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 <kvehmanen@eca.cx> 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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Dec 22 04:15:01 2010
This archive was generated by hypermail 2.1.8 : Wed Dec 22 2010 - 04:15:02 EET