mumble issues with pulseaudio

mumble issues with pulseaudio

[ng0]

At least one other person and myself are experiencing a "bug" with
pulseaudio on GuixSD when it comes to using Mumble.
I assume that the other person uses Pulseaudio aswell as it was said to
be on GuixSD.
The bug is, you have to close every possible open application which
could make use of sound input/output (webbrowser, IM, etc) then shake
the random dice pair and hope that Mumble detected your sound devices.
If it didn't, you have to wait some seconds and restart Mumble and
repeat it until your sound devices appear to be working.
This is annoying and can leave you with the impression that it doesn't
work - but it does work.

A) What is the cause of this problem

and

B) How do we fix it or point it out?

Re: mumble issues with pulseaudio

[Ludovic Courtès]

Hello,

ng0 <contact.ng0@cryptolab.net> skribis:

> The bug is, you have to close every possible open application which
> could make use of sound input/output (webbrowser, IM, etc) then shake
> the random dice pair and hope that Mumble detected your sound devices.
> If it didn't, you have to wait some seconds and restart Mumble and
> repeat it until your sound devices appear to be working.
> This is annoying and can leave you with the impression that it doesn't
> work - but it does work.

Could it be that Mumble does *not* use PulseAudio, but instead attempts
to use ALSA directly?

PulseAudio works best when all the applications on the system use it.
:-)  You can check with ‘pavucontrol’ the list of applications currently
doing audio with PulseAudio.

Note that applications that use PulseAudio, including ‘pavucontrol’,
automatically start the pulseaudio daemon if it’s not already running.

HTH!
Ludo’.

Re: mumble issues with pulseaudio

[ng0]

Ludovic Courtès transcribed 0.9K bytes:
> Hello,
> 
> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> > The bug is, you have to close every possible open application which
> > could make use of sound input/output (webbrowser, IM, etc) then shake
> > the random dice pair and hope that Mumble detected your sound devices.
> > If it didn't, you have to wait some seconds and restart Mumble and
> > repeat it until your sound devices appear to be working.
> > This is annoying and can leave you with the impression that it doesn't
> > work - but it does work.
> 
> Could it be that Mumble does *not* use PulseAudio, but instead attempts
> to use ALSA directly?

It was listed as a dependency (if I remember correctly). When I start
mumble, it appears under 'Applications' and 'All Streams' but not
'Virtual Streams'. I avoided getting into pulseaudio for a long time, so
I can only guess (and read up on the topic).
A clear sign that it does use pulseaudio would be references in the
source code, messages in standard output / log with reference to
pulseaudio, and what else?

> PulseAudio works best when all the applications on the system use it.
> :-)  You can check with ‘pavucontrol’ the list of applications currently
> doing audio with PulseAudio.

The problem is that mumble sometimes appears in Applications of
pavucontrol and sometimes it doesn't.

> Note that applications that use PulseAudio, including ‘pavucontrol’,
> automatically start the pulseaudio daemon if it’s not already running.
> 
> HTH!
> Ludo’.
> 

Re: mumble issues with pulseaudio

[ng0]

ng0 transcribed 1.6K bytes:
> Ludovic Courtès transcribed 0.9K bytes:
> > Hello,
> > 
> > ng0 <contact.ng0@cryptolab.net> skribis:
> > 
> > > The bug is, you have to close every possible open application which
> > > could make use of sound input/output (webbrowser, IM, etc) then shake
> > > the random dice pair and hope that Mumble detected your sound devices.
> > > If it didn't, you have to wait some seconds and restart Mumble and
> > > repeat it until your sound devices appear to be working.
> > > This is annoying and can leave you with the impression that it doesn't
> > > work - but it does work.
> > 
> > Could it be that Mumble does *not* use PulseAudio, but instead attempts
> > to use ALSA directly?
> 
> It was listed as a dependency (if I remember correctly). When I start
> mumble, it appears under 'Applications' and 'All Streams' but not
> 'Virtual Streams'. I avoided getting into pulseaudio for a long time, so
> I can only guess (and read up on the topic).
> A clear sign that it does use pulseaudio would be references in the
> source code, messages in standard output / log with reference to
> pulseaudio, and what else?

This is the output just shortly after boot, ran pavucontrol before it:

[user@abyayala ~]$ mumble
CELT bitstream 8000000b from
/gnu/store/04nqixbnmv29v1nzansp50ppa5gdza4q-mumble-1.2.19/lib/mumble/libcelt0.so.0.7.0
CELT bitstream 80000010 from
/gnu/store/04nqixbnmv29v1nzansp50ppa5gdza4q-mumble-1.2.19/lib/mumble/libcelt0.so.0.11.0
Locale is "en_US" (System: "en_US")
TextToSpeech: Failed to contact speech dispatcher.
Database SQLite: "3.7.7.1" 
Overlay: Listening on "/home/user/.MumbleOverlayPipe" 
GlobalShortcutX: Using XI2 2.3
AudioInput: 40000 bits/s, 48000 hz, 480 sample
PulseAudio: Starting input alsa_input.pci-0000_00_1b.0.analog-stereo
PulseAudio: Starting output: alsa_output.pci-0000_00_1b.0.analog-stereo
AudioOutput: Initialized 1 channel 44100 hz mixer
AudioInput: Initialized mixer for 1 channel 44100 hz mic and 0 channel
48000 hz echo
warning: The VAD has been replaced by a hack pending a complete rewrite



 
> > PulseAudio works best when all the applications on the system use it.
> > :-)  You can check with ‘pavucontrol’ the list of applications currently
> > doing audio with PulseAudio.
> 
> The problem is that mumble sometimes appears in Applications of
> pavucontrol and sometimes it doesn't.
> 
> > Note that applications that use PulseAudio, including ‘pavucontrol’,
> > automatically start the pulseaudio daemon if it’s not already running.
> > 
> > HTH!
> > Ludo’.
> > 
> 

Re: mumble issues with pulseaudio

[Ludovic Courtès]

Hello,

ng0 <contact.ng0@cryptolab.net> skribis:

> Ludovic Courtès transcribed 0.9K bytes:

[...]

>> PulseAudio works best when all the applications on the system use it.
>> :-)  You can check with ‘pavucontrol’ the list of applications currently
>> doing audio with PulseAudio.
>
> The problem is that mumble sometimes appears in Applications of
> pavucontrol and sometimes it doesn't.

This is weird: I would expect it to always appear under “Applications”
or to never appear, but not something in between.  Anyway, that suggests
Mumble is indeed using PulseAudio.

When it shows up under “Applications”, can you hear its audio output?
(Assuming the sliders and mute buttons in pavucontrol are all properly
set.)

HTH,
Ludo’.

Re: mumble issues with pulseaudio

[Florian Paul Schmidt]

On 04/01/2017 05:46 PM, ng0 wrote:
>>>> The bug is, you have to close every possible open application which
>>>> could make use of sound input/output (webbrowser, IM, etc) then shake
>>>> the random dice pair and hope that Mumble detected your sound devices.
>>>> If it didn't, you have to wait some seconds and restart Mumble and
>>>> repeat it until your sound devices appear to be working.
>>>> This is annoying and can leave you with the impression that it doesn't
>>>> work - but it does work.
>>>
>>> Could it be that Mumble does *not* use PulseAudio, but instead attempts
>>> to use ALSA directly?
>>
>> It was listed as a dependency (if I remember correctly). When I start
>> mumble, it appears under 'Applications' and 'All Streams' but not
>> 'Virtual Streams'. I avoided getting into pulseaudio for a long time, so
>> I can only guess (and read up on the topic).
>> A clear sign that it does use pulseaudio would be references in the
>> source code, messages in standard output / log with reference to
>> pulseaudio, and what else?
>
> This is the output just shortly after boot, ran pavucontrol before it:
>
> [user@abyayala ~]$ mumble
> CELT bitstream 8000000b from
> /gnu/store/04nqixbnmv29v1nzansp50ppa5gdza4q-mumble-1.2.19/lib/mumble/libcelt0.so.0.7.0
> CELT bitstream 80000010 from
> /gnu/store/04nqixbnmv29v1nzansp50ppa5gdza4q-mumble-1.2.19/lib/mumble/libcelt0.so.0.11.0
> Locale is "en_US" (System: "en_US")
> TextToSpeech: Failed to contact speech dispatcher.
> Database SQLite: "3.7.7.1"
> Overlay: Listening on "/home/user/.MumbleOverlayPipe"
> GlobalShortcutX: Using XI2 2.3
> AudioInput: 40000 bits/s, 48000 hz, 480 sample
> PulseAudio: Starting input alsa_input.pci-0000_00_1b.0.analog-stereo
> PulseAudio: Starting output: alsa_output.pci-0000_00_1b.0.analog-stereo
> AudioOutput: Initialized 1 channel 44100 hz mixer
> AudioInput: Initialized mixer for 1 channel 44100 hz mic and 0 channel
> 48000 hz echo
> warning: The VAD has been replaced by a hack pending a complete rewrite

Yes, this looks like mumble has opened an ALSA |PCM device that's not 
the default device called "default". If it's a PCM device that is going 
directly to a hardware device that does not provide stream mixing, then 
this will make other calls to ALSA to open that device (either directly 
or indirectly through another PCM device) _block_ until mumble has 
released the device again. Also, if the device is used by e.g. PA before 
mumble tries to open it, mumble's call to ALSA will _block_ until PA 
released the device.

This is a longstanding bug in the ALSA API, that the ALSA devs do not 
consider a bug so it will never be fixed. There have been many 
discussions about how the call to ALSA should rather _fail_ than _block_ 
in case of the device being busy (there's a sublety here that the 
failing behaviour is available, but nobody uses it, so you get this 
super annoying behaviour of calls to ALSA _blocking_)..

If the PulseAudio installation shipped with GuixSD is "sane" then it 
will provide a virtual ALSA pcm device and will globally route the pcm 
device called "default" to this virtual PCM device. This device will 
provide stream mixing, etc..

So any ALSA application that just uses the "default" PCM device should 
work out of the box with a sane PA installation since this "default" PCM 
device is just a name for the virtual PCM device provided by PA.

Mumble additionally also has "native" PA support which you can build in. 
So to make mumble work on a PA system either

1] use the PA provided virtual PCM device "default"

or

2] build mumble with native PA support and enable it in the preferences.

Have fun,
Flo




-- 
https://fps.io

Re: mumble issues with pulseaudio

[Florian Paul Schmidt]

On 04/02/2017 11:33 AM, Florian Paul Schmidt wrote:
>> PulseAudio: Starting input alsa_input.pci-0000_00_1b.0.analog-stereo
>> PulseAudio: Starting output: alsa_output.pci-0000_00_1b.0.analog-stereo
>> AudioOutput: Initialized 1 channel 44100 hz mixer
>> AudioInput: Initialized mixer for 1 channel 44100 hz mic and 0 channel
>> 48000 hz echo

Oops and I misread this output. Yes, it seems mumble uses PA natively 
here. So the first sentence in my reply below was wrong. The rest of the 
reply still standts as being possibly helpful in understanding what can 
go wrong in other scenarios.

Note though that I found the native PA support in mumble usually working 
worse than using the PA virtual ALSA PCM device.

>
> Yes, this looks like mumble has opened an ALSA |PCM device that's not
> the default device called "default". If it's a PCM device that is going
> directly to a hardware device that does not provide stream mixing, then
> this will make other calls to ALSA to open that device (either directly
> or indirectly through another PCM device) _block_ until mumble has
> released the device again. Also, if the device is used by e.g. PA before
> mumble tries to open it, mumble's call to ALSA will _block_ until PA
> released the device.
>
> This is a longstanding bug in the ALSA API, that the ALSA devs do not
> consider a bug so it will never be fixed. There have been many
> discussions about how the call to ALSA should rather _fail_ than _block_
> in case of the device being busy (there's a sublety here that the
> failing behaviour is available, but nobody uses it, so you get this
> super annoying behaviour of calls to ALSA _blocking_)..
>
> If the PulseAudio installation shipped with GuixSD is "sane" then it
> will provide a virtual ALSA pcm device and will globally route the pcm
> device called "default" to this virtual PCM device. This device will
> provide stream mixing, etc..
>
> So any ALSA application that just uses the "default" PCM device should
> work out of the box with a sane PA installation since this "default" PCM
> device is just a name for the virtual PCM device provided by PA.
>
> Mumble additionally also has "native" PA support which you can build in.
> So to make mumble work on a PA system either
>
> 1] use the PA provided virtual PCM device "default"
>
> or
>
> 2] build mumble with native PA support and enable it in the preferences.

Flo


-- 
https://fps.io

Re: mumble issues with pulseaudio

[ng0]

Ludovic Courtès transcribed 0.8K bytes:
> Hello,
> 
> ng0 <contact.ng0@cryptolab.net> skribis:
> 
> > Ludovic Courtès transcribed 0.9K bytes:
> 
> [...]
> 
> >> PulseAudio works best when all the applications on the system use it.
> >> :-)  You can check with ‘pavucontrol’ the list of applications currently
> >> doing audio with PulseAudio.
> >
> > The problem is that mumble sometimes appears in Applications of
> > pavucontrol and sometimes it doesn't.
> 
> This is weird: I would expect it to always appear under “Applications”
> or to never appear, but not something in between.  Anyway, that suggests
> Mumble is indeed using PulseAudio.
> 
> When it shows up under “Applications”, can you hear its audio output?
> (Assuming the sliders and mute buttons in pavucontrol are all properly
> set.)

Yes, in this case I can. I'll start it via console now every time I use
it to see if I can catch the error output next time I get the error.

> HTH,
> Ludo’.
> 

Re: mumble issues with pulseaudio

[Ludovic Courtès]

Florian Paul Schmidt <mista.tapas@gmx.net> skribis:

> If the PulseAudio installation shipped with GuixSD is "sane" then it
> will provide a virtual ALSA pcm device and will globally route the pcm
> device called "default" to this virtual PCM device. This device will
> provide stream mixing, etc..

FWIW I have ~/.asoundrc with:

--8<---------------cut here---------------start------------->8---
pcm.!default {
    type pulse
}
--8<---------------cut here---------------end--------------->8---

to “reroute” ALSA applications to PulseAudio.

I’m not sure whether we should do that by default, or install this
.asoundrc for newly-created accounts.  I guess some people may not want
it.

Thoughts?

Ludo’.

Re: mumble issues with pulseaudio

[Alex Kost]

Ludovic Courtès (2017-04-03 12:08 +0200) wrote:

> Florian Paul Schmidt <mista.tapas@gmx.net> skribis:
>
>> If the PulseAudio installation shipped with GuixSD is "sane" then it
>> will provide a virtual ALSA pcm device and will globally route the pcm
>> device called "default" to this virtual PCM device. This device will
>> provide stream mixing, etc..
>
> FWIW I have ~/.asoundrc with:
>
> pcm.!default {
>     type pulse
> }
>
> to “reroute” ALSA applications to PulseAudio.
>
> I’m not sure whether we should do that by default, or install this
> .asoundrc for newly-created accounts.  I guess some people may not want
> it.

At least I'm one of those people :-)  I even have the following in my
.bash_profile to make sure that pulseaudio is never used:

export AUDIODRIVER=alsa
export SDL_AUDIODRIVER=alsa

-- 
Alex

Re: mumble issues with pulseaudio

[ng0]

Alex Kost transcribed 0.8K bytes:
> Ludovic Courtès (2017-04-03 12:08 +0200) wrote:
> 
> > Florian Paul Schmidt <mista.tapas@gmx.net> skribis:
> >
> >> If the PulseAudio installation shipped with GuixSD is "sane" then it
> >> will provide a virtual ALSA pcm device and will globally route the pcm
> >> device called "default" to this virtual PCM device. This device will
> >> provide stream mixing, etc..
> >
> > FWIW I have ~/.asoundrc with:
> >
> > pcm.!default {
> >     type pulse
> > }
> >
> > to “reroute” ALSA applications to PulseAudio.
> >
> > I’m not sure whether we should do that by default, or install this
> > .asoundrc for newly-created accounts.  I guess some people may not want
> > it.
> 
> At least I'm one of those people :-)  I even have the following in my
> .bash_profile to make sure that pulseaudio is never used:
> 
> export AUDIODRIVER=alsa
> export SDL_AUDIODRIVER=alsa
> 
> -- 
> Alex
> 

I have an idea:

Default to include it.
We could have a setting which can be defined in the
(operating-system) to set (profile-creation-asoundrc #f).

Re: mumble issues with pulseaudio

[Ludovic Courtès]

ng0 <contact.ng0@cryptolab.net> skribis:

> Alex Kost transcribed 0.8K bytes:
>> Ludovic Courtès (2017-04-03 12:08 +0200) wrote:
>> 
>> > Florian Paul Schmidt <mista.tapas@gmx.net> skribis:
>> >
>> >> If the PulseAudio installation shipped with GuixSD is "sane" then it
>> >> will provide a virtual ALSA pcm device and will globally route the pcm
>> >> device called "default" to this virtual PCM device. This device will
>> >> provide stream mixing, etc..
>> >
>> > FWIW I have ~/.asoundrc with:
>> >
>> > pcm.!default {
>> >     type pulse
>> > }
>> >
>> > to “reroute” ALSA applications to PulseAudio.
>> >
>> > I’m not sure whether we should do that by default, or install this
>> > .asoundrc for newly-created accounts.  I guess some people may not want
>> > it.
>> 
>> At least I'm one of those people :-)  I even have the following in my
>> .bash_profile to make sure that pulseaudio is never used:
>> 
>> export AUDIODRIVER=alsa
>> export SDL_AUDIODRIVER=alsa
>> 
>> -- 
>> Alex
>> 
>
> I have an idea:
>
> Default to include it.
> We could have a setting which can be defined in the
> (operating-system) to set (profile-creation-asoundrc #f).

I was talking of the account skeletons, i.e., the files that are
automatically installed in the home directory of a newly-created account
(see (gnu system shadow)).  These files can always be modified or
removed by the user afterwards.

Still I understand that choosing a default is always difficult.  :-)

Ludo’.

Re: mumble issues with pulseaudio

[Alex Kost]

Ludovic Courtès (2017-04-03 23:18 +0200) wrote:

[...]
> I was talking of the account skeletons, i.e., the files that are
> automatically installed in the home directory of a newly-created account
> (see (gnu system shadow)).  These files can always be modified or
> removed by the user afterwards.
>
> Still I understand that choosing a default is always difficult.  :-)

OTOH, AFAIK PulseAudio is the default choice on most distros these days,
so it's probably OK to default to it.

-- 
Alex

Re: mumble issues with pulseaudio

[ng0]

Alex Kost transcribed 0.5K bytes:
> Ludovic Courtès (2017-04-03 23:18 +0200) wrote:
> 
> [...]
> > I was talking of the account skeletons, i.e., the files that are
> > automatically installed in the home directory of a newly-created account
> > (see (gnu system shadow)).  These files can always be modified or
> > removed by the user afterwards.
> >
> > Still I understand that choosing a default is always difficult.  :-)
> 
> OTOH, AFAIK PulseAudio is the default choice on most distros these days,
> so it's probably OK to default to it.
> 
> -- 
> Alex
> 

Aren't we just talking about GuixSD here?
In most cases every non-GuixSD system will already have a profile set
up.

Re: mumble issues with pulseaudio

[Florian Paul Schmidt]

On 04/05/2017 11:57 AM, ng0 wrote:
> Aren't we just talking about GuixSD here?
> In most cases every non-GuixSD system will already have a profile set
> up.
>

Just as a sidenote: ALSA also has global configuration files, e.g. here 
on ubuntu they live in:

/usr/share/alsa/alsa.conf

and

/usr/share/alsa/alsa.conf.d/

On ubuntu the default ALSA device is routed through PA without a user 
having a ~/.asoundrc. That latter file is used for further customization 
by the user.

It's been a while since I spent a lot of time studying the interplay of 
all of ALSA's config files, so where exactly ubuntu specifies the 
"pulse" virtual PCM device as "default" right now eludes me.

Regards,
Flo

-- 
https://fps.io

Re: mumble issues with pulseaudio

[Ludovic Courtès]

Florian Paul Schmidt <mista.tapas@gmx.net> skribis:

> On 04/05/2017 11:57 AM, ng0 wrote:
>> Aren't we just talking about GuixSD here?

Not only.  For some packages it’s a compile-time choice.

> Just as a sidenote: ALSA also has global configuration files,
> e.g. here on ubuntu they live in:
>
> /usr/share/alsa/alsa.conf
>
> and
>
> /usr/share/alsa/alsa.conf.d/
>
> On ubuntu the default ALSA device is routed through PA without a user
> having a ~/.asoundrc. That latter file is used for further
> customization by the user.

Indeed.  I just checked on Debian and the situation is similar.  It’s
doing something quite sophisticated; from
/usr/share/alsa/alsa.conf.d/pulse.conf:

--8<---------------cut here---------------start------------->8---
# PulseAudio alsa plugin configuration file to set the pulseaudio plugin as
# default output for applications using alsa when pulseaudio is running.
hook_func.pulse_load_if_running {
        lib "libasound_module_conf_pulse.so"
        func "conf_pulse_hook_load_if_running"
}

@hooks [
        {
                func pulse_load_if_running
                files [
                        "/usr/share/alsa/pulse-alsa.conf"
                        "/etc/asound.conf"
                        "~/.asoundrc"
                ]
                errors false
        }
]
--8<---------------cut here---------------end--------------->8---

I tried it on GuixSD and couldn’t get it to work though.

Ludo’.