Hi,
On Sat, 18 Dec 2010, Niels Mayer wrote:
The list comprises a good number of people with expertise in both
pulseaudio; hopefully the Jack sound server authors, including Paul
Davis, will be willing to publicly share their perspectives on the
issues raised regarding the role of pulseaudio on a handset and Linux
audio performance/latency/efficiency issues.
btw, just a note that there are lots of LAD/JACK regulars (including me)
currently working with Maemo/MeeGo, so there's some (or actually quite a
lot) of history to this discussion.
Here's my reply to Benno's mail (July this year) about this same topic on
maemo-developers:
http://lists.maemo.org/pipermail/maemo-developers/2010-July/027087.html
I think many (not all but many) issues you Niels raised in your original
mail would happen with JACK as well:
- Most of the CPU load attributed to Pulseaudio is actually
algorithms specific to the product (in-process clients in JACK
terms, so would show up with jackd as well).
- Bugs in kernel drivers that cause scheduling spikes (your WLAN
scan example) would affect jackd just as badly (bear in mind
that your average mobile phone has a huge number of hw drivers,
so there's a lot of kernel code to go through for fine-tuning);
The Maemo5 N900 firmware should fair much better (it has gone
through more fine-tuning).. This is very familiar to all of us
building machines to run jackd. Even one badly behaving driver
can ruin the whole thing, and hunting these down is not a small
task.
- Locking the sample-rate is not specific to Pulseaudio. It's
more related to the problem of supporting multiple, totally
independent clients; e.g. you could lock the hw to 8000 for calls,
but if then video playback is started, while the call is still
ongoing, do you a) stick to 8000Hz for the whole video as well,
b) have a glitch as you need to reprogram the hw to different rate,
or c) do you do the common thing and run at a common backend rate
(like 48000) and resample some of the client streams.
Agreed, JACK has many strong points that apply to MeeGo context as well,
especially in providing a good API for out-of-process clients to get
low-latency access to the audio engine. You can do the same with
Pulseaudio, but it's more complicated and more prono to errors (e.g. the
QAudio recording example Benno mentioned in the above thread). But then
OTOH, Pulseaudio has many strong points as well. Both projects can be
extended/developed. Of course here one important factor is what the
projects themselves want to do... and here Pulseaudio has a much more
explicit focus on wanting to solve the wider audio-on-the-desktop problem,
and it has had that for a long time.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
