Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: pulseaudio (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/944295
Title:
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
** Patch added: Patch against alsa-plugins
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/944295/+attachment/3076953/+files/pasuspender-pasuspend-env.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Also affects: alsa-plugins (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/944295
Title:
pasuspender tool doesn't work
To manage notifications
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.
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
