Download raw body.
bug/limitation of sndiod
On Fri, Jul 03, 2026 at 04:57:04PM +0200, Marc Espie wrote:
> According to faq13, I now have a machine configured with
>
> # rcctl set sndiod flags -f rsnd/0 -F rsnd/1
>
-F is not useful anymore (see below), I'd suggest not using it.
> It doesn't work "symetrically", namely if I start playing something
> with mpv while the USB audio is plugged in (pleasantly surprised:
> it's the USB-B input from my panasonic hi-fi system and it works
> like a charm), and I unplug the cable/turn off the appliance, it
> reverts to the internal azalia audio.
>
> BUT if I plug it back in, uaudio reappears in the dmesg, but somehow,
> sndiod doesn't jump back up to the USB output.
>
> I have to quit mpv and start it again for it to output to USB.
>
sndiod can't detect when a device is plugged. You could use
hotplugd(8) for this, ex. I've this in my /etc/hotplug/attach:
- - - - - - - - - - - - - - - - - - - - - - - - -
DEVNAME=$2
case $DEVNAME in
audio[0-9])
# Switch sndiod(8) to the new device
sndioctl server.device=${DEVNAME#audio}
;;
esac
- - - - - - - - - - - - - - - - - - - - - - - - -
alternatively, you could just switch the device manually after you
plug the device:
sndioctl server.device=1
Note that there's a unsolved problem: by default sndiod uses a huge
buffer, around 160ms (because back in 2009, MP kernels used to stutter
a lot and we never revisited the defaults). If your USB device is
32-bit and has many channels 160ms of buffer size would exceed the
kernel limit. In this case sndiod won't be able to migrate the sound
from azalia to uaudio.
I'd suggest using a better buffer size, like 40ms or even 20ms (that's
what I use since a decade and its stable). Ex:
rcctl set sndiod flags -z 480 -b 1920
This is also more suitable for audio/video calls and games. IMHO we
should refresh the defaults, MP kernels improved a lot.
> Is this fixable ?
>
Let me know how this wokrs.
bug/limitation of sndiod