pasuspender does not stop alsa-lib from defaulting to pulseaudio plugin

[max ulidtko]

Steps to reproduce:
1. Run an application continuously playing audio, music player for example.
2. Launch in a terminal: pasuspender speaker-test
3. While 2) is running, launch in another terminal: pasuspender sleep 1, and wait while it finishes.

What happens:
2. a) The usual pulseaudio streams stop playing, which is expected.
    b) But the speaker-test produces no output, which is contrary to the expected effect.
3. a) While the first pasuspender instance is still running, the sound from music player resumes, which is not what is expected.
    b) Moreover, the "pasuspended" speaker-test pink noise resumes with the music player, too. Which is not what is expected, too.

[Antony Riley (antony-cyberiantiger)]

Speaker-test writes to the default alsa device, which happens to be the alsa-pulseaudio bridge, which explains why you get no output from it, and then when sound resumes you get output.

Consider the following:

pasuspender -- speakertest -Dplug:front

This should work as you expect.

(It would be great if pasuspender disabled the alsa-pulse bridge).

3 a) is kinda obvious, pasuspender was never intended to have multiple copies running, because it's expected whatever you're running under it will lock the sound card exclusively. Making running another copy of pasuspender in parallel something outside of the designers expectations.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Antony Riley (antony-cyberiantiger)]

This has been pissing me off for some time, there are two possible workaround I can think of:

- fix libasound_module_conf_pulse.so so that if an application is running under pasuspender it does not load pulse devices into alsa.

I've implemented a rough hack so pasuspender sets the environment variable PASUSPENDED and add a check in libasound_module_conf_pulse.so

[David Henningsson (diwic)]

Hmm, interesting. So the idea is to not have alsa default to pulseaudio, if we're inside a pasuspender shell?

If so, I think what you want to modify pulse/conf_pulse.c, function "conf_pulse_hook_load_if_running", in alsa-plugins, which controls whether ALSA tries to load the pulse plugin or not.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Patch against pulseaudio" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Mike Mestnik (cheako)]

ubuntu-reviewers :
  I think this patch can be ignored, no offense to Antony, it is not ready to be included or used in it's current state.

[Mike Mestnik (cheako)]

I believe there are two changes that should be made.

The most obvious is that "conf_pulse_hook_load_if_running" needs to connect to PA and confirm it's really running, in that specifically if it's suspended or not. I believe it would be fine if PA was suspended for another reason for applications to 'skip' trying to use it. These should be rare cases and what's the worst that could happen? My though is that an application, like xmms, will start using the hardware and PA won't ever be able to get it back. However, after the unsuspend, applications will start transitioning back to PA... Even with xmms still hogging the HW sink.

The second change is for PA to reject a second attempt to suspend, this should be an error or warning that pasuspender should handle with a stop and exit without running the application it was supposed to. An issue here is that if PA is suspended for another reason, but that's up to the user to discover and fix.

[Raymond (superquad-vortex2)]

THis hack seem prevent any application use snd_ctl_open() hw:0 only

alsa-lib/test/control fail with card zero only but other card number are o.k.

[Raymond (superquad-vortex2)]

alsa-lib/test/control can be run normally by rename /use/share/alsa/alsa.conf.d/pulse.conf

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

If anyone can still reproduce this bug then please help us by running:

apport-collect 944295

to send more system information.

[Launchpad Janitor (janitor)]

[Expired for pulseaudio (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for alsa-plugins (Ubuntu) because there has been no activity for 60 days.]