"I installed the 64-bit version on two AMD machines (one laptop and one desktop) and both of them have issues with random lockups after 10 minutes or so."
May well be https://bugzilla.redhat.com/show_bug.cgi?id=517625 , if they also have AMD graphics adapters. Try booting with pcie_aspm=off as a kernel parameter. If that helps, add a comment on the bug report to note that you have the same problem, with output of 'lspci -nn'.
Re:Most "Features" Have Nothing To Do With Fedora
on
Fedora 12 Beta Released
·
· Score: 2, Informative
Actually, most of the features described have been written mostly by Fedora contributors. The full release announcement text - https://fedoraproject.org/wiki/F12_Beta_Announcement - gives explicit credit for many of them.
Since it's Fedora's policy to contribute all possible work to upstream projects, of course other distributions benefit from this work. We don't play the game of having 'exclusive' features to trumpet in our distribution, we play the game of improving the F/OSS ecosystem for all. We don't really see that the fact that many other distributions will also benefit from this work doesn't mean they're important new features for Fedora users.
Of the features mentioned in the Slashdot story:
X.org improvements: Red Hat employee and Fedora project member Ben Skeggs is the major upstream contributor to the nouveau driver and implemented all the nouveau improvements described. Red Hat employees and Fedora project members Dave Airlie and Jerome Glisse are two of the major contributors to the ati/radeon driver and implemented many of the radeon improvements described. RH employees and FP members Adam Jackson and Kristian Hogsborg are major contributors to the intel driver. Adam and Dave also do substantial work on the X server itself and implemented the default support for multi-display spanning.
NetworkManager improvements: these were implemented by Red Hat employee and Fedora project member Dan Williams.
openfwwf: this is upstream work. We are, however, the first distribution to include it by default, as far as I'm aware (do correct me if I'm wrong).
Virtualization work: this is all contributed by the Red Hat employees and Fedora project members who make up the virtualization team, including Mark McLoughlin, Cole Robinson, and Justin Forbes.
Moblin integration: this is a co-operation between the Fedora project and the Moblin project. Fedora itself serves as part of the foundations of the upstream Moblin project (they do draw on other distributions as well for certain things).
GNOME Shell: maintainer and leading contributor is Red Hat employee and Fedora project member Owen Taylor.
oh, yeah, the days are going to be fricking *empty* around here. That's just the QA calendar, BTW, doesn't cover release engineering or development team's tasks. To translate, we'll do a full set of installation validation tests on the release candidate images, and weekly blocker bug review meetings at which the entire list of bugs marked as final release blockers are reviewed and managed. I spent most of today managing the blocker bug list, ensuring fixes were being worked on, confirming fixes, and clarifying the impacts of certain issues.
In the four days since the beta freeze was ended, around 200 bugfix updates have already landed in the F12 tree, including the whole KDE 4.3.2. But, yep, we're not doing any work on F12, you're perfectly right. Man, we're lazy.
Um. Nothing was really *broken* that I can think of, but F12 does improve the situation here. Systems with multiple monitors connected will boot in span mode (display spanned across all connected displays) by default (as long as the driver uses RandR 1.2; that's the case for intel, ati and nouveau, the default drivers for 95% of all graphics hardware out there), and spanning multiple monitors work on NVIDIA cards (with the default open source nouveau driver) out of the box now (in F11 it wouldn't work in span mode unless you made a manual xorg.conf tweak). Those are the major differences to F11 in this area.
"Really? Only last week I was looking at NetworkManager - and it didn't support this - even in the development version... based upon the information I could find."
Note there's two types of Bluetooth tethering (two possible protocols) - DUN and PAN. Some mobile devices can only do one or the other, some can do both. Only PAN has been implemented so far, there's no DUN support yet unfortunately. That's coming, probably for F13.
https://fedoraproject.org/wiki/Bug_info_kernel_sound contains the instructions for filing good reports on sound problems. Note it links to a similar page for PulseAudio, with instructions to follow if the issue seems PA-related.
it's worth noting that the most important ALSA bits - the drivers themselves - are in the kernel package. The packages with 'alsa' in their name are just user-space support stuff, and them being up to date is somewhat less important. The most important thing to know is which alsa-drivers version is in the current kernel of the distro you run, that's the vital bit.
it follows that if you want to try a newer ALSA, try finding a testing build of a later kernel for your distro, or just re-build the alsa-drivers bit, you don't need to bother rebuilding the rest, it's unlikely the fix for any driver bug is in any other bit of ALSA.
that sounds like a sampling rate bug (I think we've seen this in cases where the driver was providing bogus sampling rate information). have you filed a bug on it where I can ask for the appropriate information to investigate?
that was unfortunately just on the other side of the 'common enough use case to account for in gnome-volume-control' line. The idea of the new g-v-c is to present sufficiently commonly used functions in a simple and understandable interface (whereas the idea of ALSA mixer applications is to present every possible function in an interface which looks like it was designed by a crack-addled monkey:>). basically the way to configure this is to bypass gnome-volume-control. In F11 we provided gst-mixer (which was really the old gnome-volume-control) for this purpose, in F12 you'll have to use something else, like alsamixer . These apps still expose the full ALSA mixer interface, so you can set up things like this if you need to. To control the input channels you run something like 'alsamixer -c0 -Vcapture'.
if by 'sleep' you mean suspend, that's not a general problem. Or, at least, it Works For Me (tm), on a Sony laptop (not renowned as a source of super-friendly hardware). I can suspend / resume as much as I like, no audio troubles.
Yeah, it's a FESco decision, but on the other hand, if Lennart had fr'instance said 'of course we shouldn't push it by default, what are you, _nuts_?' it probably wouldn't have happened.
"Yeah, I get that application developers need to be pushed along at some point, but the application-facing aspect of PA and the kernel/driver-facing aspect can be thought of as separate efforts."
But if we don't have people actually using PA by default - i.e. hook applications into it - it's not getting any use, and none of the bugs would get exposed. It'd be 'there' by default but not actually being used at all.
"Fedora also made it default far before it was ready, which is not the developer's fault."
Given that Lennart is in fact the Fedora PulseAudio packager, you could say it partly is.:) But see an earlier comment of mine for an explanation of why PA was made default at the point it was.
"Seriously, software mixing is a trivial algorithm and there's no reason why you shouldn't be able to open/dev/dsp or something and simply pipe several outputs to it."...and what happens when they're at different sampling rates?
Wow, clearly you've really thought carefully about this problem. I'm impressed.
"Yes, and that is the problem. I don't want to configure anything, I just want sound to come out of my speakers. I don't want to have to try out 2^40 different combinations of buttons and switches scattered over a dozen different tabs in order to make that happen."
And, let me get this straight, you thought things were _better_ with ALSA? Have you *looked* at alsamixer lately? Or, y'know,/etc/asound.conf , where you had to poke around to enable S/PDIF output? Or/etc/modprobe.conf , where you had to poke around to pick a default output device? The whole _point_ of PA is to present genuinely necessary configuration choices - like, y'know, whether you want analog or digital output, and which of multiple sound devices should be the default - in a very easy interface. Which was one of the major _failings_ of the previous situation.
(Given your post, it's ironic that one of the *other* major criticisms of PA is 'it doesn't let me tweak RidiculouslyObscureAlsaKnob Foo! It sucks!')
"Strawman. Plus a thoroughly unjustified strike at petrus4, with the cherry being a thoroughly patronising attitude. Let me be the first to call you on all three of these things."
Nope. Not guilty, on any of the above. Follow the thread of the conversation. It was not a discussion of general issues, it was a discussion of a specific post where a commenter extrapolated directly from 'my audio doesn't work' to 'PulseAudio is, overall, a terrible idea'. petrus4 was defending this. hence my post is entirely legitimate. If he was _not_ defending this, you'd have a point.
On the wider topic, actually, you're interestingly close to the mark. PulseAudio was intentionally, and by agreement between multiple distributions, introduced when we knew it still had functional regressions compared to the previous situation.
Interestingly, exactly the same thing happened with ALSA when it replaced OSS/Free. This has been explained before, but to rehash...
Why? Because we needed to pick something to fix the damn mess. At the point when this was done, every distribution was using plain ALSA, plus esd for GNOME and/or arts for KDE messing up the works (or, in some cases, distros trying to use esd on KDE...). It was fairly obvious that no-one cared about esd and arts was going to be dying too, though I believe at that point no-one knew what was going to replace it (turned out to be Phonon). There were _several_ potential replacement sound server candidates around. PulseAudio (previously PolypAudio) had been around for years; it was available on most distros, but virtually no-one ran it because going out and choosing to install a minor-league sound server is not on most people's daily lists of Really Good Ideas. It was painfully obvious that the current situation was nowhere near good enough in terms of handling things real people actually want to do with sound (for instance, enabling S/PDIF output on many cards was a gigantic pain; ditto analog surround output; ditto dealing with multiple sound devices; that's just the low-hanging fruit). It was equally painfully obvious that none of that was going to get fixed in ALSA (as I said earlier in the thread, people who will yell loudly that it all should be fixed in ALSA are ten-a-penny; people willing to actually write ALSA code, not so much).
The problem is that it's very hard to move forward from that situation without picking a solution. No alternative sound server was never going to get critical mass by relying on optional installations. As long as it was optional, no application or desktop was going to care about properly integrating it, it would be very difficult to get necessary fixes made in the kernel and so on. So the distributions together decided to pick PulseAudio and implement it as standard essentially just to make it very clear where the future was going and provide the necessary impetus for other work to get done.
If we hadn't done that, we'd probably _still_ be stuck on plain ALSA, looking more stupid with every passing year.
Was this for the best in this best of all possible worlds? Probably not, but it was the best available of a quite bad set of choices. Note that distributions implemented the change differently: Fedora did it first and has no 'off switch' because part of the point of Fedora is to drive ultimately beneficial change in desktop Linux at the cost of temporary issues (this is hardly unique to PulseAudio). Ubuntu did it a little later for safety. Mandriva went quite early but has an off switch in the draksound utility, as MDV tends to focus on working as well as possible at any given point in time.
Look at the bright side: a huge amount of work has been done since PA was 'promoted' to improve ALSA, improve desktops (it's hard to look at gnome-volume-control in Fedora 12 and *not* say it's a vast improvement on the pre-PA era) and improve application integration. We now actually have a more or less coherent sound story across all Linux distributions, which we _never_ had before. Everyone knows where they stand and where things are going, and we're getting a damn sight more productive work on audio done than was the case before. That's the reasoning behind how things were done.
I really don't see how the context changes anything. The sentence I quoted is perfectly clear that "abject denial" refers to "Stutters and skips are the norm, audio systems that worked previously no longer do", and as I said this is absolutely not at all true.
I'm really curious - I haven't tried OSS4 yet, but the one thing I haven't ever gotten working on linux is the following setup:
Analog/Digital speakers, with a USB headset.
Can OSS4 handle USB sound? Can it mix multiple streams? Does it have an easy way to switch between input/output devices?
Pulse gave me hope for the above. Then fell flat on its face. I've never been able to get dmix to handle this setup, and ALSA doesn't seem to do it.
I hate to say it as a linux fanboy, but I want audio like Windows. Right-click on my audio button, and in two clicks I can choose my input and output devices, and all sounds are seamlessly mixed to make that happen. I don't really care about network audio, or any of the other fancy-ass shit that pulseaudio is supposed to do.
Really, I use a desktop, and I have multiple audio sources and devices. Mix them automatically, and give me a quick gui control for which piece of hardware should be handling each. That's all I really want.
I've been trying (every now and then, but for longer than I care to remember) to achieve the same thing except with analog speakers and a bluetooth headset. No luck yet...
First poster: in case you're not sure (I can't quite tell), dmix mixes multiple *streams* - different apps playing audio, essentially - to a single output device. It has nothing to do with handling multiple output devices.
dmix works only with ALSA-native output, it doesn't mix OSS-type audio. PA can mix ALSA-native, PA-native or esd-native streams, but not OSS-native. If any of the apps you're trying to use outputs OSS-style (direct to/dev/dsp as a file), neither dmix nor PA will be able to mix it by default. If it will run through padsp (Pulse's wrapper for OSS-style audio) or ALSA's similar wrapper (I forget what that's called), mixing the output may work. Otherwise, both ALSA/dmix and PA should be able to handle your mixing needs.
Choosing an output device you can do with both ALSA and PA, but it's a heck of a lot simpler with PA. With ALSA you need to identify which driver each of your devices uses, then use the index= parameter for those modules in/etc/modprobe.conf (or/etc/modprobe.d/somefile.conf , depending on your distro's conventions). Something like:
would ensure that the USB audio device (or _one_ of multiple USB audio devices, if you have more than one; you wouldn't get to pick which) became the default output device, and an onboard Intel HDA adapter became the secondary output device, at each boot. If you don't specify index parameters, whichever module happens to load first gets to be the default device (yes, this is the wonderful ALSA design that's getting so much praise in this thread).
With PA, you use a Pulse-compliant mixer (gnome-volume-control, pavucontrol, whatever) to pick a default output device graphically. Nice and simple. I can't tell you what problem you're having with PA without more detail than 'fell flat on its face'.
Second poster: Complete Bluetooth audio support only landed in PulseAudio in June or so, IIRC. After the last round of distro releases. Fedora 12, Mandriva 2010 and Ubuntu 9.10 include the easy Bluetooth audio support, earlier distributions don't.
"if the application is not performing its' stated task, to provide audio playback, then it is a bad design."
ah. So if I can find any system, anywhere in the world, on which audio playback does not work in FreeBSD, you will admit that FreeBSD is 'a bad design'?
"He's qualified to comment on the fact that his sound isn't working."
Sure. It's called a bug report. Believe it or not, in the days before PulseAudio, sometimes people's sound didn't work either. Imagine that! Sometimes life sucks.
Extrapolating from 'my sound isn't working' to 'the entire architecture of PulseAudio, which I am about to make a wild-ass guess at describing, is utterly wrong' is what he's not qualified to do. Which is exactly what the post you're replying to said. What's hard to understand?
"So to sum it up, for someone like me a better Linux/PA/Bluetooth experience would be great. I've actually wanted to dig into the code and see how I can improve things, but I've never done that kind of programming before nor have I had the time lately to learn/do it."
With a coming-gen distro (Ubuntu 9.10, Fedora 12, Mandriva 2010) any Bluetooth headset you pair with should simply show up in PA as an output device like any other. Nothing else required.
actually (depending what version exactly 9.04 has) it probably does but isn't exposing that via any UI. 9.10 (and Fedora 12 and Mandriva 2010) include this functionality in pavucontrol. MDV and Fedora have it in gnome-volume-control too, I'm not sure which g-v-c Ubuntu 9.10 is shipping.
I didn't realize you were going from an S/PDIF output on the audio card, I figured you were actually trying to use audio via a video card's HDMI output (which is actually possible, as long as the underlying ALSA driver for that video card is present and working).
Slashdot Mirror
"I installed the 64-bit version on two AMD machines (one laptop and one desktop) and both of them have issues with random lockups after 10 minutes or so."
May well be https://bugzilla.redhat.com/show_bug.cgi?id=517625 , if they also have AMD graphics adapters. Try booting with pcie_aspm=off as a kernel parameter. If that helps, add a comment on the bug report to note that you have the same problem, with output of 'lspci -nn'.
http://lwn.net/Articles/355542/
Actually, most of the features described have been written mostly by Fedora contributors. The full release announcement text - https://fedoraproject.org/wiki/F12_Beta_Announcement - gives explicit credit for many of them.
Since it's Fedora's policy to contribute all possible work to upstream projects, of course other distributions benefit from this work. We don't play the game of having 'exclusive' features to trumpet in our distribution, we play the game of improving the F/OSS ecosystem for all. We don't really see that the fact that many other distributions will also benefit from this work doesn't mean they're important new features for Fedora users.
Of the features mentioned in the Slashdot story:
X.org improvements: Red Hat employee and Fedora project member Ben Skeggs is the major upstream contributor to the nouveau driver and implemented all the nouveau improvements described. Red Hat employees and Fedora project members Dave Airlie and Jerome Glisse are two of the major contributors to the ati/radeon driver and implemented many of the radeon improvements described. RH employees and FP members Adam Jackson and Kristian Hogsborg are major contributors to the intel driver. Adam and Dave also do substantial work on the X server itself and implemented the default support for multi-display spanning.
NetworkManager improvements: these were implemented by Red Hat employee and Fedora project member Dan Williams.
openfwwf: this is upstream work. We are, however, the first distribution to include it by default, as far as I'm aware (do correct me if I'm wrong).
Virtualization work: this is all contributed by the Red Hat employees and Fedora project members who make up the virtualization team, including Mark McLoughlin, Cole Robinson, and Justin Forbes.
Moblin integration: this is a co-operation between the Fedora project and the Moblin project. Fedora itself serves as part of the foundations of the upstream Moblin project (they do draw on other distributions as well for certain things).
GNOME Shell: maintainer and leading contributor is Red Hat employee and Fedora project member Owen Taylor.
Right, we'll be doing nothing. Nothing, that is, except this:
http://poelstra.fedorapeople.org/schedules/f-12/f-12-quality-tasks.html
oh, yeah, the days are going to be fricking *empty* around here. That's just the QA calendar, BTW, doesn't cover release engineering or development team's tasks. To translate, we'll do a full set of installation validation tests on the release candidate images, and weekly blocker bug review meetings at which the entire list of bugs marked as final release blockers are reviewed and managed. I spent most of today managing the blocker bug list, ensuring fixes were being worked on, confirming fixes, and clarifying the impacts of certain issues.
In the four days since the beta freeze was ended, around 200 bugfix updates have already landed in the F12 tree, including the whole KDE 4.3.2. But, yep, we're not doing any work on F12, you're perfectly right. Man, we're lazy.
Um. Nothing was really *broken* that I can think of, but F12 does improve the situation here. Systems with multiple monitors connected will boot in span mode (display spanned across all connected displays) by default (as long as the driver uses RandR 1.2; that's the case for intel, ati and nouveau, the default drivers for 95% of all graphics hardware out there), and spanning multiple monitors work on NVIDIA cards (with the default open source nouveau driver) out of the box now (in F11 it wouldn't work in span mode unless you made a manual xorg.conf tweak). Those are the major differences to F11 in this area.
"Really? Only last week I was looking at NetworkManager - and it didn't support this - even in the development version... based upon the information I could find."
Well, take a look at http://blogs.gnome.org/dcbw/2009/07/10/unwire-with-networkmanager/ .
Note there's two types of Bluetooth tethering (two possible protocols) - DUN and PAN. Some mobile devices can only do one or the other, some can do both. Only PAN has been implemented so far, there's no DUN support yet unfortunately. That's coming, probably for F13.
"Couldn't agree more with the sentiment, but as a KDE user, I'd recommend the RC of opensuse instead."
or, for the exact same amount of money, you could try both and see which you prefer :)
https://fedoraproject.org/wiki/Bug_info_kernel_sound contains the instructions for filing good reports on sound problems. Note it links to a similar page for PulseAudio, with instructions to follow if the issue seems PA-related.
it's worth noting that the most important ALSA bits - the drivers themselves - are in the kernel package. The packages with 'alsa' in their name are just user-space support stuff, and them being up to date is somewhat less important. The most important thing to know is which alsa-drivers version is in the current kernel of the distro you run, that's the vital bit.
it follows that if you want to try a newer ALSA, try finding a testing build of a later kernel for your distro, or just re-build the alsa-drivers bit, you don't need to bother rebuilding the rest, it's unlikely the fix for any driver bug is in any other bit of ALSA.
Doesn't read that way to me.
Hardware mixing is actually *less* common now than it used to be, since there's less need for it (because Windows does software mixing).
that sounds like a sampling rate bug (I think we've seen this in cases where the driver was providing bogus sampling rate information). have you filed a bug on it where I can ask for the appropriate information to investigate?
that was unfortunately just on the other side of the 'common enough use case to account for in gnome-volume-control' line. The idea of the new g-v-c is to present sufficiently commonly used functions in a simple and understandable interface (whereas the idea of ALSA mixer applications is to present every possible function in an interface which looks like it was designed by a crack-addled monkey :>). basically the way to configure this is to bypass gnome-volume-control. In F11 we provided gst-mixer (which was really the old gnome-volume-control) for this purpose, in F12 you'll have to use something else, like alsamixer . These apps still expose the full ALSA mixer interface, so you can set up things like this if you need to. To control the input channels you run something like 'alsamixer -c0 -Vcapture'.
if by 'sleep' you mean suspend, that's not a general problem. Or, at least, it Works For Me (tm), on a Sony laptop (not renowned as a source of super-friendly hardware). I can suspend / resume as much as I like, no audio troubles.
Yeah, it's a FESco decision, but on the other hand, if Lennart had fr'instance said 'of course we shouldn't push it by default, what are you, _nuts_?' it probably wouldn't have happened.
"Yeah, I get that application developers need to be pushed along at some point, but the application-facing aspect of PA and the kernel/driver-facing aspect can be thought of as separate efforts."
But if we don't have people actually using PA by default - i.e. hook applications into it - it's not getting any use, and none of the bugs would get exposed. It'd be 'there' by default but not actually being used at all.
"Fedora also made it default far before it was ready, which is not the developer's fault."
Given that Lennart is in fact the Fedora PulseAudio packager, you could say it partly is. :) But see an earlier comment of mine for an explanation of why PA was made default at the point it was.
That's a different version of OSS. Linux kernel only ever had what's generally referred to as OSS/Free, which never had software mixing capabilities.
http://lwn.net/Articles/355542/
"Seriously, software mixing is a trivial algorithm and there's no reason why you shouldn't be able to open /dev/dsp or something and simply pipe several outputs to it." ...and what happens when they're at different sampling rates?
Wow, clearly you've really thought carefully about this problem. I'm impressed.
"Yes, and that is the problem. I don't want to configure anything, I just want sound to come out of my speakers. I don't want to have to try out 2^40 different combinations of buttons and switches scattered over a dozen different tabs in order to make that happen."
And, let me get this straight, you thought things were _better_ with ALSA? Have you *looked* at alsamixer lately? Or, y'know, /etc/asound.conf , where you had to poke around to enable S/PDIF output? Or /etc/modprobe.conf , where you had to poke around to pick a default output device? The whole _point_ of PA is to present genuinely necessary configuration choices - like, y'know, whether you want analog or digital output, and which of multiple sound devices should be the default - in a very easy interface. Which was one of the major _failings_ of the previous situation.
(Given your post, it's ironic that one of the *other* major criticisms of PA is 'it doesn't let me tweak RidiculouslyObscureAlsaKnob Foo! It sucks!')
"Strawman. Plus a thoroughly unjustified strike at petrus4, with the cherry being a thoroughly patronising attitude. Let me be the first to call you on all three of these things."
Nope. Not guilty, on any of the above. Follow the thread of the conversation. It was not a discussion of general issues, it was a discussion of a specific post where a commenter extrapolated directly from 'my audio doesn't work' to 'PulseAudio is, overall, a terrible idea'. petrus4 was defending this. hence my post is entirely legitimate. If he was _not_ defending this, you'd have a point.
On the wider topic, actually, you're interestingly close to the mark. PulseAudio was intentionally, and by agreement between multiple distributions, introduced when we knew it still had functional regressions compared to the previous situation.
Interestingly, exactly the same thing happened with ALSA when it replaced OSS/Free. This has been explained before, but to rehash...
Why? Because we needed to pick something to fix the damn mess. At the point when this was done, every distribution was using plain ALSA, plus esd for GNOME and/or arts for KDE messing up the works (or, in some cases, distros trying to use esd on KDE...). It was fairly obvious that no-one cared about esd and arts was going to be dying too, though I believe at that point no-one knew what was going to replace it (turned out to be Phonon). There were _several_ potential replacement sound server candidates around. PulseAudio (previously PolypAudio) had been around for years; it was available on most distros, but virtually no-one ran it because going out and choosing to install a minor-league sound server is not on most people's daily lists of Really Good Ideas. It was painfully obvious that the current situation was nowhere near good enough in terms of handling things real people actually want to do with sound (for instance, enabling S/PDIF output on many cards was a gigantic pain; ditto analog surround output; ditto dealing with multiple sound devices; that's just the low-hanging fruit). It was equally painfully obvious that none of that was going to get fixed in ALSA (as I said earlier in the thread, people who will yell loudly that it all should be fixed in ALSA are ten-a-penny; people willing to actually write ALSA code, not so much).
The problem is that it's very hard to move forward from that situation without picking a solution. No alternative sound server was never going to get critical mass by relying on optional installations. As long as it was optional, no application or desktop was going to care about properly integrating it, it would be very difficult to get necessary fixes made in the kernel and so on. So the distributions together decided to pick PulseAudio and implement it as standard essentially just to make it very clear where the future was going and provide the necessary impetus for other work to get done.
If we hadn't done that, we'd probably _still_ be stuck on plain ALSA, looking more stupid with every passing year.
Was this for the best in this best of all possible worlds? Probably not, but it was the best available of a quite bad set of choices. Note that distributions implemented the change differently: Fedora did it first and has no 'off switch' because part of the point of Fedora is to drive ultimately beneficial change in desktop Linux at the cost of temporary issues (this is hardly unique to PulseAudio). Ubuntu did it a little later for safety. Mandriva went quite early but has an off switch in the draksound utility, as MDV tends to focus on working as well as possible at any given point in time.
Look at the bright side: a huge amount of work has been done since PA was 'promoted' to improve ALSA, improve desktops (it's hard to look at gnome-volume-control in Fedora 12 and *not* say it's a vast improvement on the pre-PA era) and improve application integration. We now actually have a more or less coherent sound story across all Linux distributions, which we _never_ had before. Everyone knows where they stand and where things are going, and we're getting a damn sight more productive work on audio done than was the case before. That's the reasoning behind how things were done.
I really don't see how the context changes anything. The sentence I quoted is perfectly clear that "abject denial" refers to "Stutters and skips are the norm, audio systems that worked previously no longer do", and as I said this is absolutely not at all true.
I'm really curious - I haven't tried OSS4 yet, but the one thing I haven't ever gotten working on linux is the following setup: Analog/Digital speakers, with a USB headset. Can OSS4 handle USB sound? Can it mix multiple streams? Does it have an easy way to switch between input/output devices? Pulse gave me hope for the above. Then fell flat on its face. I've never been able to get dmix to handle this setup, and ALSA doesn't seem to do it. I hate to say it as a linux fanboy, but I want audio like Windows. Right-click on my audio button, and in two clicks I can choose my input and output devices, and all sounds are seamlessly mixed to make that happen. I don't really care about network audio, or any of the other fancy-ass shit that pulseaudio is supposed to do. Really, I use a desktop, and I have multiple audio sources and devices. Mix them automatically, and give me a quick gui control for which piece of hardware should be handling each. That's all I really want.
I've been trying (every now and then, but for longer than I care to remember) to achieve the same thing except with analog speakers and a bluetooth headset. No luck yet...
First poster: in case you're not sure (I can't quite tell), dmix mixes multiple *streams* - different apps playing audio, essentially - to a single output device. It has nothing to do with handling multiple output devices.
dmix works only with ALSA-native output, it doesn't mix OSS-type audio. PA can mix ALSA-native, PA-native or esd-native streams, but not OSS-native. If any of the apps you're trying to use outputs OSS-style (direct to /dev/dsp as a file), neither dmix nor PA will be able to mix it by default. If it will run through padsp (Pulse's wrapper for OSS-style audio) or ALSA's similar wrapper (I forget what that's called), mixing the output may work. Otherwise, both ALSA/dmix and PA should be able to handle your mixing needs.
Choosing an output device you can do with both ALSA and PA, but it's a heck of a lot simpler with PA. With ALSA you need to identify which driver each of your devices uses, then use the index= parameter for those modules in /etc/modprobe.conf (or /etc/modprobe.d/somefile.conf , depending on your distro's conventions). Something like:
options snd-usb-audio index=0 options snd-hda-intel index=1
would ensure that the USB audio device (or _one_ of multiple USB audio devices, if you have more than one; you wouldn't get to pick which) became the default output device, and an onboard Intel HDA adapter became the secondary output device, at each boot. If you don't specify index parameters, whichever module happens to load first gets to be the default device (yes, this is the wonderful ALSA design that's getting so much praise in this thread).
With PA, you use a Pulse-compliant mixer (gnome-volume-control, pavucontrol, whatever) to pick a default output device graphically. Nice and simple. I can't tell you what problem you're having with PA without more detail than 'fell flat on its face'.
Second poster: Complete Bluetooth audio support only landed in PulseAudio in June or so, IIRC. After the last round of distro releases. Fedora 12, Mandriva 2010 and Ubuntu 9.10 include the easy Bluetooth audio support, earlier distributions don't.
"if the application is not performing its' stated task, to provide audio playback, then it is a bad design."
ah. So if I can find any system, anywhere in the world, on which audio playback does not work in FreeBSD, you will admit that FreeBSD is 'a bad design'?
wow, way to paint yourself into a corner, skippy.
"He's qualified to comment on the fact that his sound isn't working."
Sure. It's called a bug report. Believe it or not, in the days before PulseAudio, sometimes people's sound didn't work either. Imagine that! Sometimes life sucks.
Extrapolating from 'my sound isn't working' to 'the entire architecture of PulseAudio, which I am about to make a wild-ass guess at describing, is utterly wrong' is what he's not qualified to do. Which is exactly what the post you're replying to said. What's hard to understand?
"So to sum it up, for someone like me a better Linux/PA/Bluetooth experience would be great. I've actually wanted to dig into the code and see how I can improve things, but I've never done that kind of programming before nor have I had the time lately to learn/do it."
With a coming-gen distro (Ubuntu 9.10, Fedora 12, Mandriva 2010) any Bluetooth headset you pair with should simply show up in PA as an output device like any other. Nothing else required.
actually (depending what version exactly 9.04 has) it probably does but isn't exposing that via any UI. 9.10 (and Fedora 12 and Mandriva 2010) include this functionality in pavucontrol. MDV and Fedora have it in gnome-volume-control too, I'm not sure which g-v-c Ubuntu 9.10 is shipping.
I didn't realize you were going from an S/PDIF output on the audio card, I figured you were actually trying to use audio via a video card's HDMI output (which is actually possible, as long as the underlying ALSA driver for that video card is present and working).