Bug Description

Run both of these at the same time:
gst-launch-0.10 audiotestsrc ! pulsesink
gst-launch-0.10 audiotestsrc ! alsasink

If your default sound device does not support hardware mixing, the second command will fail. ALSA cannot use the device while PulseAudio is using it, and this affects a lot of applications.

Note that if you run the commands the other way around, alsalib will use dmix, and then so will pulseaudio, so there is not as much of a problem this way around (except for the fact that dmix and PA are doing the same job, and you can not control the ALSA-using apps' volumes and routing with PA.)

Then, install the package "libasound2-plugins", as it contains the required "pcm_pulse" and "ctl_pulse" plugins.

Note, too, that there are some applications that fail with ALSA->Pulse:

SDL* seems to hang with neverball, but that is fixed by installing the PulseAudio backend for SDL (libsdl1.2debian-pulseaudio), which will replace the default ALSA backend.
WINE has its own issues with regards to device selection, which I don't know a remedy for.
Skype* also has its own problems, but these aren't fixable by us and should not block us, though should be given some consideraton.

Thanks for the useful link, Anders. To my mind, we're not only facing a bug — it's a regression actually, and as such should be treated as very important. It's nice to be on the cutting edge of progress and use latest inventions like PulseAudio in our favoured distro (though my experience of PulseAudio doesn't let me call it a great and welcome invention), but actually breaking things that DID work otherwise is surely completely unacceptible.

The new default pulseaudio in Hardy does not work with many non-Gnome programs, not just Skype. I am worried that everyone (Ubuntu, Alsa, Pulse, Wine) is not on the same page. Will try cross-posting bug information.
I am concerned for myself because I use Dragon NaturallySpeaking in Wine as an input mechanism, and that program works poorly for me now.

On my system, the problem seems to have vanished. I have occasionally rebooted the system, and decided not to kill pulseaudio after boot to test things a bit. To my astonishment, sound works flawlessly, even in skype, games, etc.

Flashplugin in Firefox sometimes locks sound to itself (producing the very same behaviour as described in the bugreport), but after closing the problematic page everything works again.

I know that by Launchpad rules my report is sufficient to close this bug (as I am the original reporter), but I think it's wise to wait till at least one more person confirms that the problem is gone.

Thanks for pointing this simple test out, Roberto — they don't sound simultaneously. Skype (and aplay, vlc, all stuff like that) are useless unless I close the page with a YouTube video in Firefox (simply pausing or stopping the video doesn't make no good). But anyway, after closing that page ALSA stuff starts sounding again, which was absolutely not the case when I first reported this bug. There is some progress anyway.

By the way, YouTube is not the only good test for this issue: having a video running (or even paused) in Totem effectively blocks ALSA sound as well. At this point I revoke my statement about this problem having been resolved. :)

Confirmed. Skype does not work at all on Ubuntu 8.04, and no matter how i configure its sound device, it doesn't work. 'padsp' doesn't change anything, either.

While this might be Skype's fault, it seems that Pulseaudio has existed for at least a year now, and at least for a year there have been complaints about Skype+PA not working, all over the web. I'm not sure if PA should be included in a stable release. I have no idea how i'm supposed to make Skype phonecalls now - downgrade to 7.10? I'd rather not, especially since this is supposed to become an LTS (read: extremely stable) release.

Ulrich, Skype is not the only issue with PulseAudio (though one of the most annoying ones). Including PulseAudio in the coming LTS release doesn't look too wise to me either, but it's included and we'll have to live with it anyway.

A temporarily workaround was proposed earlier in this bugreport: issue
killall pulseaudio
in console. This switches PulseAudio off (until the next GDM restart), allowing dmix to be the audio mixer, which solves the audio problems.

Unfortunately, upstream PulseAudio team's position is that PulseAudio is completely allright, and instead all those applications that don't work well are broken (wine, Skype, ALSA, VLC, the list may continue). It is thus highly unlikely that this bug will be resolved ever in the thinkable future.

Will also enable alsa redirection for pulse audio, at least per user, and may be a solution for the problem.

I'm using Hardy x86_64, and, sadly, libasound2-plugins is not avaliable for 32 bits apps like Skype ( https://bugs.launchpad.net/bugs/182731 ). I'd like to know if this works for 32 bit Hardy users, though. Anyone tested?

If it works, then setting alsa redirection to PulseAudio by default may be a fix for this bug... at least for the cases where libasound2-plugins are avaliable. Why not to make this change?

If setting this command it don't work, maybe there's something really broken with pulseaudio... I don't know... just my opinion.

Maybe a "tracker" bug should be opened for collect all issues related with pulseaudio. Most of them can be fixed or workarounded, but a tracker bug is really useful for checking opened bugs easily. At least with bugzilla (I don't know how launchpad manages this) the tracker bugs has all related marked as blockers

install and run pavucontrol.
apps that use pulseaudio will appear in pavucontrol when making sound, and those that do should all work together.
any apps that dont appear in pavucontrol will not work with any apps that do.

i think the best idea is to look for and report individual applications that dont use pulseaudio by default (so dont appear in pavucontrol) in individual bug reports, rather than doing confusing bug reports about incompatibilities between various applications, and not knowing which app is the broken one. Then you can focus on what the real bugs are.
eg for vlc: bug #208579 (fix included)
for mpd: bug #192735 (fix included)
for audacious: bug#175536 (easy to fix)
programs using sdl: bug #203158 (fix included)

this is the way to make things smooth for the release

skype doesnt work very well at the moment, lets all go and nag skype about it in their forums.

Josh, thank you for the perfect illustration of the upstream PulseAudio team position.

I repeat: there's NOTHING WRONG with Skype, aplay, oolite and any other application that relies on ALSA. They work with ALSA, they work in any other distribution, they worked well in Gutsy, so having to "fix" them to work in Hardy is actually a REGRESSION BUG in Hardy itself. This is what the upstream Skype team says, and in my opinion, they are perfectly right.

With Skype team saying that Skype is not broken so PA should be fixed (and they're right) and PulseAudio team saying that Skype is broken and should be fixed(they're perfectly wrong, but Ubuntu team seems to share their opinion) we are never going to have all the applications (including old games etc.) working in Ubuntu ever again.

I believe that applications should be fixed, as Josh pointed, considering that the goal is to have PulseAudio really as the "standard" way to go. If PulseAudio is being consolidated, soon or later, they'll have to be changed. So those fixes would be for accomplishing the goal, and not because "the programs are broken".

But I also believe that ALSA emulation should be provided as default and work flawlessly for this transition, since not all packages will suddenly support PulseAudio. This doesn't seem to be the reality in the moment, though. libasound2-plugins is not installed as default on Hardy (and there's not even an working package for 32 bits apps in x86_64 - https://bugs.launchpad.net/ubuntu/+source/alsa-plugins/+bug/182731 ).

I've read that, in some cases, like wine, the ALSA implementation was making wrong assumptions about the hardware - which prevented working correctly using PulseAudio's alsa emulation. In this case, PulseAudio's team position seems to make sense for me - why would they emulate a behavior to support bad written code, making assumptions that wouldn't work even on some instances of "real" hardware? I don't know if it's Skype case, but if it is, then it should be fixed by them - just the same way as they should fix if some people were having problems because their soundcard doesn't have an "A" or "B" non-standard feature (like a mixer channel). Wine team already said they're taking care of this ( http://www.winehq.org/?issue=344#Wine%20/%20Pulseaudio%20issues )

And while they don't fix, the "real" soundcard is accessible to the ALSA relying applications when no program is using the PulseAudio's stream (at least in my computer). The problem is that some programs (like flashplugin-nonfree, on Firefox, and other one which I don't remember the name) likes to "hold for them" the audio stream, and, when this happens, there's no sound avaliable for the non-PulseAudio applications.

So, the important question to the bug: isn't there a "selfish audio application" making this problem happen in your machines? On my machine, Skype and Wine works fine - but only when there's not another program playing through PulseAudio.

Roberto, you make a perfect point and anybody having any common sense is bound to agree with you. Answering your question, on my machine it's flashplugin-nonfree that causes troubles, not freeing up sound until I close the browser alltogether.

And I think ALSA emulation would better be more complete, so that PA-enabled programs don't block sound from not-PA-enabled ones. It's a real pity to miss Skype calls or some notifications via aplay while watching a movie in Totem, for example.

You both make perfectly valid points, but I think you don't put the stress exactly where you should, so... sorry for the spam:

1) The ideal situation would be that all applications have native PulseaAudio output, to take advantage of it's great features.
Corollary 1a. Bugs in any application's PA module are the application's fault, and should be fixed in the application. This minimizes effort and cruft, and maximizes the opportunities for future development of PA.
Corollary 1b. If this isn't true _now_ for an application, it can _only_ happen for future versions of it. Which means that only applications that i) already have PA support or ii) will add it in the future can be in this ideal situation.

2) The practical situation is that there will always be applications that don't have native PA support. In particular, many users will need (for too many reasons to cite here) to run an application like this. Often this is because they _need_ to use an old, not-still-developed application or version of it. That last part is important: even if application X is still worked on, if the user _needs_ an older version (say, because the new ones don't work, or is only 64 bit, or, like Skype, is developed primarily on Windows), they will need it supported. And there are always legacy applications.
Corollary 2a. Support for ALSA/OSS/etc is by definition _legacy_ support, for applications that won't work with PA.
Corollary 2b. We have this compatibility layer _because_ users _need_ to use things that don't fall into the ideal situation above, _and_ because if we don't have this compatibility PA will not see widespread use, developers will not add PA support in the future, and we'll get even further away from the ideal situation.
Corollary 2c. Even if a legacy app. is broken, PA _needs_ to support it and work. This is important enough and hard enough to agree with that it deserves a re-statement:

We don't want PulseAudio to have ALSA support. We don't care about ALSA in particular. We want PulseaAudio to have support for ALSA-only _applications_. Read that again:

== We want PulseaAudio to have support for ALSA-only _applications_, not ALSA per-se. ==

(This applies for OSS and any other compatibility layer.) Whether or not these apps are broken _totally_ irrelevant! The compatibility layers are there, by definiton, for applications that are _not_ supported with PulseAudio. If their developers cared, they'd have added PA support anyway, and we wouldn't need the compatibility layer.

If someone can run, say, Skype on ALSA (despite its brokenness) and they can't with PA, they won't use PulseAudio. We NEED such apps to be usable, so that people will use Pulseaudio, so that current developers have an incentive to add PulseAudio support. I know it's difficult, and I know it takes developer time, and I know they work for free, and I know the best thing would be to shut up and send a patch. But that doesn't change the truth of it.

As noted, running pulseaudio through dmix is almost certainly a bad idea. Which means that, short of disabling pulseaudio by default (not a great idea one week before release as it would leave us with the converse problem of re-testing everything without pulseaudio), any fix for this needs to happen in alsa-lib rather than in pulseaudio.

Leaving the ubuntu-8.04 milestone in place, but in practice we need to get a pretty high degree of confidence, pretty quickly, in any proposed fix in order to get it in on time.

If all the Ubuntu desktop distros, Kubuntu, Xubuntu etc all used PulseAudio, this wouldn't be a problem to solve. However, since only Ubuntu, Gobuntu, and UbuntuStudio use pulseaudio for the desktop, things are a lot more difficult.

As Steve has stated, this needs to be done in alsa-lib/libasound2. However, not as the default device, as explained above.

An asoundrc configuration could be created for applications to use the pulse plugin, however not all applications either allow the selection of a custom asoundrc config in their UI or implement alsa support in such a way that using asoundrc configs is impossible.

Then there is the problem of these applications being used by people who don't use pulseaudio, which rules out per application configuration for using pulseaudio.

I think the best bet at this stage in the release, is user education/documentation, and mention something in the release notes about the current situation WRT audio.

Having Ubuntu 8.04 LTS actually work (apps play sounds at the same time) seems to be more important than maintaining perfect cross-variant package elegance on this one package.

Why not introduce an "alsa-pulse" package that (provides: alsa-lib; conflicts: alsa-lib; depends: pulseaudio) that consists of alsa-lib with pulse audio as the default device? Include that in the pulseaudio variants and the existing lib in the non-pulse variants.

I really don't think we can leave 8.04 in its current state, there are
far too many ALSA-using apps that people are going to wonder why
they're not working while they have Rhythmbox paused or whatever.

Steve, Luke is suggesting that this should be fixed directly in
alsalib. As I understood your comment, you meant that, for example,
the ALSA configuration setting pulse to be the default device should
be included in the /package/ alsa-lib. What did you mean?

And if there is a problem with just including a default ALSA
configuration, please can you update the original description.

I was using the /etc/asound.conf in Intrepid and sound was working correctly, but after recent update, flash is not playing any sound if I have other apps playing sound. Flash just start and hangs. If I stop all the apps using the pulseaudio, then it works.

Luke Yelavich a écrit :
> Just to let you know that in intrepid, there is now 0.9.10-2ubuntu6. If
> you could try that and make sure all is ok, that would be appreciated.
I installed pulseaudio 0.9.10-2ubuntu6 and related libs and latest
alsa-utils alsa-plugins and libs but it doesn't change anything for me.

Luke, I had the the latest 0.9.10-2ubuntu6 along with other updates on the system and that is when I found this issue. So after downgrading alsa-utils and alsa-plugins, which didn't work I downgraded pulseadudio and found that my setup worked again.

The thing I have not tried is to see which build of pulseaudio broke things since i went strait to 0.9.10-2ubuntu2 from 0.9.10-2ubuntu6. If i had to guess, I think it is the 0.9.10-2ubuntu4 build that changed something.

1. Kill pulseaudio, either by using "killall pulseaudio" or "pulseaudio -i"
2. Remove all .pulse files from your home directory, "rm -r ~/.pulse*"
3. Move any .asoundrc files away to a temporary directory, of if you have nothing in them that you want to keep, delete them.
4. Restart pulseaudio, either by rebooting, logging out and back in, or running "pulseaudio -D --log-target=syslog"

Then let me know if you can get sound at all from any pulseaudio and alsa application.

I tried what you suggested and still not working correctly. If I start the flash first, then sound works, but it gets hold of the sound card and no app that uses pulseaudio works. If I start app which uses pulseaudio first, then flash does not work. I am on 64-bit version.

----------------------------------------
> From: <email address hidden>
> To: <email address hidden>
> Date: Mon, 29 Sep 2008 02:28:16 +0000
> Subject: Re: [Bug 198453] Re: Default ALSA device must use PulseAudio, otherwise ALSA applications may fail
>
> Could you please try to do the following:
>
> 1. Kill pulseaudio, either by using "killall pulseaudio" or "pulseaudio -i"
> 2. Remove all .pulse files from your home directory, "rm -r ~/.pulse*"
> 3. Move any .asoundrc files away to a temporary directory, of if you have nothing in them that you want to keep, delete them.
> 4. Restart pulseaudio, either by rebooting, logging out and back in, or running "pulseaudio -D --log-target=syslog"
>
> Then let me know if you can get sound at all from any pulseaudio and
> alsa application.
>
> Thanks.
>
> --
> Default ALSA device must use PulseAudio, otherwise ALSA applications may fail
> https://bugs.launchpad.net/bugs/198453
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in PulseAudio sound server: Confirmed
> Status in “alsa-lib” source package in Ubuntu: Fix Released
> Status in “alsa-plugins” source package in Ubuntu: Fix Released
> Status in “pulseaudio” source package in Ubuntu: Confirmed
> Status in alsa-lib in Ubuntu Hardy: Incomplete
> Status in alsa-plugins in Ubuntu Hardy: Incomplete
> Status in pulseaudio in Ubuntu Hardy: Invalid
>
> Bug description:
> Steps to reproduce:
>
> Run both of these at the same time:
> gst-launch-0.10 audiotestsrc ! pulsesink
> gst-launch-0.10 audiotestsrc ! alsasink
>
> If your default sound device does not support hardware mixing, the second command will fail. ALSA cannot use the device while PulseAudio is using it, and this affects a lot of applications.
>
> Note that if you run the commands the other way around, alsalib will use dmix, and then so will pulseaudio, so there is not as much of a problem this way around (except for the fact that dmix and PA are doing the same job, and you can not control the ALSA-using apps' volumes and routing with PA.)
>
>
> Resolution:
>
> Follow http://pulseaudio.org/wiki/PerfectSetup#ALSAApplications
> i.e. install /etc/asound.conf with:
>
> pcm.pulse {
> type pulse
> }
> ctl.pulse {
> type pulse
> }
> pcm.!default {
> type pulse
> }
> ctl.!default {
> type pulse
> }
>
> Then, install the package "libasound2-plugins", as it contains the required "pcm_pulse" and "ctl_pulse" plugins.
>
> Note, too, that there are some applications that fail with ALSA->Pulse:
>
> SDL* seems to hang with neverball, but that is fixed by installing the PulseAudio backend for SDL (libsdl1.2debian-pulseaudio), which will replace the default ALSA backend.
> WINE has its own issues with regards to device selection, which I don't know a remedy for.
> Skype* also has its own problems, but these aren't fixable by us and should not block us, tho...

Ok, I am going to go out on a limb here and guess you are on amd64. I have a good idea as to what has to be done to make this work properly, I just have to implement. However its not likely to land till just after beta, due to the invasive changes needed to make it work, however I will see what I can do.

ktp420 a écrit :
> Found a workaround which works:
> https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/273693/comments/6
>
> Another workaround that works for me:
> 1. Create /etc/ld.so.conf.d/alsa32.conf with the following contents:
> /usr/lib32/alsa-lib
>
> 2. Create /etc/ld.so.conf.d/alsa64.conf with the following contents:
> /usr/lib/alsa-lib
>
> 3. sudo ldconfig
>
> 4. Open /usr/share/alsa/pulse.conf in the editor and remove the
> "/usr/lib/alsa-lib/" prefix from the libasound_module_conf_pulse.so
> file.

Works for me too.
(Firefox crash sometime while playing flash, but I don't know the exact
cause).

* Fix some errors in the pid file handling patch, thanks to Mandriva.
* debian/pulse.conf: Do not use an absolute path when referring to the
pulse alsa plugin, as this breaks bi-arch configurations. libasound2
and lib32/64asound2 now include ldconfig files to include the alsa-plugins
path for the architecture in use.

Pablo, it is not yet marked as "Fixed", it's only "Fix released" now, wait a bit. I'm sure, Daniel and the devs understand that until the fix is backported to Hardy the bug can not be completely closed. LTS should be supported for more than 2,5 years from now, so the bug should get fixed on Hardy soon.

On Thu, Oct 16, 2008 at 1:42 AM, Daniel T Chen <email address hidden> wrote:
> All the necessary components are in place currently in 8.10, so closing
> pulseaudio task.

Dan, though I realise it is somewhat late, I have a slight concern
about the implementation of this change. Previously, PulseAudio was
only used as default when it was so set in ~/.asoundrc.asoundconf.
Currently, if I have a real hardware device set as default, say via
asoundconf set-default-card, that choice is ignored (at least by
GStreamer apps: I'm not sure of others) if pulseaudio is running.

This is frustrating, since PulseAudio doesn't use the plain "hw"
device of my Audigy card by default, but rather "front". This means I
don't get any hardware up-mixing, which is quite enjoyable.
Previously, I could just set my default ALSA card to anything not
PulseAudio, and bypass this issue, but that has become more difficult:
now I also have to kill the daemon.

I'm not sure whether PA's HAL autodetection module uses "front" for a
reason, so I have not filed a separate bug for that.

Well I think pulseaudio is one of the thing that was a little bit too fast harshed into ubuntu. As of now it disables the use of lots of features of Alsa and the latest update of hardy screwed my settings one more time.

People should have the choice between an feature missing cpu expensive pulseaudio and a correctly set Alsa, and updates should'nt reset theirs settings.

It is not acceptable that after an update, one loses its ALSA device, so that it becomes impossible for him to easily set his volume and that gnome's audio preferences falls the default device to the oss interface.

I do hope that the pulse-audio implementation in Intrepid won't be as messy as the one in hardy, but the audio problems induced by hardy pulseaudio arevery nerving me and make me consider switching to other distrib.

For now I have applications that complain about not finding sound a.s.o. gnome mixer is unusable.

As for setting 'default' for both ALSA and PulseAudio, I agree that the interaction is quite fragile. I'll be tackling that in jaunty (e.g., making each backend respect another's settings as much as sensible). As things stand for intrepid, for GSt-based apps, set everything to use ALSA (instead of Autodetect), and your ~/.asoundrc* will be honoured.

Daniel, if "you are free to remove this if you don't like it" is the official position on the devs, should I file a new bug about ubuntu-desktop depending on (and not recommending instead) pulseaudio? As it currently is, pulseaudio can not be removed whithout breaking the upgrade ability.

Alternatively, if pulseaudio actually IS the essential and unremovable part of an Ubuntu installation, maybe it's not a good idea to point out that users can remove this buggy pile of garbage completely, which they can't?

On Sun, 2008-10-19 at 04:03 +0000, Evgeny Kuznetsov wrote:
> Daniel, if "you are free to remove this if you don't like it" is the
> official position on the devs, should I file a new bug about ubuntu-
> desktop depending on (and not recommending instead) pulseaudio? As it
> currently is, pulseaudio can not be removed whithout breaking the
> upgrade ability.
>
> Alternatively, if pulseaudio actually IS the essential and unremovable
> part of an Ubuntu installation, maybe it's not a good idea to point out
> that users can remove this buggy pile of garbage completely, which they
> can't?
>

@Daniel
Yes I know I can remove pulseaudio, but as stated by others, it breaks ubuntu-desktop package and thus prevent the upgrade to be proposed. And also since the begining with hardy, I have to rebuild alsa from the source (the ones downloaded with apt-get sources) and sometime safe-upgrades break again the sound system.

I think sound issues are of major importance to Ubuntu since sound belongs to the basics thing that "should just work". Pulseaudio is in itself a good idea, but it is much more ressource consuming that alsa dmix. Actually I am not sure wether pulseaudio really bring something to people not wanting to do CAM or webradios, and for those, would'nt it be more consistent to have Jack ?

Also the problem with hardy is the regression on the alsa side : 7.10 I had my alsa sound working, inputs, outputs every thing was correct (after some painful configuration). With hardy, at first I had only one slider, no alsa interface (mixing capabilities were inexistant for none pulseaudio devices), I got rid of pulseaudio, find out that I had to recompile alsa, and unfortunately I am still unable to have the recording from mic/line in input work properly : it is very noisy, even thought the sound in the speaker when not muting mic line in is good.

I do really hope that 8.10 will clean these messy problems and that sound won'nt be anymore an issue on Ubuntu.

Actually I removed pulseaudio from my laptop and removed from my family desktop to get working everything. Sound it's ok and firefox does not crashes anymore.
But I want to test the newest version with most of the problems fixed and I want to test it in hardy, so I'm waiting here.

> Actually I removed pulseaudio from my laptop and removed from my family
> desktop to get working everything. Sound it's ok and firefox does not
> crashes anymore.
> But I want to test the newest version with most of the problems fixed and I
> want to test it in hardy, so I'm waiting here.
>
> Br,
> Pablo.
>
> --
> Default ALSA device must use PulseAudio, otherwise ALSA applications may
> fail
> https://bugs.launchpad.net/bugs/198453
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in PulseAudio sound server: Confirmed
> Status in "alsa-lib" source package in Ubuntu: Fix Released
> Status in "alsa-plugins" source package in Ubuntu: Fix Released
> Status in "pulseaudio" source package in Ubuntu: Fix Released
> Status in alsa-lib in Ubuntu Hardy: Incomplete
> Status in alsa-plugins in Ubuntu Hardy: Incomplete
> Status in pulseaudio in Ubuntu Hardy: Invalid
>
> Bug description:
> Steps to reproduce:
>
> Run both of these at the same time:
> gst-launch-0.10 audiotestsrc ! pulsesink
> gst-launch-0.10 audiotestsrc ! alsasink
>
> If your default sound device does not support hardware mixing, the second
> command will fail. ALSA cannot use the device while PulseAudio is using it,
> and this affects a lot of applications.
>
> Note that if you run the commands the other way around, alsalib will use
> dmix, and then so will pulseaudio, so there is not as much of a problem this
> way around (except for the fact that dmix and PA are doing the same job, and
> you can not control the ALSA-using apps' volumes and routing with PA.)
>
>
> Resolution:
>
> Follow http://pulseaudio.org/wiki/PerfectSetup#ALSAApplications
> i.e. install /etc/asound.conf with:
>
> pcm.pulse {
> type pulse
> }
> ctl.pulse {
> type pulse
> }
> pcm.!default {
> type pulse
> }
> ctl.!default {
> type pulse
> }
>
> Then, install the package "libasound2-plugins", as it contains the required
> "pcm_pulse" and "ctl_pulse" plugins.
>
> Note, too, that there are some applications that fail with ALSA->Pulse:
>
> SDL* seems to hang with neverball, but that is fixed by installing the
> PulseAudio backend for SDL (libsdl1.2debian-pulseaudio), which will replace
> the default ALSA backend.
> WINE has its own issues with regards to device selection, which I don't
> know a remedy for.
> Skype* also has its own problems, but these aren't fixable by us and should
> not block us, though should be given some consideraton.
>
> * SDL applications (using libsdl1.2-alsa backend), Skype and possibly other
> misbehaving applications work properly with later versions of libasound2 &
> libasound2-plugins from Debian unstable.
>

Sorry, roxthiaguin, but Flash 10 is only released for x386 machines, which is not the only architecture supported by Ubuntu. People using other architectures (or should I say "another architecture"?) are still forced to use libflashsupport.

> Sorry, roxthiaguin, but Flash 10 is only released for x386 machines,
> which is not the only architecture supported by Ubuntu. People using
> other architectures (or should I say "another architecture"?) are still
> forced to use libflashsupport.
>
> --
> Default ALSA device must use PulseAudio, otherwise ALSA applications may
> fail
> https://bugs.launchpad.net/bugs/198453
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in PulseAudio sound server: Confirmed
> Status in "alsa-lib" source package in Ubuntu: Fix Released
> Status in "alsa-plugins" source package in Ubuntu: Fix Released
> Status in "pulseaudio" source package in Ubuntu: Fix Released
> Status in alsa-lib in Ubuntu Hardy: Incomplete
> Status in alsa-plugins in Ubuntu Hardy: Incomplete
> Status in pulseaudio in Ubuntu Hardy: Invalid
>
> Bug description:
> Steps to reproduce:
>
> Run both of these at the same time:
> gst-launch-0.10 audiotestsrc ! pulsesink
> gst-launch-0.10 audiotestsrc ! alsasink
>
> If your default sound device does not support hardware mixing, the second
> command will fail. ALSA cannot use the device while PulseAudio is using it,
> and this affects a lot of applications.
>
> Note that if you run the commands the other way around, alsalib will use
> dmix, and then so will pulseaudio, so there is not as much of a problem this
> way around (except for the fact that dmix and PA are doing the same job, and
> you can not control the ALSA-using apps' volumes and routing with PA.)
>
>
> Resolution:
>
> Follow http://pulseaudio.org/wiki/PerfectSetup#ALSAApplications
> i.e. install /etc/asound.conf with:
>
> pcm.pulse {
> type pulse
> }
> ctl.pulse {
> type pulse
> }
> pcm.!default {
> type pulse
> }
> ctl.!default {
> type pulse
> }
>
> Then, install the package "libasound2-plugins", as it contains the required
> "pcm_pulse" and "ctl_pulse" plugins.
>
> Note, too, that there are some applications that fail with ALSA->Pulse:
>
> SDL* seems to hang with neverball, but that is fixed by installing the
> PulseAudio backend for SDL (libsdl1.2debian-pulseaudio), which will replace
> the default ALSA backend.
> WINE has its own issues with regards to device selection, which I don't
> know a remedy for.
> Skype* also has its own problems, but these aren't fixable by us and should
> not block us, though should be given some consideraton.
>
> * SDL applications (using libsdl1.2-alsa backend), Skype and possibly other
> misbehaving applications work properly with later versions of libasound2 &
> libasound2-plugins from Debian unstable.
>

Is there any definite work around for this bug? I tried to Making Alsa the default for all sound in the preferences>sound but it didn't fix the issue. Skype blocks Rythmbox if it is being used and Rythmbox blocks skype if it is being used. Firefox will also block both.

I am using 64bit 8.10 on an HP Pavilion DV6000. It is a very annoying issue and must be causing big headaches for a lot of people.