"No, they're not being fixed because it's extremely difficult to fix something in ALSA as a result of a piece of software (PA) that is pretending to be ALSA."
Would you please stop drivelling? Also, please stop your one-man King Canute crusade against reality? The crackling / stuttering issues experienced by some people in Fedora 11 and equivalent distros were _all_ cases of kernel driver probelms being exposed by PulseAudio functionality. Dozens of bugs with hundreds of comments in each were filed, which together covered many different instances of this kind of bug. The vast majority of these were fixed, others continue to be fixed as ALSA development goes along.
"Pulseaudio has been default on Fedora since Fedora 8. Tell me, how long does it take to get it right?"
well, that's kind of a stupid argument. NVIDIA video cards have been around since the 1990s and we didn't get those 'right' yet. ALSA was the default for the last eight years and that ain't right either. Neither GNOME nor KDE are apparently 'right' or else they wouldn't both be getting major revisions. I could go on, but you get the point. Software has this habit of getting improved and revised over time. It's never 'right'.
so your modest proposal is that Linux stop 'aping Windows' as you put it and start aping FreeBSD instead?
What would be the point of that? FreeBSD is doing a good job of being FreeBSD. You like it, go use it and stop ear-bashing. I really don't know why people like you *make* posts like this. Do you really think it's the way to change anything? Do you honestly think Fedora developers or Ubuntu developers or anyone else is going to read a load of random vitriol on a comment thread somewhere and go 'oh my god, we've been doing it wrong all along! This guy knows the way and the light!"
Ironically, your message would make far more sense if it were talking about plain ALSA than about PA. ALSA is the configuration nightmare. PA makes it all a lot better.
generally speaking you should be able to configure just about everything you need to in pavucontrol. though it depends what version of PA you're working with, and how badly broken your distribution's implementation of it is.
As I mentioned in an earlier comment, there are several distributions which are specifically designed to give you a good audio creation environment out of the box. Ubuntu Studio is probably the most well-known:
but there are others. If you want to do audio production, you do not want to be using PA. You want to be using JACK. This may change in future, but that's the situation right now. Ubuntu Studio's documentation on getting going with JACK: https://help.ubuntu.com/community/UbuntuStudio/JackQuickStart
the OP was trying to do something rather unusual, hence the 'target audience' argument is invalidated. The target audience you're thinking of isn't likely to be trying to run mpd from a console.
Well, if the software calls on a driver, and the driver has a bug and crashes, then it's the fault of the driver. Therefore, fix the driver. Simple! Why is this so controversial?
Because if the issue is really there then we need to be looking at solving it at that level and not bunging yet another in a long line of sound servers into the mix and making the problem even worse and then denying any responsibility.
But...that's not at all what is happening. What is happening is exactly what you said. Where PA exposes kernel bugs, those bugs are being fixed. No-one ever said otherwise. All Lennart said was that sometimes the bugs are in ALSA, not PA. He then *specifically* said that does _not_ mean they should not be fixed, or that he's not interested in fixing them. Yet you choose to draw that conclusion anyway...
The note that it is not entirely open source post-dates those news posts and is still accurate to the latest versions of OSS, as far as I'm aware. The source code does not include the bits that are described as proprietary in the note I quoted.
The full text is interesting (though I didn't quote it for reasons of brevity) because it makes clear that 4front don't see this as a one-off, but as an _ongoing state of affairs_: "We reserve the right to include some "closed source" drivers only in our binary distribution if the hardware manufacturers refuse to give the programming specs without NDA. Our policy is to promote open source but not to enforce it."
Thus even if they ever do manage to make an OSS release that's entirely open source, there's no guarantee any future OSS release will be. Which is another reason it's very unlikely to be accepted into the Linux kernel and hence be used by any significant distribution.
"I'd like to try this out. I did a brief search for PA streaming via UPnP to a PS3 but didn't find anything. Could you point me in the right direction? "
Fedora and Mandriva have the best PA implementations, according to the developers. Fedora 10 has a pretty old PulseAudio, by the standards of development (PA development is quite rapid, in partly to implement all the bug fixes people in this thread insist Lennart isn't interested in writing). F11 is better, and F12 will be rather better than that. F12 Beta comes out tomorrow. Mandriva 2010, which is nearly released, should be good also.
"Examples: My desktop system requires careful balancing of the VIA DXS, PCM and Master sliders to get enough output to drive my speakers and avoid clipping in the digital side of the system."
By all means file a bug. Contrary to your later assertions, we (myself, in co-ordination with Lennart and Jaroslav) have developed a process for reporting this kind of issue in a way which provides the correct information for us to efficiently adjust things so that ALSA exposes an interface to PA which allows it to properly control your volume. Cue celebrations. See https://bugzilla.redhat.com/show_bug.cgi?id=497966#c1 for instructions.
"2. Pulse blameshifts all it's problems to apps and drivers. Ok, apps (open source ones anyway) will eventually get fixed. Drivers won't."
Saying the problem is in the kernel and it should be fixed there is not blame shifting, it is correctly identifying the problem.
A rather large hole is blown in your theory that drivers won't be fixed by the fact that they have been, are being, and will be fixed. Red Hat pays Jaroslav Kysela, and Novell pays Takashi Iwai, to do exactly this. Jaroslav, working together with Lennart, has fixed rather a lot of ALSA driver bugs that were exposed by PA already. They continue to work on fixing more.
"Say, Microsoft gets a bug report which actually covers several distinct bugs. If it then gets closed as "NOTABUG: do a proper bug report, noob!""
Microsoft? Bug report?
Where do I go to file bug reports with Microsoft? Last time I checked, the only option available was a black hole. You fill in your issue, and you get a page that says 'thank you for submitting your issue'.
Was it filed as a valid bug? Was it filed as NOTABUG: do a proper bug report, noob!? Was it set on fire and thrown into a lake? I don't have a freaking clue, because Microsoft's bug tracking system is not public, so I have no way to tell what the hell they did with it. I think that is just a tiny little mite worse than the case where you get a prompt reply from the _actual developer of the component you're complaining about_ explaining politely exactly how to file your issue properly.
"Or switch to something that works without having to write bug reports according to form X7Y-2Z and then waiting for several months to see the bug closed (and 10 more bugs found in the meantime)."
Um. The OP filed a bug report covering five entirely separate problems, and multiple commenters then followed up talking about *other* different issues.
You will not find any bug tracker for any project anywhere in the world which would accept that as a useful way to try and track bugs. When do we set the bug to FIXED? When the first issue's fixed? The second? The third? The fourth? All five? How do we track what information is needed from who for what issue?
Lennart politely replied that several of the issues were duplicates of other reports, pointing out which. He asked for the remaining valid issues to be filed as separate reports so they could be properly tracked. Suggesting this is akin to "having to write bug reports according to form X7Y-2Z" is just ludicrous.
"Like, say, OSS4. Or even ALSA."
ALSA's bug tracker is essentially ignored these days, as they do not have the development manpower to track it.
any interface which presents over thirty different sliders on many cards, many of which aren't actually really sliders you can / should interact with, is not a very good idea.
"It's a shame that I can't use my Creative USB audio card on practically any Linux distro or OS X b/c of the lack of driver support."
Unfortunately, Creative decided the perfectly good USB audio standard which every other USB audio device under the frickin' sun uses is not good enough for them, and used an entirely different interface for their USB audio devices. Which they then didn't give anyone any specifications for, so no-one could write a driver.
I _think_ the recent spec release which is leading to a usable X-Fi ALSA driver covered the USB hardware too, so a working driver may be available soon / already in recent enough ALSA releases. But I haven't followed that particular wrinkle very closely.
Any USB audio device which actually uses the USB audio standard should work fine with the snd-usb-audio driver. I've used quite a lot of such devices, and haven't found one that doesn't work yet.
You missed quite a lot: http://en.wikipedia.org/wiki/PulseAudio#Features isn't a bad overview, right now. Colin or Lennart wrote a good 'why PulseAudio?' page, I think, but can't find it right now.
One major point is that saying "The 2nd point is of course entirely moot for those who only have 1 sound card" isn't _exactly_ accurate. 'Sound device' is a better phrase to use, because the modern world has moved on rather substantially from what you may be thinking of as 'sound cards'. Any Bluetooth audio device is a 'sound card'. Any USB headset is a 'sound card'. Any USB speaker is a 'sound card'. Many webcams are 'sound cards' (they have mics, these days). Any USB handset for pretending you're using a real phone when you use Skype or whatever is a 'sound card'. Any other computer running PulseAudio can be a 'sound card'. With the recent Rygel integration, any UPnP audio client can be a 'sound card'...
that's actually a case where PA is making things much better. with raw ALSA you have to either flip an obscurely-named mixer switch (which is actually a driver hack...) or create a custom asoundrc to do S/PDIF output. With recent PulseAudio and gnome-volume-control or pavucontrol, you can just select an S/PDIF output profile from a drop-down box in the volume control application (in g-v-c, go to the 'hardware' tab, select the device you want to do S/PDIF output on, and pick the appropriate choice from the drop-down box labelled 'Profile:').
This isn't in the last round of distro releases (Fedora 11 / Ubuntu 9.04 / Mandriva 2009.1), admittedly. It's in the next - well, it's definitely in Fedora 12, and should be in Ubuntu 9.10 and MDV 2010 if their stacks are recent enough. But even before it was fully-implemented in PA, it didn't make the situation any *worse*: you could make it work with PA using much the same tweaks you had to use with ALSA.
"Very true. However when you try (tens of thousands of times) to point out politely where problems are, with detailed debugging steps, and at times even code patches, with evidence of how many less broken apps act broken after the changes are applied, and all tens of thousands of posts are viciously attacked by the developer, then clearly it is time for another tactic."
I notice the above paragraph appears to be missing approximately 10,000 references.
Can't speak for anyone else, but _I_ test PulseAudio with a Chaintech AV-710 S/PDIF output to a Firestone Audio Spitfire DAC, to Firestone Cute headphone amp, to Grado HF-1 headphones. That's about a $800 headphone stack right there.
"PulseAudio reimplementing ALSA to look like ALSA is just plain silly"
What the _hell_ are you talking about?
"Talking about each new version of the kernel and PulseAudio to fix issues now after all these years when sound and even ALSA for many people have started to work is laughable. History, and the Linux desktop world's inability to learn from the past, is against PulseAudio but Lennart seems determined to bludgeon it in."
I take it you're working hard on contributing all the things that PulseAudio is doing to ALSA, then?
That's the point that annoys me the post about this whole discussion - comment thread trolls who will bang on and on about how PA is a terrible idea and everything should be done in ALSA are ten a penny, yet people willing to contribute actual code to ALSA are rarer than unicorn shit. ALSA was effectively dormant for a decade - with barely enough contributors to write basic drivers for new devices, never mind implementing important new features - and when someone shows up with an actual plan to address the situation, all you can do is whine about how he's doing it all wrong. Then quit whining and do it 'right', and if your solution's a good one, it will be adopted. Development isn't a democracy. Whining about how things should be done differently is _not helping_.
" This includes making the ALSA drivers better at reporting which jacks are plugged in and things like that.
Then fix ALSA or use OSS before you start retrofitting bullshit sound servers that breaks a lot of things. "
Except that the bugs in ALSA weren't exposed until something - i.e. PulseAudio - started using them. And the bugs exist in multiple different drivers on multiple different cards. If we don't get PulseAudio into actual usage on actual hardware, there's no way of finding the bugs to fix them, and nothing ever gets better.
Slashdot Mirror
Use Skype 2.1 (with native Pulse support), not Skype 2.0 (with patented Crack-Addled(TM) audio implenetation).
"No, they're not being fixed because it's extremely difficult to fix something in ALSA as a result of a piece of software (PA) that is pretending to be ALSA."
Would you please stop drivelling? Also, please stop your one-man King Canute crusade against reality? The crackling / stuttering issues experienced by some people in Fedora 11 and equivalent distros were _all_ cases of kernel driver probelms being exposed by PulseAudio functionality. Dozens of bugs with hundreds of comments in each were filed, which together covered many different instances of this kind of bug. The vast majority of these were fixed, others continue to be fixed as ALSA development goes along.
Take a stroll through https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=crackl&classification=Fedora&product=Fedora&bug_status=CLOSED .
"Pulseaudio has been default on Fedora since Fedora 8. Tell me, how long does it take to get it right?"
well, that's kind of a stupid argument. NVIDIA video cards have been around since the 1990s and we didn't get those 'right' yet. ALSA was the default for the last eight years and that ain't right either. Neither GNOME nor KDE are apparently 'right' or else they wouldn't both be getting major revisions. I could go on, but you get the point. Software has this habit of getting improved and revised over time. It's never 'right'.
so your modest proposal is that Linux stop 'aping Windows' as you put it and start aping FreeBSD instead?
What would be the point of that? FreeBSD is doing a good job of being FreeBSD. You like it, go use it and stop ear-bashing. I really don't know why people like you *make* posts like this. Do you really think it's the way to change anything? Do you honestly think Fedora developers or Ubuntu developers or anyone else is going to read a load of random vitriol on a comment thread somewhere and go 'oh my god, we've been doing it wrong all along! This guy knows the way and the light!"
I mean, honestly.
Ironically, your message would make far more sense if it were talking about plain ALSA than about PA. ALSA is the configuration nightmare. PA makes it all a lot better.
generally speaking you should be able to configure just about everything you need to in pavucontrol. though it depends what version of PA you're working with, and how badly broken your distribution's implementation of it is.
Why do you assume that PulseAudio is the reason you don't get any sound over HDMI? Did you get any sound over HDMI in 9.04 when you disabled PA?
As I mentioned in an earlier comment, there are several distributions which are specifically designed to give you a good audio creation environment out of the box. Ubuntu Studio is probably the most well-known:
http://ubuntustudio.org/
but there are others. If you want to do audio production, you do not want to be using PA. You want to be using JACK. This may change in future, but that's the situation right now. Ubuntu Studio's documentation on getting going with JACK: https://help.ubuntu.com/community/UbuntuStudio/JackQuickStart
"You say its unfair to blame PA for problems, but most of those problems WERE NOT THERE prior to PA. I say its totally fair to blame PA."
Yes, they were. You not knowing they were there is not the same thing as them not being there.
the OP was trying to do something rather unusual, hence the 'target audience' argument is invalidated. The target audience you're thinking of isn't likely to be trying to run mpd from a console.
Well, if the software calls on a driver, and the driver has a bug and crashes, then it's the fault of the driver. Therefore, fix the driver. Simple! Why is this so controversial?
Because if the issue is really there then we need to be looking at solving it at that level and not bunging yet another in a long line of sound servers into the mix and making the problem even worse and then denying any responsibility.
But...that's not at all what is happening. What is happening is exactly what you said. Where PA exposes kernel bugs, those bugs are being fixed. No-one ever said otherwise. All Lennart said was that sometimes the bugs are in ALSA, not PA. He then *specifically* said that does _not_ mean they should not be fixed, or that he's not interested in fixing them. Yet you choose to draw that conclusion anyway...
The note that it is not entirely open source post-dates those news posts and is still accurate to the latest versions of OSS, as far as I'm aware. The source code does not include the bits that are described as proprietary in the note I quoted.
The full text is interesting (though I didn't quote it for reasons of brevity) because it makes clear that 4front don't see this as a one-off, but as an _ongoing state of affairs_: "We reserve the right to include some "closed source" drivers only in our binary distribution if the hardware manufacturers refuse to give the programming specs without NDA. Our policy is to promote open source but not to enforce it."
Thus even if they ever do manage to make an OSS release that's entirely open source, there's no guarantee any future OSS release will be. Which is another reason it's very unlikely to be accepted into the Linux kernel and hence be used by any significant distribution.
"I'd like to try this out. I did a brief search for PA streaming via UPnP to a PS3 but didn't find anything. Could you point me in the right direction? "
http://0pointer.de/blog/projects/oh-nine-sixteen.html
Fedora and Mandriva have the best PA implementations, according to the developers. Fedora 10 has a pretty old PulseAudio, by the standards of development (PA development is quite rapid, in partly to implement all the bug fixes people in this thread insist Lennart isn't interested in writing). F11 is better, and F12 will be rather better than that. F12 Beta comes out tomorrow. Mandriva 2010, which is nearly released, should be good also.
"Examples: My desktop system requires careful balancing of the VIA DXS, PCM and Master sliders to get enough output to drive my speakers and avoid clipping in the digital side of the system."
By all means file a bug. Contrary to your later assertions, we (myself, in co-ordination with Lennart and Jaroslav) have developed a process for reporting this kind of issue in a way which provides the correct information for us to efficiently adjust things so that ALSA exposes an interface to PA which allows it to properly control your volume. Cue celebrations. See https://bugzilla.redhat.com/show_bug.cgi?id=497966#c1 for instructions.
"2. Pulse blameshifts all it's problems to apps and drivers. Ok, apps (open source ones anyway) will eventually get fixed. Drivers won't."
Saying the problem is in the kernel and it should be fixed there is not blame shifting, it is correctly identifying the problem.
A rather large hole is blown in your theory that drivers won't be fixed by the fact that they have been, are being, and will be fixed. Red Hat pays Jaroslav Kysela, and Novell pays Takashi Iwai, to do exactly this. Jaroslav, working together with Lennart, has fixed rather a lot of ALSA driver bugs that were exposed by PA already. They continue to work on fixing more.
"Say, Microsoft gets a bug report which actually covers several distinct bugs. If it then gets closed as "NOTABUG: do a proper bug report, noob!""
Microsoft? Bug report?
Where do I go to file bug reports with Microsoft? Last time I checked, the only option available was a black hole. You fill in your issue, and you get a page that says 'thank you for submitting your issue'.
Was it filed as a valid bug? Was it filed as NOTABUG: do a proper bug report, noob!? Was it set on fire and thrown into a lake? I don't have a freaking clue, because Microsoft's bug tracking system is not public, so I have no way to tell what the hell they did with it. I think that is just a tiny little mite worse than the case where you get a prompt reply from the _actual developer of the component you're complaining about_ explaining politely exactly how to file your issue properly.
"Or switch to something that works without having to write bug reports according to form X7Y-2Z and then waiting for several months to see the bug closed (and 10 more bugs found in the meantime)."
Um. The OP filed a bug report covering five entirely separate problems, and multiple commenters then followed up talking about *other* different issues.
You will not find any bug tracker for any project anywhere in the world which would accept that as a useful way to try and track bugs. When do we set the bug to FIXED? When the first issue's fixed? The second? The third? The fourth? All five? How do we track what information is needed from who for what issue?
Lennart politely replied that several of the issues were duplicates of other reports, pointing out which. He asked for the remaining valid issues to be filed as separate reports so they could be properly tracked. Suggesting this is akin to "having to write bug reports according to form X7Y-2Z" is just ludicrous.
"Like, say, OSS4. Or even ALSA."
ALSA's bug tracker is essentially ignored these days, as they do not have the development manpower to track it.
any interface which presents over thirty different sliders on many cards, many of which aren't actually really sliders you can / should interact with, is not a very good idea.
"It's a shame that I can't use my Creative USB audio card on practically any Linux distro or OS X b/c of the lack of driver support."
Unfortunately, Creative decided the perfectly good USB audio standard which every other USB audio device under the frickin' sun uses is not good enough for them, and used an entirely different interface for their USB audio devices. Which they then didn't give anyone any specifications for, so no-one could write a driver.
I _think_ the recent spec release which is leading to a usable X-Fi ALSA driver covered the USB hardware too, so a working driver may be available soon / already in recent enough ALSA releases. But I haven't followed that particular wrinkle very closely.
Any USB audio device which actually uses the USB audio standard should work fine with the snd-usb-audio driver. I've used quite a lot of such devices, and haven't found one that doesn't work yet.
You missed quite a lot: http://en.wikipedia.org/wiki/PulseAudio#Features isn't a bad overview, right now. Colin or Lennart wrote a good 'why PulseAudio?' page, I think, but can't find it right now.
One major point is that saying "The 2nd point is of course entirely moot for those who only have 1 sound card" isn't _exactly_ accurate. 'Sound device' is a better phrase to use, because the modern world has moved on rather substantially from what you may be thinking of as 'sound cards'. Any Bluetooth audio device is a 'sound card'. Any USB headset is a 'sound card'. Any USB speaker is a 'sound card'. Many webcams are 'sound cards' (they have mics, these days). Any USB handset for pretending you're using a real phone when you use Skype or whatever is a 'sound card'. Any other computer running PulseAudio can be a 'sound card'. With the recent Rygel integration, any UPnP audio client can be a 'sound card'...
that's actually a case where PA is making things much better. with raw ALSA you have to either flip an obscurely-named mixer switch (which is actually a driver hack...) or create a custom asoundrc to do S/PDIF output. With recent PulseAudio and gnome-volume-control or pavucontrol, you can just select an S/PDIF output profile from a drop-down box in the volume control application (in g-v-c, go to the 'hardware' tab, select the device you want to do S/PDIF output on, and pick the appropriate choice from the drop-down box labelled 'Profile:').
This isn't in the last round of distro releases (Fedora 11 / Ubuntu 9.04 / Mandriva 2009.1), admittedly. It's in the next - well, it's definitely in Fedora 12, and should be in Ubuntu 9.10 and MDV 2010 if their stacks are recent enough. But even before it was fully-implemented in PA, it didn't make the situation any *worse*: you could make it work with PA using much the same tweaks you had to use with ALSA.
"Very true. However when you try (tens of thousands of times) to point out politely where problems are, with detailed debugging steps, and at times even code patches, with evidence of how many less broken apps act broken after the changes are applied, and all tens of thousands of posts are viciously attacked by the developer, then clearly it is time for another tactic."
I notice the above paragraph appears to be missing approximately 10,000 references.
Can't speak for anyone else, but _I_ test PulseAudio with a Chaintech AV-710 S/PDIF output to a Firestone Audio Spitfire DAC, to Firestone Cute headphone amp, to Grado HF-1 headphones. That's about a $800 headphone stack right there.
"PulseAudio reimplementing ALSA to look like ALSA is just plain silly"
What the _hell_ are you talking about?
"Talking about each new version of the kernel and PulseAudio to fix issues now after all these years when sound and even ALSA for many people have started to work is laughable. History, and the Linux desktop world's inability to learn from the past, is against PulseAudio but Lennart seems determined to bludgeon it in."
I take it you're working hard on contributing all the things that PulseAudio is doing to ALSA, then?
That's the point that annoys me the post about this whole discussion - comment thread trolls who will bang on and on about how PA is a terrible idea and everything should be done in ALSA are ten a penny, yet people willing to contribute actual code to ALSA are rarer than unicorn shit. ALSA was effectively dormant for a decade - with barely enough contributors to write basic drivers for new devices, never mind implementing important new features - and when someone shows up with an actual plan to address the situation, all you can do is whine about how he's doing it all wrong. Then quit whining and do it 'right', and if your solution's a good one, it will be adopted. Development isn't a democracy. Whining about how things should be done differently is _not helping_.
" This includes making the ALSA drivers better at reporting which jacks are plugged in and things like that.
Then fix ALSA or use OSS before you start retrofitting bullshit sound servers that breaks a lot of things. "
Except that the bugs in ALSA weren't exposed until something - i.e. PulseAudio - started using them. And the bugs exist in multiple different drivers on multiple different cards. If we don't get PulseAudio into actual usage on actual hardware, there's no way of finding the bugs to fix them, and nothing ever gets better.