Marco -- many thanks for your reply -- I've taken the liberty of
CC'ing this informative reply to the Linux-Audio-Developers list
(your CC was not posted as you're not a subscriber:
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.
Here's a link to Marco's original post to meego-handset mailing list,
---------- Forwarded message ----------
From: Marco Ballesio
Date: Sat, Dec 18, 2010 at 4:42 AM
Subject: Re: Meego pulseaudio "compliance" and "enforcement" (was Re:
[Meego-handset] Enabling Speakerphone)
To: Niels Mayer
Cc: firstname.lastname@example.org, Linux Audio Developers
sorry for the late reply but, whew, this was really long, definitely
more than what my poor brain can handle in a single bunch ;). Maybe we
could split this into a "Resource Policy Framework" and "Pulseaudio on
Embedded" couple of threads.
As a general comment on PA, it may appear odd but when I started
working with it I shared 100% of your considerations. Working with it
(not ON it), I started realising that, ok, it may not be perfect (and
which software actually is?) but it brings definitely more benefits
than troubles to the system. See my notes below for more details.
Maybe you've read in some other of my posts here and there, I'm trying
to get a Resource Policy Framework wiki somewhere. In the meanwhile,
documents are scarce but present:
- The MeeGo conference presentation:
Does not say too much, but it comes with some slides and many "mmmmh"
- The resource policy application developer's manual:
Mysteriously, it's not linked or referred to anywhere.. at least, now
it's on this thread.
- The source code: it may twist more than one nose but, at the end, I
always like to check in the sources before/after Googling. Documents
may be obsolete (who knows?) or expose a partial view. Code can't ;).
Not that I want to say with this that we don't need more documents
about the Resource Policy Framework...
> Is there a design document stating the
My pointers of above may begin to satiate your hunger (appetisers?).
Unfortunately, this is still in the "dark side" of the documentation,
which is currently application-centric. Hopefully one day we'll have
an "Adaptation developer's guide", in the meanwhile, a good starting
point may be checking the sources, the N900/Meego ruleset and posting
questions here. If it's not enough, we may set up an IRC channel (if
there's enough interest)...
See my notes above about the project wiki. Your pointers are
definitely good hints, thanks.
this project covers the audio-specific cases: for what I understood it
might very well be used as an ALSA enforcement point in the Framework
so, more than compete with Resource Policy it would be complementary
in case you don't really want/need to use a sound server. BTW, I could
not find so much info, maybe you can help me to retrieve:
- more than just source-code to describe how it works.
- the developer's documentation for the appropriate layer to use, etc.
- something like:
now, the pulseaudio cases. First of all, please note I'm not the best
advocate for it, btw my 0.05 €.
Posting some extracts of your comments to the PA mailing list will
definitely give you a better insight for the internals of the server.
> Regarding my old nemesis, pulseaudio ( http://tinyurl.com/2976vu6
And actually "elegant" was not referred to pulseaudio, but to the way
its ports can handle audio routing instead of using ALSA (they bring
Yes, the sound server has shown instabilities in some cases and I
personally used to uninstall it on my Ubuntu box immediately after the
upgrades. Recently but many improvements have been made at a point
that, on a PC, I'm nowadays not seeing it anymore jumping to a steady
30% of the CPU or completely jamming any audio output in the middle of
Another _personal_ feeling I had is that pulseaudio was pretty hard to
configure for a generic HW (like distros tend to do), but works pretty
well after being tuned for a given one (like 95% of embedded products
are). Very often the root issue may have been a wrong configuration
for your system.
I can agree from a kernel/ALSA pov (everything in userland appears to
be less efficient than any kernel drivers ;) ), I strongly disagree
from the system architecture's one. Some points you should consider:
- Audio outputs frequency tuning: in the real word a crappy speaker
costs less than a good one (strange?) so, unless you've a very high
target price, you'll usually have to take the maximum out of garbage
by "massaging" the output spectrum in order to get an adequate overall
transfer function. And this must work with all of the applications
-even the ones coming from third parties on which you don't have the
bare minimum control on- and different analog outputs (front, rear,
bt, ...). Not that pulseaudio comes with these features
out-of-the-box, but it's quite easy to plug them in.
- Audio inputs: the dual of audio outputs.
- Mixing: it's possible that users will want more than one application
accessing the audio output at the same time (e.g. navigator and car
radio) or that they'll want to switch bw two different applications
all of a sudden (e.g. radio and ringtone). In all these cases they'll
want a good mixing and no sudden power steps when the ringtone app
does not know about the volume level used for the radio.
- Acoustic delay estimation: sitting in the middle of pulseaudio
(running as a real-time thread) it's easier to write a proper AEC.
Back to 2004 I've tried to grant, with a TI aic31, constant latencies
for both LEC and AEC by just using ALSA and the application... It took
a really long time to work.
- It may not appear so, but it's energy-efficient (see my comments
below if you just jumped out of your chair).
Now, I don't mean that those things can be handled only by pulseaudio.
Actually developers could write their own sound server, or use an
already available one, to do all of this, but..
- How long would it take to be better than pulseaudio? (e.g. wrt my
- Can it grant the same solid user base and portability across embedded HW?
- Could it grant the same level of contribution from companies with
solid experience on the subject?
- Are there architectural flaws for which pulseaudio couldn't
effectively handle these cases? If yes, has anybody tried to discuss
about them on the PA mailing list?
I've no religious issues against jack and actually I don't have that
much experience with it, so I'd like to know more about jack on
embedded. I'd like to know, for instance, how many embedded, low-power
devices are already using it and with which degree of success. Also it
would be great to know if anybody has interfaced it with a cellular
modem to handle Circuit-switched cellular calls, and if the device has
actually been certified for such a service in any countries.
please correct me if I'm wrong, but if I understood well most of the
apps using _exclusively_ jack are aimed to audio/video
composition/editing. Now, as we are on the IVI ML I think it's quite a
strange use case (even though I must admit I don't know which
requirements you have).
> Finally, it seems odd that in a "handset" environment, pulseaudio is
see below (and above).
> and a
well, it runs as real-time priority, so it's executed when it's
scheduled. Context switches would not be different for any process
(e.g. jack) running with the same scheduling.
> It's sort of like being forced to drive around in a
funnily, this is EXACTLY the same thing I thought the first time I
profiled pulseaudio on the N900, then I found some reasonable
explanation (scroll a little below).
> Take for example HD audio/video playback -- something where you need a
Yes, this is a bad aspect, but it's actually possible to change the
output bitrate of the server (it depends on the port used). Maybe you
could query on the PA mailing list for more knowledge on the subject.
so we'll end up writing our own sound server or using a different one,
won't we? As an alternative, we may have to heavily modify ALSA to
suit our needs, and we'll not have yet covered all of the needed
Personally, I would not say that MultiMedia with MeeGo on the N900 is
already at the same quality of Maemo 5. Lots of tuning is imho still
You must consider that here there many algorithms involved that
users/applications don't even know about, like the spectrum
optimisations I've been mentioning before. If you could run an
oprofile session over your tests you'd see that the actual CPU
attributable to PA is pretty lower than your figures.
> I'm sure a simple experiment could determine exactly the "effect" of pulseaudio:
As written above, PA is not only resampling and mixing here.. imho if
the user/the developer didn't have to adjust the system to work with
PA in order to achieve this, it's a success. The CPU usage comes from
the fact we're actually running something we need.
> I would
Sure it would, but with a lower set of features (and an higher cost
for the audio system). It's up to the device price target/customer's
pockets and needs to decide what's better.
> Although a realtime userspace process like pulseaudio can help deliver
I would agree in some cases, that is when the system conditions don't
require it to run multi-application use cases and the price tag for
the audio system is irrelevant wrt the audio quality.
Note for the reader: if you've reached this point it means you're
really interested about pulseaudio on embedded devices :D.