Re: [LAD] Meego pulseaudio "compliance" and "enforcement" (was Re: [Meego-handset] Enabling Speakerphone)

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Kai Vehmanen <kvehmanen@...>, <linux-audio-dev@...>, Marco Ballesio <gibrovacco@...>
Cc: <meego-handset@...>
Date: Tuesday, December 21, 2010 - 11:07 pm

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 wrote:

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?


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

-- Niels
Linux-audio-dev mailing list

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] Meego pulseaudio "compliance" and "enforcement" (w..., Niels Mayer, (Tue Dec 21, 11:07 pm)