很贴切的一段话,呵呵

西门庆把潘金莲推倒在墙上,武大郎看到 了,严正声明潘金莲是属于自己,神圣不 可侵犯!!西门庆把潘金莲的衣服扒光了 ,武大郎坐在床边,予以强烈批评,要求 西门庆正视现实,立即停止一切侵害行为 。西门庆施展着各种姿势,武大郎再次表 明决心:为了保卫潘金莲,我方将不惜一 切代价………然后西门射了。。。记者问武 大郎,”你老婆被西门庆强行霸占,你对此 有何评论?”大郎面色平静说:“自从娘子 事件发生以来,我一直在密切关注事态进 展。众所周知,金莲自古以来就是我老婆 ,我对金莲有着无可争辩的主权。希望西 门庆先生认清形势,本着双方世代友好的 大局,尽快无条件释放我老婆;我提倡搁 置争议共同开发。潘金莲再次被抢走,武大郎不去营救反而 在家里面砸东西。邻居不明:武大郎,潘 金莲被抢走你应该去打西门庆啊,在家里 砸东西做什么?武大郎:我砸的东西是西 门庆家生产的!

刚写了一篇文章,花了大半小时,刚写完,手贱,按了CMD + Q,退出了。。。我操你妈!!!

关于vs起起落落的,简单说就是今天上了一个vs,发现人数非常少,整个平台玩dota的估计只有2000人。

想起当年和兄弟们一起战斗的时光,真是唏嘘不已。

玩过的平台,最早是浩方,后面是vs,虎克,aa,再到现在的11

11,最先出的dota6v6,一炮走红,再办了场比赛,万人直播!牛逼!后面就是天梯!更牛b!!!就火了,一直到现在。

反观vs,统领江湖这么多年,转型的机会大大的有,可以一一错过,活生生血淋淋的例子啊。。。

最后,再见,那风一般的少年,再见,那些青葱的岁月,再见,那纯真的年代,我那一起奋斗的兄弟们啊,你们一路平安。

vs已死,有事烧纸

现在有点焦虑。。。

额。。。忽然觉的什么都不想干,不想打游戏,不想干活,不想学习,不想看小说。。。操,有点焦虑,为什么呢。。。

难道是刚看的那篇文章,讲的是恋爱五年分手的故事,还有家里钱的问题?恩。。。压力有点大。。。fuck。。。看个电影?呵呵。研究下做点事去,fuck了。。。

与五毛党谈美国(转)

这真的是一篇好文章,呵呵 来自 http://blog.sina.com.cn/s/blog_6de114d0010108v9.html

————————华丽的分割线————————–

 

 

近日王功权先生在微博上说了这样一件事:坐出租车回到住处,出租车司机的唠叨一直萦绕在我的耳边。他从北京堵车开始说起,说到执政党的严重腐败,越说越气愤,最后干脆痛骂起共产党来。我笑着插话,试着问他走民主道路行不行。他惊呼“不行”。他坚持说“中国只要一民主,就一定乱”。我问那怎么办,他说:“再熬几代人吧。”


我也有同样感遇,昨天和一位多日不见朋友聊天,这位朋友先是痛斥社会黑暗现状,怒骂共产党贪污腐败不可救药,然后突然话锋一转说,最近唯一让他感到自豪的事情是中国终于有了航母,可以不受美国的欺负了,然后又痛斥美帝国主义亡我之心不死,妄图称霸世界,为了石油侵略打伊拉克等等。我有些吃惊,要不是面对面和他讲话,在网上我一定会把这位朋友当成五毛。当我告诉了他下面这段美国进口石油的真实情况后,这位朋友只剩下吃惊茫然的表情。


美国是世界上消耗石油最多的国家,也是进口石油最多的国家,以前一直以为中东是主要来源地、沙特是最大供应国。事实上美国第一大石油供应国是加拿大,输入石油是沙特2.7倍;第二是墨西哥,沙特第三。中东只占美国石油进口的17%。美国和加拿大有两千多公里的没有军队防守的边境线。与这么一个“利欲熏心,霸道蛮横”的国家为邻,加拿大人居然不害怕。加拿大是美国最大的石油进口国。美国人把军队开进来,插上油管子直接把油抽回家,可比打伊拉克省事多了。

继续阅读“与五毛党谈美国(转)”

武侠小说中各帮派如何解决经济问题的?

这个太牛b了,生动形象!地址:http://www.zhihu.com/question/20327435

一年前写过篇东西,聊帮派教,顺便把经济来源问题弄掉了。
直接贴全文,懒得摘引了。
要看经济结构和来源的,请直接看粗体字。

——————————————————————————

“师父,为啥那些姑娘刚和我语笑晏晏,一听说我是巨鲸帮的,立刻就翻个白眼?”
“傻孩子,报啥帮名儿啊,以后就说你是海上游迹的一介少年浪子,最爱读麦尔维尔的《白鲸》,喜欢闻龙涎香与海风混合的味道。姑娘们立刻扑你怀里。”

“怎么,我混帮派还丢人了吗?”
“你错了,你混的不是派,是帮。”

“那,那还有区别吗?”
“区别大了去了。你看武当昆仑、华山青城,出来的哪个不是少侠?”

“区别有恁大吗?”
“你以后下山就知道了。你砍个人就是江湖火并,人家砍个人就是替天行道。你钓姑娘是居心叵测,他们钓姑娘是风流倜傥。你去亲姑娘肩膀手指是意图猥亵,他们去亲姑娘肩膀手指就是吸毒疗伤!”
继续阅读“武侠小说中各帮派如何解决经济问题的?”

根据native crash log 查找native出错代码

使用ndk,如果native crash,会打出一大堆带地址的出错信息,这里有一个很给力的python,来自于这个项目,很有用,可以还原回出错的行。

文件下载地址

项目地址在这里:https://code.google.com/p/android-ndk-stacktrace-analyzer/

使用方法如下:只需要三步,

1.得到so的asm文件,2.拿到crash log 3.使用这个脚本,ok 如下:

 

1.android-ndk/android-ndk-1.6_r1/build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-objdump -S mylib.so > mylib.asm

2.自己adb logcat 拷出来那一堆东西,保存

3.python parse_stack.py libslpi.asm logcat.txt

K歌引擎机型问题简述(坑爹啊!!!)

底层使用ffmpeg + lamemp3 使之能编码mp3.

1.当机器有点卡,导致播放的伴奏会卡。好了,这下就完蛋了,后面所有的都不同步了。

buffer调大就好了。

2.同时播放伴奏和录音,然后合成编码,发现不同步,录音偏慢。因为播放线程即audioTrack有个buffer,如果比较大的话,导致delay很明显。因为人是听到音乐然后开始跟着唱的,呵呵。

这时要让record线程休眠一段时间,这个时间就是填满player的buffer的时间。

3.绝大部分声音和伴奏同步,偶尔不同步,录音偏快,而且有延迟越来越大的趋势。这个是因为机器有点卡,或忙于做别的事情,这时record的buffer满了,而我们还没有来及取,就导致部分数据丢失,所以就导致人声越来越快。

record的buffer调大,整个线程优先级调高,呵呵。

4.moto me86等使用 tegra 2 的系列处理器点击会crash。

我操,这个超级坑爹!因为tegra2系统处理器虽然是arme-v7但是却不支持neon浮点运算库(这个是一个非常重要的可选项,绝大部分都支持)。。。尼玛。。。目前没有好的办法。。。只能单独为他发包了。。。

坑爹的 AudioRecorder 的 setPositionMarker

from stackOverFlow

太坑了。。。

My Android Java Application needs to record audio data into the RAM and process it. This is why I use the class “AudioRecord” and not the “MediaRecorder” (records only to file).

Till now, I used a busy loop polling with “read()” for the audio data. this has been working so far, but it peggs the CPU too much. Between two polls, I put the thread to sleep to avoid 100% CPU usage. However, this is not really a clean solution, since the time of the sleep is not guaranteed and you must subtract a security time in order not to loose audio snippets. This is not CPU optimal. I need as many free CPU cycles as possible for a parallel running thread.

Now I implemented the recording using the “OnRecordPositionUpdateListener”. This looks very promising and the right way to do it according the SDK Docs. Everything seems to work (opening the audio device, read()ing the data etc.) but the Listner is never called.

Does anybody know why?

Info: I am working with a real Device, not under the Emulator. The Recording using a Busy Loop basically works (however not satifiying). Only the Callback Listener is never called.

Here is a snippet from my Sourcecode:

 

public class myApplication extends Activity {

  /* audio recording */
  private static final int AUDIO_SAMPLE_FREQ = 16000;
  private static final int AUDIO_BUFFER_BYTESIZE = AUDIO_SAMPLE_FREQ * 2 * 3; // = 3000ms
  private static final int AUDIO_BUFFER_SAMPLEREAD_SIZE = AUDIO_SAMPLE_FREQ  / 10 * 2; // = 200ms

  private short[] mAudioBuffer = null; // audio buffer
  private int mSamplesRead; // how many samples are recently read
  private AudioRecord mAudioRecorder; // Audio Recorder

  ...

  private OnRecordPositionUpdateListener mRecordListener = new OnRecordPositionUpdateListener() {

    public void onPeriodicNotification(AudioRecord recorder) {
      mSamplesRead = recorder.read(mAudioBuffer, 0, AUDIO_BUFFER_SAMPLEREAD_SIZE);
      if (mSamplesRead > 0) {

        // do something here...

      }
    }

    public void onMarkerReached(AudioRecord recorder) {
      Error("What? Hu!? Where am I?");
    }
  };

  ...

  public void onCreate(Bundle savedInstanceState) {

  try {
      mAudioRecorder = new AudioRecord(
          android.media.MediaRecorder.AudioSource.MIC,
          AUDIO_SAMPLE_FREQ,
          AudioFormat.CHANNEL_CONFIGURATION_MONO,
          AudioFormat.ENCODING_PCM_16BIT,
          AUDIO_BUFFER_BYTESIZE);
    } catch (Exception e) {
      Error("Unable to init audio recording!");
    }

    mAudioBuffer = new short[AUDIO_BUFFER_SAMPLEREAD_SIZE];
    mAudioRecorder.setPositionNotificationPeriod(AUDIO_BUFFER_SAMPLEREAD_SIZE);
    mAudioRecorder.setRecordPositionUpdateListener(mRecordListener);
    mAudioRecorder.startRecording();

    /* test if I can read anything at all... (and yes, this here works!) */
    mSamplesRead = mAudioRecorder.read(mAudioBuffer, 0, AUDIO_BUFFER_SAMPLEREAD_SIZE);

  }
}

Answer:

I believe the problem is that you still need to do the read loop. If you setup callbacks, they will fire when you’ve read the number of frames that you specify for the callbacks. But you still need to do the reads. I’ve tried this and the callbacks get called just fine. Setting up a marker causes a callback when that number of frames has been read since the start of recording. In other words, you could set the marker far into the future, after many of your reads, and it will fire then. You can set the period to some bigger number of frames and that callback will fire every time that number of frames has been read. I think they do this so you can do low-level processing of the raw data in a tight loop, then every so often your callback can do summary-level processing. You could use the marker to make it easier to decide when to stop recording (instead of counting in the read loop).