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.