On 2020/04/26 14:29, Moises Simon wrote:
> Hi,
> 
> after the mixerctl/sndioctl change in -current
> sndioctl doesn't work if mpd is playing music.
> 
> Other music players like cmus work fine
> 
> OpenBSD 6.7-beta (GENERIC.MP) #153: Fri Apr 24 07:15:21 MDT 2020
> Information for inst:mpd-0.21.21
> 
> sirius$ sndioctl -v 
> input[0].level=0.49
> input[1].level=0.49
> input[0].mute=0
> input[1].mute=0
> output[0].level=0.71
> output[1].level=0.71
> output[0].mute=0
> output[1].mute=0
> app/mpd0.level=1
> sirius$ mpc play
> Héroes del Silencio - La chispa adecuada
> [playing] #18/62   3:51/5:01 (76%)
> volume:100%   repeat: on    random: on    single: off   consume: on 
> sirius$ sndioctl -v 
> default: can't open control device

sndioctl first tries to connect to sndiod using ~/.sndio/cookie,
which I think in this case probably fails because mpd (running as a
different uid) has already connected to sndiod using its own cookie.

When that fails it falls back to trying to connect to the kernel
interface (i.e. via the device node in /dev) which is no longer
permitted, triggering the "can't open control device" error.

I'm not an mpd user but I think the fix for this situation is that mpd
needs a copy of your ~/.sndio/cookie so that both you and mpd can both
control the device. How to get there, I'm not sure, because the uid
running mpd has its home directory set as /var/empty, maybe that needs
changing to a real directory. Or it _might_ be possible to workaround
by having mpd talk to sndiod over a TCP socket instead (like
https://undeadly.org/cgi?action=article;sid=20180410063454 but using
127.0.0.1 instead of an external address).

Reply via email to