I'm replying out of order and still digesting all the messages... but first wanted to thank all the Nokia engineers and architect willing to come here and discuss their experience with the N900 product multimedia issues publicly. This wouldn't be happening with Apple, or Android, so I wanted to express my appreciation for your commitment to open-ness, open-source, and open discussion.
On Sun, Dec 19, 2010 at 12:43 PM, Kai Vehmanen <[email protected]> wrote: > And another btw, in case someone has missed this, do check Jyri Sarha's > slideset presented at plumber's conf 2009: > http://linuxplumbersconf.org/2009/slides/Jyri-Sarha-audio_miniconf_slides.pdf > > E.g. slide 15 has a good diagram of how the pipelines are connected. > > Some things to try: > - use an output low overehead output (e.g. headset) > - use srate that matches hw rate (48kHz in this case) ->no SRC is > involved These are interesting suggestions and that is a very good link explaining the issues. Also, I was wondering how the n900 speakers actually managed to sound so good while being minuscule -- so you're saying a finite impulse response adjustment has been made? But wouldn't that be different "mid air" versus "on kickstand" versus flat on table (boundary effect)? [2.0 version feature: haptic adjustment of FIRs] And that processing overhead can be reduced by plugging-in headphones or activating stereo output? ...... So interestingly, in [1] one of the main issues is latency -- the exact same one I raised as being important for "creative" multimedia. But clearly , it's also important for day-to-day tasks on the handset. The quotes below are almost as if pulseaudio is being used in a "jack-like" fashion, with small buffers, rather than the usual power-efficient large buffers. But that also means pulseaudio is consuming more CPU cycles at high-prio, competing against shorter emptying buffers. Does the "Policy Framework" orchestrate switching pulseaudio's buffer-lengths "on the fly" in order to provide low-latency when needed for a call, and more power-efficient performance for streaming audio playback, such as listening to music or watching a video? ................... [1] http://linuxplumbersconf.org/2009/slides/Jyri-Sarha-audio_miniconf_slides.pdf Cellular Call Latency Challenge • Cellular modem air interface alone causes a lot of latency • GSM and 3G audio frame size is 20 ms • Cellular frame timing is ruled by base station • Timing of 20ms frames change in cellular hand over • Simple buffering between cellular modem and audio codec adds at least 20 ms latency to each direction Minimize Cellular Call Latency • Run ALSA with two 5 ms fragments This is doable even on ARM Linux with real-time priority DMA buffering delay is 5ms each direction • Synchronize up link audio buering with Cellular Modem Cellular Modem sends up-link timing adjustment messages Align up-link buering according to messages Change UL timing with 5 ms granularity • Synchronize down link audio buering with Cellular Modem Keep tight buffer management to minimize latency ... ... Acoustic Echo Cancellation .... ... • Good acoustic echo path modeling for transient signals is possible only with proper time alignment of the reference loop Accurate feedback loop timing for AEC • Accurate playback and capture latencies are needed for time alignment of echo reference and mic signal • Latency functions of ALSA do not work well with doing DMA block transfers • Solution: Implement ALSA sink latency functions based on snd_pcm_htimestamp() .................... -- Niels http://nielsmayer.com _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
