标签： android

底层使用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浮点运算库（这个是一个非常重要的可选项，绝大部分都支持）。。。尼玛。。。目前没有好的办法。。。只能单独为他发包了。。。

一开始搞的想死，相当的莫名其妙，搞清楚了发现很强大，呵呵。

@Override
        public boolean onTouchEvent(MotionEvent event) {
            int action = event.getActionMasked();
            if (action == MotionEvent.ACTION_DOWN || action == MotionEvent.ACTION_POINTER_DOWN) {
                int i = event.getActionIndex();
                Point p = new Point((int) event.getX(i), (int) event.getY(i));
                for (int j = 0; j < mRect.length; j++) {
                    if (mRect[j].contains(p.x, p.y) ) {
                        click(j);
                    }
                }
            }

最关键的是这个MotionEvent  这个东西，半猜半试的。

每当有一个action时，都会触发一个event，这个时候拿 event.getAction() 时会是 他的code，为了区分是哪个pointer发生的这个event，会加上个mask 这里第一个手指按下，第二个手指点击时getAction = 261 就是0xff00 + 5，5是 action_pointer_down ,所有就要调用一个函数 event.getActionMasked() 得到这个action，然后判断这个action是不是我们想要的，如果是，就拿到event.getActionIndex()，然后根据此index去拿这个点的相关信息就可以了。

嘿嘿，搞定，收获还是很大的，哈哈