Pulseaudio...


pulse audio! memory is tight and I like the fairly low latency of sound on the pandora as is, introducing pulse is *guaranteed* to make memory tighter and it *will* increase latency, and depending how well (or not) written the alsa driver is, it could make the whole shooting match a lot less reliable, pulse audio is *very* picky about the underlying driver and will curl its toes given the slightest excuse...

on the desktop I have a mail client an IM client a web browser all fighting for the sound card (at least) so it makes sense to have a sound server - though I'd rather have ESD there was nowt wrong with it!

If you try to run that many apps on the Pandora - you're out of luck you'll soon be out of memory a few hundered meg only goes so far, in the *vast* majority of cases people are using ONE app at a time...

That reminds me I really must get lmms working on the Pandora....
 
I don't think so, Chris... I think it depends on how pulseaudio is set up... my desktop has 4GB of RAM and pulseaudio only uses about 2 - 4% of my RAM when playing VLC and making a phone call on Linphone.... scaling that down to 512MB of ram, you're looking at 10 - 20% (doubt it scales down in exact multiplications, especially if optimized for the soundcard... which is doable since it's the SAME sound card in every unit)... I don't consider that a lot when IN USE. My RAM has never exceeded 10% with pulseaudio (unoptimized) and compiz running standalone..

But I guess in the end, opinion is opinion... doubt it will ever make it to firmware unless it proves more functional, easier to configure (which it is) and lighter than ALSA... but if it's ever implemented in general, we will see how much of a hit it will take to RAM... a REAL hit, theoretical...
 
10-20% that’s a massive amount of ram especially on a comparatively limited system like the Pandora!

and you seem to be forgetting the cpu time is just gobbles up - way more than the simple middle ware job its doing! and further for no apparent reason it can be running fine for weeks then decide to choke one of my cores randomly... on a single core system that would be nothing short of a disaster...

and as for being easier to configure! its sat on top of alsa - so you still have to ensure that alsa is configured and more tightly that normal and *then* you have to configure pulse audio - something that many people have found rather a task...

...and in any case I have yet to see a single justification for pa on the Pandora, like I say the end uses of an embedded system is rather different from a desktop, just because the Pandora *can* run a lot of desktop s/ware and is a very capable platform, doesn't mean you *should* be using it exactly like a desktop.

and if you *really* really think you need more than one concurrent application to access the sound system, why not look at ESD of course like any additional layer like PA then you're still using more resources - but at least less than port audio...

PA is still relatively immature compared with other sound server layers with end users frequently used as unwitting tester (in the authors words to "force" the device drivers to improve their drivers) - If ever there was a poor fit for a machine like the Pandora this is it!
 
pcm.pulse
type pulse
slave.pcm pulse


works fine as an alsa config on every system I've ever put it on...

all software is test software... anything that is complete needs no updates... show me a program that NEVER needs updates...
 
Custom Processing Unlimite said:
all software is test software... anything that is complete needs no updates... show me a program that NEVER needs updates...
If that were the case no computer would be functioning for longer than a few milliseconds, there is plenty of software that is highly stable - has reached that stability by virtue of it being established in its role for a good period of time, PA is far from established or particularly stable...

And I have still yet to hear a *single* convincing need for another layer in the Pandoras sound subsystem

go on give ESD a try...
 
Last edited by a moderator:
Back
Top