From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Paul Schmidt Subject: Re: mumble issues with pulseaudio Date: Sun, 2 Apr 2017 11:33:46 +0200 Message-ID: <7d1e1ea3-d45f-5942-2bb0-7c41f65dd69b@gmx.net> References: <20170331182310.noh3apyuautud73j@abyayala> <87shlsi814.fsf@gnu.org> <20170401154331.ayicbw46mttkpsle@abyayala> <20170401154613.olv3qzrd72x36edb@abyayala> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cubtS-0007bR-SJ for help-guix@gnu.org; Sun, 02 Apr 2017 05:33:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cubtP-0004hN-O5 for help-guix@gnu.org; Sun, 02 Apr 2017 05:33:54 -0400 Received: from mout.gmx.net ([212.227.17.20]:56910) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cubtP-0004gX-D2 for help-guix@gnu.org; Sun, 02 Apr 2017 05:33:51 -0400 Received: from [192.168.1.241] ([77.8.135.211]) by mail.gmx.com (mrgmx101 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MCPhl-1cm7Qo3xsv-0097TE for ; Sun, 02 Apr 2017 11:33:48 +0200 In-Reply-To: <20170401154613.olv3qzrd72x36edb@abyayala> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: help-guix@gnu.org 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