On Tue, Dec 14, 2010 at 1:31 PM, Marco Ballesio
> Please check here:
>
> http://meego.gitorious.org/maemo-multimedia/pulseaudio-policy-enforcement/trees/master/src
> to get a few more hints on the subject.
Hopefully there's more than just source-code to describe the policies
and enforcement. Is there a design document stating the
"organizational" or "legal" or "human" reasons for said policies and
enforcements?
And, as a developer, where is the documentation for the appropriate
layer to use, the appropriate API, etc -- e.g. for the original
question that started this thread -- how to switch on/off speakers,
FM-radio transmitter, etc on handset. ( cf my original reply
http://lists.meego.com/pipermail/meego-handset/2010-December/000066.html
)
Something high-level like the following Maemo document would be very
helpful -- but I have been unsuccessful finding such documentation for
Meego: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain
Also, why not use ALSA use-case-manager:
http://opensource.wolfsonmicro.com/node/14
UCM appears to be scheduled for other distros "handset" work:
https://wiki.ubuntu.com/Specs/N/ARM/AlsaScenarioManager
> the n900 Resource Policy enforcement points were directly interacting
> with ALSA. As Krisztian pointed out, it's no more necessary (and at
> the limit it may be dangerous for your system's health) to do so
> within MeeGo, as the pulseaudio ports can elegantly handle the whole
> thing.
Potential to blow out my handset speakers duly noted (the n900 goes
http://en.wikipedia.org/wiki/Up_to_eleven !), however, I wasn't
advocating playing around with the ALSA layer indiscriminately, in
fact, I specifically stated:
> the "amixer" results of meego indicate an equally complicated
> soundchip; where random hacking could render your system somewhat useless... is there documentation on all these values?:
> http://nielsmayer.com/meego/n900-card0-amixer.txt .
> The only chip mentioned by name is
> http://focus.ti.com/lit/ds/symlink/tpa6130a2.pdf "TPA6130A2 Headphone"
................................
Regarding my old nemesis, pulseaudio ( http://tinyurl.com/2976vu6
== http://old.nabble.com/uninstall-pulseaudio-to-increase-audio-app-stability-across-updates-(was-Re:-yum-update)-td27759501.html#a27759501
), I think the only "elegant" thing about pulseaudio is that it's
bluetooth handling works for those that care about bluetooth; given
the number of bug-reports and incompatibilities pulseaudio generates
in different distros, I'm not sure "elegant" is the right word....
From my position, as a multimedia/ALSA/linux-audio developer, having
to go through pulseaudio sounds like an all-around bad idea, and to
have "enforcement" or "compliance" attached makes it sound even
worse. Tell me it ain't so!
There is a growing class of applications that do not want or need
pulseaudio around -- those using http://jackaudio.org/ . When the
jack audio server launches, the first thing it does it use dbus to
disable pulseaudio. Is that also non compliant?
It seems inappropriate to preclude an entire class of application --
real-time "pro" audio and video apps that utilize the Jack audio
server to provide low-latency, tightly synchronized audio -- as needed
for modern multimedia creation and playback. Perhaps such applications
are a stretch for an OMAP3-class device, but given the many
audio/media apps listed in http://omappedia.org/wiki/PEAP_Projects ,
clearly OMAP4 and beyond might not be, even on a puny "handset." Of
course, those making such audio apps might sidestep pulseaudio
compliance/latency/inefficiency issues by using
http://opensoundcontrol.org/ and an external DAC (
http://gregsurges.com/tag/dac/ ).
Finally, it seems odd that in a "handset" environment, pulseaudio is
an absolute requirement. To me, it is just a waste of batteries, and a
terrible source of unnecessary context switching and interrupts during
audio playback. It's sort of like being forced to drive around in a
gas-guzzling, oversized sport-utility vehicle with 10 foot tires and 5
feet of ground clearance -- just to drive to the market or work on a
well-paved freeway on a summer's day -- even when one might prefer a
bicycle, motorcycle, sports-car, subway, or whatever tool is best for
the job. Given that's the argument against Java/Android on the handset
(it's the SUV of languages/environments) it's unfortunate that
lighter-weight and less monolithic and more "unixy" solutions aren't
being pursued for audio on the Meego handset.
Take for example HD audio/video playback -- something where you need a
"sportscar" to get the latency and sample rate associated with the
audio stream while also performing HD decoding (e.g. 16bit/96K audio
is supported on omap3430 per
http://and-developers.com/device_information ). Pulseaudio typically
operates at a fixed rate and forces resampling to that rate, causing
an oft perceptible loss in fidelity. So in order to allow "digital
mixing" for notification signals or phone calls while watching an HD
movie, either pulseaudio will be upmixing those signals to 16/96,
which is inefficient for audio that doesn't need the higher bitrate;
the alternative, which is what we get with pulseaudio, is that the DAC
is running at 44 or 48k, and even though we might be listening to
material at a higher sample-rate, it'll be resampled and sonic
artefacts may be introduced in order to work with the 'lowest common
denominator'.
IMHO what is needed is not a "digital mixer" and resampler and extra
user-space processing before going into the kernel and out to the
sound hardware via ALSA drivers. We certainly need "use case
management" and the notion of a digital patch bay, and some way of
smoothly mixing between sounds, glitch free switching of sample rates
at the ALSA level, and then choosing the direct path to hardware
that'll best handle the "main audio task" we're doing -- e.g. playing
music, watching a movie, making a phone call, or just using the screen
UI. What isn't needed is "desktop networked audio" capabilities of
pulseaudio, or any extra user-space streaming/mixing/resampling of
signals.
The inefficiencies introduced by pulseaudio is evidenced by the
n900/meego-1.1 handset, which cannot maintain audio synchronization
during audio or video playback if even the slightest trace of
something else is going on, including a wireless network scan, or even
just cursoring around in a networked terminal (which goes through the
wireless stack in my setup).
On Maemo/n900 note what happens when playing back an Mp3 -- pulseaudio
consumes twice the resources at "high priority" of the decoding
process:
Mem: 239968K used, 5572K free, 0K shrd, 1856K buff, 68204K cached
CPU: 31.5% usr 10.3% sys 0.0% nice 53.9% idle 4.1% io 0.0% irq 0.0% softirq
Load average: 0.88 0.56 0.27
PID PPID USER STAT RSS %MEM %CPU COMMAND
781 1 pulse S < 3832 1.5 22.0 /usr/bin/pulseaudio --system
--high-priority
1317 705 user S < 6320 2.5 12.2 /usr/bin/mafw-dbus-wrapper
mafw-gst-renderer
971 1 user S < 1868 0.7 1.3 /usr/bin/dbus-daemon --fork
--print-pid 5 --print-address 7 --session
On Meego/n900, here's what playing track one in "Music player" looks
like -- where even cursoring around on the command-line in bash in the
terminal is enough to "desync" the audio stream for a few seconds --
and that's with pulseaudio running at nice=-11 and high priority! Note
pulseaudio consumes 31.6% CPU while the decompression, presumably
happening in bognor-regis "Media daemon and play queue manager" ==
34.5% and finally the media player app itself at 6.7%.... all while
consuming 21.3% memory just to play back an MP3....
top - 17:56:15 up 20 min, 1 user, load average: 3.31, 3.12, 2.07
Tasks: 106 total, 2 running, 103 sleeping, 0 stopped, 1 zombie
Cpu(s): 18.1%us, 26.6%sy, 17.2%ni, 36.5%id, 1.2%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 226260k total, 215948k used, 10312k free, 84k buffers
Swap: 786428k total, 5944k used, 780484k free, 81596k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1063 meego 20 0 127m 9m 7720 S 34.5 4 .5 1:35.09 bognor-regis-da
892 meego 9 -11 191m 4588 3256 S 31.6 2.0 2:45.14 pulseaudio
1104 meego 20 0 2364 960 744 R 10.5 0.4 0:00.22 top
1059 meego 25 5 91628 32m 29m R 6.7 14.8 0:29.26 meegomusic
803 root 20 0 38452 28m 17m S 3.8 12.8 0:38.55 Xorg
876 root 20 0 0 0 0 S 1.9 0.0 0:13.20 ipolldevd
Here's *just* watching a video (big buck bunny 240p) on the meego
handset -- and no audio is even playing back (constant triggering of
desync bug seen when playing back audio stream?) but pulseaudio is
working hard anyways, consuming almost 50% of CPU needed to decompress
the video and audio stream:
top - 17:46:48 up 11 min, 1 user, load average: 4.47, 2.20, 1.03
Tasks: 106 total, 2 running, 103 sleeping, 0 stopped, 1 zombie
Cpu(s): 12.8%us, 31.9%sy, 55.2%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 226260k total, 222564k used, 3696k free, 100k buffers
Swap: 786428k total, 1224k used, 785204k free, 85424k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1007 meego 25 5 269m 41m 32m R 59.3 18.9 1:27.18 meegovideo
892 meego 9 -11 191m 5272 3948 S 26.1 2.3 0:40.00 pulseaudio
803 root 20 0 33092 23m 13m S 4.1 10.6 0:10.83 Xorg
I'm sure a simple experiment could determine exactly the "effect" of pulseaudio:
Play the same playlist until the battery wears out using the same
software player outputting first to pulseaudio (pref not through
ALSA's pulseaudio driver because that wouldn't be "fair" to go through
the kernel twice) then play the same through ALSA "dmix" interface,
just to emulate pulseaudio's mixing/resampling functionality. I would
imagine the pure-ALSA solution would pass the "energizer bunny' test
for more hours and far fewer kernel/userspace context switches.
Although a realtime userspace process like pulseaudio can help deliver
stable audio in a multicore environment -- it may end starving out
other processes on a slower uniprocessor. Which is why I believe a
pulse-audio-free solution should be available and still be "compliant"
on low-end systems.
The one place where pulseaudio is currently helpful is in hooking up
bluetooth devices. But ALSA has it's own bluetooth layer as well, and
other architectures for audio shouldn't be precluded:
http://bluetooth-alsa.sourceforge.net/future.html or Phonon
(http://pulseaudio.org/wiki/KDE ).
-- Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed, 15 Dec 2010 10:31:58 -0800
This archive was generated by hypermail 2.1.8 : Wed Dec 15 2010 - 20:15:05 EET