Exophase said:
Look, it really comes down to this. When Pandora is supposed to be running an intensive emulator that needs every last shred of CPU it can get I'm simply not willing to give 15% of it up to a pointless sound server (same thing goes for video, at that). Call me greedy. But all of those things that PA is good at are things that almost no one actually desires in software running on a handheld (or desktops, to be honest).
Not once did I say that *the Pandora* should use PA. As I said, I'm split on this subject when it comes to the Pandora; I wouldn't like to have PA enabled by default, but I'd like the option to be there, e.g. it should be possible to run "pulseaudio -D" without problems for situations when you want to do network streams. But otherwise... OSS would be a better default, as long as there's an usable ALSA frontend, and as long as it remains possible to "ipkg install" pulseaudio.
Exophase said:
Most of the time I'd be much happier with the sound system not messing with my data. Pandora is a fixed platform. The programs running on it should ideally not need to be resampled at all. They should generate data that's at a rate and depth most suitable for the Pandora's hardware. If they can't do this then I think it'd be better for them to know something needs to change rather than spending a lot of CPU time trying to fix it for them.
Agree 100%. However, sometimes you don't have a choice. Some libs will just output 44100 Hz 16 bit streams regardless of what the hardware prefers, but that's a pretty standard format anyways so it shouldn't be a problem. I'm just saying that it would be better if there at least was some kind of basic re-sampling functionality.
Exophase said:
Maybe Ubuntu screwed things up somehow.
They do that a lot
You should have a look at how they handle the transition to Plymouth in the init scripts... brr
Exophase said:
I don't know why people have to "stop clinging to the past" and let PA get fixed - to me PA's disadvantages are intractable and are themselves fixing something that wasn't broken. Unless PA can provide EXACTLY the same benefits kernel level mixing can (it can't) then it's not fair to make it the only choice.
(Disclaimer: what I said was provocative and not related to my own opinions at all, as indicated by the word "flamebait")
Well, I don't think that PA should be the only sound API, I'm not stupid. But there are no better API alternatives (functionality-wise) out there that I know of. Show me the API that I can use on Linux and that allows me to asynchronously control an indefinite amount of streams connected to various sinks, to kill a stream and replace it with another stream, and to have the sound buffer become cleared from where the old stream ended and replaced by data from the new stream, *while* the device is reading the buffer via DMA... I can't do that in ALSA for example (thus creating more than 16 ms of latency while the old stream is killed and the new stream gets buffered); most PA-related crashes are actually triggered because new/unstable PA-optimized drivers are loaded into ALSA that gives PA direct access to shared buffers (so yes, PA *can* be low-latency *today* (more so than raw ALSA); you just have to change your /etc/pulse/daemon.conf file accordingly). Show me such an API and I'll gladly use it.
BTW, how did this suddenly become an argument? Nobody has to defend themselves here, take it easy! It's not like a Pandora Dev (EDIT: as in someone who's actually responsible for the core OS image, I mean) is going to walk in here and say "Gee, I'm wondering if choosing PA was such a good idea; I wish that there was an exhaustive discussion about it somewhere, preferably in the format of a forum thread since I really love to spend hours reading through pointless discussions". No, if we want to change something, this isn't the place for discussion; we should 1. check whether the latest Pandora build even uses PA and 2. create a Wiki page about what we can do about it before we 3. submit it to someone with the power to change stuff.
