The Desktop


Exophase said:
And I think we should use OSS instead of ALSA but that ship has possibly sailed forever :(

Me too. ;)

dflemstr said:
Someone said a long time ago in one of those "Use the Pandora for an audio mixer" threads that the Pandora uses PulseAudio. So you can easily switch backends to OSS!
I read a very long article a while ago complaining about audio quality. Something about not mixing frontends and backends. (probably the wrong terminology - I know nothing about audio in Linux)

Summarized, OSS4+OSS4 = Good, Alsa+OSS = bad, Alsa+Alsa = bad, PulseAudio+Alsa = bad

Where "bad" indicates either delay, poor audio quality, crashes, or high resource usage.
 
Last edited by a moderator:
Exophase said:
dflemstr said:
Someone said a long time ago in one of those "Use the Pandora for an audio mixer" threads that the Pandora uses PulseAudio. So you can easily switch backends to OSS!

Oh god, PulseAudio. Maybe I should just rip the speakers out of mine.

PulseAudio is utter shit. Even when it actually works properly it still adds a ton of CPU overhead. Just what we want on our low power ARM devices, right?

It's not like using PulseAudio to wrap OSS even makes any sense. If it was just using straight OSS from the start everything would be very simple for everyone.

It works much much much (prbly still not enough) better now then even half a year ago. With Ubuntu 9.08 I don't get any of the crashed device issues and huge cpu hogging I used to get even with 9.04. Ofc it will prbly break again with 10.04 :p
 
Last edited by a moderator:
Kramy said:
Exophase said:
And I think we should use OSS instead of ALSA but that ship has possibly sailed forever :(

Me too. ;)

dflemstr said:
Someone said a long time ago in one of those "Use the Pandora for an audio mixer" threads that the Pandora uses PulseAudio. So you can easily switch backends to OSS!
I read a very long article a while ago complaining about audio quality. Something about not mixing frontends and backends. (probably the wrong terminology - I know nothing about audio in Linux)

Summarized, OSS4+OSS4 = Good, Alsa+OSS = bad, Alsa+Alsa = bad, PulseAudio+Alsa = bad

Where "bad" indicates either delay, poor audio quality, crashes, or high resource usage.
http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html these posts explain some of the issues.

EDIT: sorry for fueling this off topic crap :)
 
Last edited by a moderator:
As for the comments about LXDE using OpenBox, the thing is OpenBox and a panel are pretty much all you need which is why I prefer stuff like CrunchBang over full blown LXDE environments.
I'm really, really surprised at PulseAudio being included by default and would like to see official confirmation of this. I'm worried that this could become a support nightmare for the team.
 
I'm sure they'll use whatever works, most applications are abstract enough that they could channel audio into Egyptian hieroglyphics, if that was the only available sound system.
 
Can we use OSS on the Pandora ,sorry from my lack of understanding and why is ALSA a problem ,could
someone explain the difference between OSS and ALSA and the prefered sound driver.


cheers
 
mahousaru said:
It works much much much (prbly still not enough) better now then even half a year ago. With Ubuntu 9.08 I don't get any of the crashed device issues and huge cpu hogging I used to get even with 9.04. Ofc it will prbly break again with 10.04 :p

I give it a chance in 9.10 (Karmic) and it was terrible, even worse than it was on 9.04 (Jaunty). Latency was bad across the board and several programs either had choppy audio output (like flash in Firefox) or hung completely. I've read of several other people having severe problems with it as of Karmic.

Fortunately, Ubuntu have put up a guide to switch to OSS in Karmic so it's not as hard to ditch ALSA/PulseAudio anymore.

On my netbook (currently using Eeesy Peasy Ubuntu 9.04 but that will change to Karmic netbook remix soon) it works but uses like 20% CPU. It'll be much worse on a Pandora than on a 1.6GHz Atom.

OSS is the obvious choice for embedded platforms. GP2X and Wiz use it, so that means migrating from them will be simpler (I use straight OSS now instead of SDL there because of bad SDL audio on Wiz). What I fear is that no one wrote an OSS driver for audio codecs interfaced through OMAP3, not that I know exactly what's involved there.
 
Last edited by a moderator:
Exophase said:
dflemstr said:
Someone said a long time ago in one of those "Use the Pandora for an audio mixer" threads that the Pandora uses PulseAudio. So you can easily switch backends to OSS!

Oh god, PulseAudio. Maybe I should just rip the speakers out of mine.

PulseAudio is utter shit. Even when it actually works properly it still adds a ton of CPU overhead. Just what we want on our low power ARM devices, right?

It's not like using PulseAudio to wrap OSS even makes any sense. If it was just using straight OSS from the start everything would be very simple for everyone.

PulseAudio is utter shit for sure (just ask any ubuntu user....)
But remember that OSS3 was just known as "one process at a time", thus ESD, DMIX and such.
HOMM3 (loky version...) use OSS3, and if I have a firefox open, I have no sound playing that game which suck

Alsa solved that problem from the user perspective. Sure it's a mess to code, but sdl-alsa is there to the rescue.

And yeah, OSS4 is out for more than a year, fix the mixing problem while still being easy to use for coder. But is it included in the main-line kernel yet ? (honest question, I realy don't know)
 
Last edited by a moderator:
I'd switch over to OSS4 on my desktop in a heartbeat if it supported usb microphones. If it supports the pandora hardware I see no reason not to use it. Does it? Also some people were going to use a pandora as a music making wondermachine. Would OSS4 be better (less latency, better quality) or worse (hw support?) for them?
 
sebt3 said:
PulseAudio is utter shit for sure (just ask any ubuntu user....)
But remember that OSS3 was just known as "one process at a time", thus ESD, DMIX and such.
HOMM3 (loky version...) use OSS3, and if I have a firefox open, I have no sound playing that game which suck

Alsa solved that problem from the user perspective. Sure it's a mess to code, but sdl-alsa is there to the rescue.

ALSA has that problem too, it only supports mixing via hardware support, if the drivers also support it. As far as I understand it's probably for this reason that PulseAudio is used. I know that on my machine ALSA can't mix, and will lock the audio device entirely.

IMO it's much better to handle software mixing in the kernel, close to where the output is streamed to the device. This is especially the case for embedded, where often only one program will have the device open and this case can be optimized in the drivers. If it's done in user space through something like Pulse (or the systems you mentioned) then it'll always have to go through an additional layer.

In fact, with Pulse it's often even worse, because if your app does output to ALSA or OSS and not Pulse directly then everything has to go through yet another layer.

sebt3 said:
And yeah, OSS4 is out for more than a year, fix the mixing problem while still being easy to use for coder. But is it included in the main-line kernel yet ? (honest question, I realy don't know)

No, and I bet that does has something to do with historical bitterness towards no longer relevant licensing decisions. Some distros are offering it as options now. Open Pandora is in a position where they could push it forward, if they so desire.
 
Last edited by a moderator:
Ew, ALSA and sound mixing *shudders*
I've yet to figure out how to setup dmix properly (maybe it's not even possible on my hardware, I don't know, even though I wasted about 30h trying to make it work). I've been using JACK (with alsa plug) (considered pulseaudio but it was way more complicated) for mixing for about 2 years now and it works flawlessly. No lags or latency, nearly every software playing nice with it (Software that doesn't: Mumble, Firefox's internal video-player.) and the ability to route audio anywhere I want it easily :D
I'm definitely going to try to compile JACK for the Pandora (should work, Gentoo Portage lists it as unstable for arm)
 
Exophase said:
I give it a chance in 9.10 (Karmic) and it was terrible, even worse than it was on 9.04 (Jaunty). Latency was bad across the board and several programs either had choppy audio output (like flash in Firefox) or hung completely. I've read of several other people having severe problems with it as of Karmic.

I've been running 9.10 without the PA and Flash fix on several boxes including my 1000HE without any issues. My 1000HE is out helping out someone with their course work so I can't test to see how much PA hogs the CPU. I did have problems with PA until the latest Skype came out.

Fair point about running any thing that is resource hungry on a portable low resource device....

Just tested playing a mp3 on my n900 and PA sucks 15% on average *shudder*
 
Last edited by a moderator:
I'm really split when it comes to PA.

Yes, it consumes massive amounts of CPU relatively speaking; it takes roughly 1% of my CPU time on a 1GHz Celeron system I have (which isn't *that* horrendous but YMMV), but on the other hand we have per-application sound mixing, balancing, equalizers, sound filters, monitors, sinks, etc... which are really powerful features. I abuse PA's network streaming ability for different things, like combining the sound from my laptop, desktop and external MP3 player into one stream that gets sent to one set of 5.1 speakers; really useful, especially since you can "position" the streams when mixing them ("Ah, a sound from over there; my laptop's batteries are low"). And even though there aren't that many projects yet that use PA directly, we're starting to see some really interesting stuff, like projectM, where you can see that PA's features actually can be "used for good".

I usually use PA on a desktop PC, so my view of it is of course biased because of that, but as I said PA worked "fine" on an oldish Celeron PC.

What I tend to think when looking at the KDE Multimedia configuration page and having to choose my Phonon sound backend (Yet another abstraction layer! Gaah!) is that: There isn't really a good alternative to PA that beats it at everything I need. Yes, plain ALSA or OSS are (sometimes noticeably) faster and more performing, and with the default PA settings, they might give you better sound quality (/etc/pulse/daemon.conf: "resample-method=src-sinc-best-quality" recommended for every audiophile with a high-end CPU), but what other features do they offer me that I've grown to become used to in a modern desktop environment? Barely sound mixing, maybe digital IO if I'm lucky, equalizing via dubious plugins; nothing unified or standard, mind, and that's about it.

If I had to choose between using Windows Vista or MS DOS for my day-to-day life I'd use Vista (cholera or the plague... but you get my point) even though there probably are some drivers in MS DOS that give me faster hardware acceleration for certain things, because MS DOS lacks the abstraction that Vista has.

</monologue>

Also, random flamebait: If everyone would stop clinging to the past and instead would embrace PA, then maybe it'd get fixed, get modules for hardware mixing (look at the PA module API; It IS possible to do stuff like that) and we'd finally be able to drop ALSA and OSS as standalone sound APIs (yeah I know, ain't gonna happen any time soon)
 
PA worked fine on my hardware in Ubuntu 9.04, then I switched to Arch Linux, tried oss4, tried PA, but only ALSA seems to work, and it works great.

Again, I trust OP will use which ever system works best and let the abstractions do their job.
 
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).

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.

I don't know what this 1% CPU time number is about, given that it uses well over 15% on my 1.6GHz Atom. Maybe Ubuntu screwed things up somehow. Maybe PA was improved since. Maybe you're going to a native layer and I'm going to something else. I don't really know. But the way I see it, if you support OSSv4 as a REAL option then you can still easily go from OSS to PA while still maintaining the benefits PA offers. The same cannot be said for the other way around. And if you allow OSS as an option you can also allow a way to lock it and get real direct sound card access, which is even more desirable in those instances where you don't want to share anything and the user is willing to comply.

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.
 
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 :p
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.
 
Last edited by a moderator:
dflemstr said:
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.

You don't know that. In fact, it very well could happen. If not, this is still a good place to come up with the argument to make.

PA or not, last I was aware Pandora didn't have any OSS device. Now granted, this was in like, fall 2008, but I haven't heard of any push to change this.
 
Last edited by a moderator:
Exophase said:
PA or not, last I was aware Pandora didn't have any OSS device. Now granted, this was in like, fall 2008, but I haven't heard of any push to change this.
Nope, can't find any public OSS drivers for the TWL5030 (which I guess must be the chip that's being used...)
 
Last edited by a moderator:
B-ZaR said:
I'd switch over to OSS4 on my desktop in a heartbeat if it supported usb microphones. If it supports the pandora hardware I see no reason not to use it. Does it? Also some people were going to use a pandora as a music making wondermachine. Would OSS4 be better (less latency, better quality) or worse (hw support?) for them?
alsa will be supported at launch. oss probably won't be supported in all programs you'll want. maybe alsa with jack?

there are no wondermachines
 
Last edited by a moderator:
Exophase said:
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
Well, it's clear that you don't have any use for PulseAudio's unique features. That's fine. A lot of people don't have use for GUI. That's fine too. ;)

The fact that PulseAudio has received lots of developer support says to me there's a need out there for the features PulseAudio provides. Stuff like a brain-dead simple configuration of anything from networking sound to configuring Bluetooth headsets (and the profile in use). It also brings all these various API's together and filters them into a single API transparently.

And let's not so quickly forget that NetworkManager was bashed in the same way not two years ago, and now that its bugs have been mostly ironed out, and some very useful features written, there's not a whole lot people say against it. People only dislike something when it doesn't work. Once it works, then all of a sudden everyone doesn't want to toss it out with next Tuesday's garbage. :p
 
Last edited by a moderator:
Back
Top