Well I'm a true Scotsman, and a technical person and certainly agree with Lennart on this front. Don't know what that means overall :s

Really? Your system sucks then because on mine it works fine! Have you submitted a backtrace for this issue? Even a bug report?

If you haven't then the bug doesn't exist, plain and simple.

Well, on my system (4 year old core2duo) it sits between 0 and 1% even when playing...

Not heard of any problems here but is there a bug report about this?

I'm not experiencing any problems. It's been pretty stable for me for quite some time? What version have you been using?

If you even had a tiny clue about things, you'd realise how ridiculous this statement is. OSS is old news. The API is not going to help us move forward. Have you even seen some of the stuff from the latest Linux Plumbers conference? Paul "Jack/Ardour" Davis summary is probably the best one I've read about why OSS is not sufficient and these are decisions that were made years ago... where on earth do people get this "OSSv4 causes world peace and solves every problem ever" option from? They've clearly never actually *looked* at things for themselves that's for sure.

Yeah because that kind of code writes itself right? All we need to do is get everyone to catch a fairy at the bottom of their garden and then stuff it into their CD drive... the code will be there by morning!

There are probably about four people working on linux sound as a paid job... Lennart, Takashi, Jaroslav and Paul... Maybe a few other too, but typically in very specific disciplines/hardware, but certainly none of them are going to start working on OSS that's for sure. So where is this magical work going to come from?

This is us getting it right and this is that pain.

Yeah, because *my* computer is so shit it can only decode the DVD audio in real time and there isn't any way that it could possible decode say 20 seconds worth of the audio, and pump it into the audio layer in anything under 20 seconds right???

This is *exactly* the point I'm making when people here the word latency, they assume completely the wrong thing. You go on to say "As such you need to keep latency as low as practical"... which is where I switch off, as from this comment it's clear you've not read my posts, so I'll just ask you to read them again.

Now, like I say, you do not want high latencies at all times. Certain circumstances mean that this is simply not possible, e.g recording sound and playing it back or some other interactive sounds, but there are also a lot of applications where it certainly is a good thing.

And all this "windows has done this for years" crap people keep spouting, should read up about some of the "new" features in Windows 7 audio stack that are features PulseAudio has had for a long time! They are playing catchup.

This is why distros play an important job. Compiling your own kernel is a complex job that 90% of users shouldn't have to care about. Even with a shedloads of documentation, you still need to keep on top of kernel developments to ensure you're using the right options and the right approach. Ditto with configuring pulse. I don't deny that it's a complex beast to configure correctly, but that's why we have distros. Just like we vote in politicians to read policy and make decisions on our behalf (why everyone shouts "referendum" whenever anything vaguely complex comes up is beyond me - the people voting in referendums do not read the policy in question to make informed decisions - they read the red tops... insane), so we chose our distros to take care of this stuff for us. Users should not have to venture beyond a few ticky boxes.

And none of these problems were there before the Linux kernel, so obviously it's the one to *really* blame right?? Argument fail. :p

Well, not really. It could point to a documentation problem or it could be to do with certain distros aversion to getting involved with upstream projects as much as they could.

There are numerous problems being represented that are all grouped under the same heading, and that then informs your "all ... have a problem with PA". Like I've said already, the majority of the problems lie with most applications creative use of the ALSA client API (which make it impossible for us to compensate for), the drivers not supporting accurate timing information that is needed for timer based scheduling, or poorly integrated distro. None of these (bar the last one maybe) is a "pulseaudio problem" per se. There are other problems that *are* of course (bugs get everywhere) but it's totally unfair to PA to group things up like that.

To be honest, I've not looked much at this specifically (hence my original disclaimer!). I just know the support is there. You essentially just run paprefs and tick the right boxes and your devices should show up. I'll probably have a proper play with this sometime soon, so if you're interested, subscribe to my blog and I'll post something about it when I've got more info.

Flash also uses ALSA. I'm not sure why your version would be using /dev/dsp. Mine certainly uses ALSA.

What is a common problem on distros is installing 64 bit browsers but relying on 32 bit plugins.

When combined with PA under the default setup (ALSA redirected to PA), you need to also remember to install 32 bit versions of: libasound, alsa-plugins, libpulse. If you do not, then the firefox's use of ALSA will fail and (I'm guessing now as the source is closed and I can't look) Flash will fall back to OSS.

Like I say, the distros play a big part here. If this is the setup they distribute, they need to think about this kind of thing.

Also the 1 device per /dev/dsp can be solved by kernel 2.6.32 (maybe) + Fuse 2.0.x and osspd. More info here: http://www.kernel.org/pub/linux/kernel/people/tj/ossp/ when combined with a pulseaudio setup. It could be made to work without PA if someone wrote an appropriate proxy.

Just waiting for this kernel bug to be fixed: http://bugzilla.kernel.org/show_bug.cgi?id=14023

All that said, as OSS is disabled by defaul on Fedora, and other distros will follow suit soon, I suspect that most people will forget about OSS support before too long.

/me laughs at the way /. has trimmed the subject to add the Re: prefix :p

You cannot separate the mixing from the buffering like that. Consider two apps, both playing audio tracks (it will sound terrible but let's not think about that!). Both apps have fed 10 seconds into the buffer so they can "spin down" and save power. All well and good. So the output is mixed and fed to the device buffer with the highest possible latency it supports. Again, all good. Now the user suddenly skips a track on player A. What happens here is that we have to throw away the 10s of pre-mixed audio, keep Player B's audio but remix it to new content provided by player A's decoding of the next track. So the mix+buffer has to be kept together, so that the buffer from a given app is not thrown away until we known that it's spent. AFAIK, these buffers can be passed in to PA under zero-copy and are only copied when the audio is mixed and then dumped into the device buffer. i.e. it's very low overhead.

As for the "implemented in alsa" stuff, it sadly isn't really a valid comparison. If it *were* implemented in alsa, we'd first of all need some kind of daemon to run and handle this mixing for us. We'd need something that has exclusive control of the real underlying hardware so that it can disable interrupts on it and feed the data into the device buffers under it's timing control, regardless of whether applications start or close inbetween. In the end you'll just design PulseAudio all over again but call it "alsad" instead. So the whole exercise is rather pointless!

And as for the comments about representing sound controls in GUIs this is actually a pretty complex task, especially when you take the concept of flat volumes into consideration. For every app there are effectively three volumes kicking around but it will only ever make sense to show the user a single unified volume.

When it's back online (currently that service is down due to Trac basically not handling things!) this article should be insightful: http://0pointer.de/blog/projects/writing-volume-control-uis.html

And this is yet again, lumping all the problems of a distro at the door of PA without *any* specific justification other than it was there.

This is the problem of Linux development in my opinion: a little knowledge is a dangerous thing - e.g. knowing enough to know that there is something called pulseaudio installed and removing it makes things work ergo it is at fault as opposed to all the configuration and setup that is *supposed* to go part in parcel with it.

I'm not saying that the problem *wasn't* with pulse itself, it's just that all too often people jump to the conclusion that it is when really there is no evidence for or to the contrary.

Until a proper investigation shows where the problem really lies, I keep an open mind.

Well this is clearly a case where a bug needs to be fixed. A similar bug I had that lead to crashing was due to enigmail cocking up, even if I wasn't about to sign anything. In this case, chances are it's not even directly PAs fault, but rather some thing inbetween, e.g. libcanberra or similar, but without a full backtrace I can't comment further and say the bug is with the libpulse client or libcanberra.

If that's what you see, then your setup is wrong. Blame the distro or blame the close source crap that we can't fix.

I can use Firefox to watch a you tube video and play it out via my Bluetooth Hifi while listening to music on my built in card and move all those streams around at will. Ergo, the problem is with your setup, not PA. Complain to your distro.

Lag != Latency. Lag is the time between two things that should be synchronised, but are not. Latency is the time taken between something going in to a black box, and it coming out.

If there is a buffer of 20 seconds, and I completely fill that up right at the start, the data going in will have between 0 and 20 seconds latency. The lag is completely different and as we have no idea what we're supposed to be synchronised with, I cannot comment about what lag could or could not be in this case.

It's this general misunderstanding that means that statements like: "I simply cannot understand how you could think high latency is certainly good, thats simply never ever the case." so completely wrong.

I'm not suggesting that games etc should have a ridiculously high lag between a visual event/user input and a sound event. Clearly this wants as close to lag=0 as possible. But you should really also consider that for many applications and use cases, latency IS a good thing due to the power savings it introduces, and thus the longer battery life.

Power consumption in alsa: In order to enable this mode you need to disable interrupts and then deal with the filling of the audio buffers via some kind of timer mechanism. This approach also requires that the whole mixing buffers are rewritten when needed (this is across all applications). This needs some kind of central process to manage all the audio from all applications, or a "sound server". The likelihood of this even occurring has to be offset with the overhead of remixing etc etc. but the tradeoff is generally fine unless you are skipping forward/back in audio tracks all the time etc.

The argument about writing for the most common path is not one I'd personally agree with. You have to design the architecture to handle all the cases that will be thrown at it. Sure, maybe make the common case pipeline a clear run through your architecture, but you can't really do things fundamentally different in difference cases. Typically a problem occurs when something changes half way through, you cannot tear down your "special setup" and restart in "generic setup" without letting the user know with a pop and a click.

0 == no attenuation in my book, not mute. A volume of 0dB is pretty much the max it can be.

And -inf dB attenuation != mute either. My volume can be pretty near 0dB and I can still have the thing muted... If I hit mute twice, I don't want to lose track of what my volume was at! In my book, mute state handling should be totally separate to volume. How it's presented to the user via GUI tools is perhaps another question tho'.

The fact that audio cuts out when you switch to a TTY is the domain of console-kit. There used to be a way do disable it via HAL but as HAL is dead now, that no longer seems to work, but I'm sure there is another way to do it. It's basically tweaking the console kit policy.

Dude, I'm not talking about lag, I'm talking about latency. Latency is the time it takes from inserting the data into the buffer for it to be heard. Lag may be bad, but high latency is certainly good.

Mediatomb is a deamon in itself and it's a totally different use case than the UPnP support in PA, so please don't compare apples to oranges.

"next LTS (Hardy Heron) and boom... pulseaudio screwed it all up..."

Dude, Ubuntu's integration of PA in that version totally sucks. They didn't even try to get things right there and this then reflects badly on PA. Ubuntu have made a *lot* of mistakes with pulse and are continuing to do so, so please don't use this as the benchmark to judge.

We released Mandrvia around the same time with our first PA-by-default version, and it was received very well. So don't blaming the carpenter just because the stable boy left the door open while the horse bolted.