Re: sndiod fallback trouble

[Mihai Popescu]

> ... but i see no simple & obvious solution that doesn't break current common 
> use-cases

Maybe I'm wrong, but hotplugd comes to my mind. Isn't it possible to
run some script(s) at plug/unplug events associated with that USB DAC
in order to reconfigure sndiod.
Again, I never used hotplugd, but someone my know better ...

Re: sndiod fallback trouble

[Alexandre Ratchov]

On Sat, Feb 27, 2016 at 01:41:15PM -0500, Michael Reed wrote:
> On 02/27/16 04:15, Alexandre Ratchov wrote:
> >A nicer approach would be to handle this in sndiod by allowing
> >sub-devices (aka -s options) to change their device (aka -f
> >option).  The advantage of doing it in sndiod is that later this
> >could happen dynamically (ex.  unplug usb cable and programs
> >migrate to another device).
> 
> So, if I had program A connected to snd/0 (backed by rsnd/1), and
> rsnd/1 was unplugged during playback, then snd/0's backing device
> would be changed to rsnd/0?

yes that would work.  The hardest part is how to expose it without
adding a gazillon of flags & options.

Re: sndiod fallback trouble

[Alexandre Ratchov]

On Sat, Feb 27, 2016 at 10:32:30AM +0100, Matej Nanut wrote:
> On 27 February 2016 at 10:15, Alexandre Ratchov  wrote:
> > One option would to patch libsndio to try more devices (how many?).
> 
> I've also noticed this issue and have hacked libsndio to try snd/0 and
> snd/1 first, which is basically the same as your suggestion.
> 
> > A nicer approach would be to handle this in sndiod [...]
> 
> That would be fantastic, but seems like quite a lot of work. I don't
> know enough about the audio stack to really comment, but can't there
> be problems with a device changing for the program mid stream? Or
> would you add a special "trunk-like" pseudo device?
> 
> What do you think of adding a separator to AUDIODEVICE, to be able to
> list more than one device (like : or ;)? Then libsndio just tries them
> one after another, and you don't have to guess how many. It's a simple
> backwards-compatible fix, but it doesn't address device migration.

yeah that would work. I'd like something that could work by default
without configuration, but i see no simple & obvious solution that
doesn't break current common use-cases

Re: sndiod fallback trouble

[Michael Reed]

On 02/27/16 04:15, Alexandre Ratchov wrote:

A nicer approach would be to handle this in sndiod by allowing
sub-devices (aka -s options) to change their device (aka -f
option).  The advantage of doing it in sndiod is that later this
could happen dynamically (ex.  unplug usb cable and programs
migrate to another device).


So, if I had program A connected to snd/0 (backed by rsnd/1), and
rsnd/1 was unplugged during playback, then snd/0's backing device
would be changed to rsnd/0?

I might be misunderstanding you, but that sounds like a really nice
idea ("trunk-like", as Matej said).

Re: sndiod fallback trouble

[Matej Nanut]

On 27 February 2016 at 10:15, Alexandre Ratchov  wrote:
> One option would to patch libsndio to try more devices (how many?).

I've also noticed this issue and have hacked libsndio to try snd/0 and
snd/1 first, which is basically the same as your suggestion.

> A nicer approach would be to handle this in sndiod [...]

That would be fantastic, but seems like quite a lot of work. I don't
know enough about the audio stack to really comment, but can't there
be problems with a device changing for the program mid stream? Or
would you add a special "trunk-like" pseudo device?

What do you think of adding a separator to AUDIODEVICE, to be able to
list more than one device (like : or ;)? Then libsndio just tries them
one after another, and you don't have to guess how many. It's a simple
backwards-compatible fix, but it doesn't address device migration.

I guess fixing it in sndiod is the right way, though.

Re: sndiod fallback trouble

[Alexandre Ratchov]

On Fri, Feb 26, 2016 at 07:18:06PM -0500, Michael Reed wrote:
> Hello,
> 
> I use OpenBSD on my laptop to listen to music, using an external DAC
> (USB) at home and built-in audio elsewhere.
> 
> In rc.conf.local I have
> 
>   # see http://thread.gmane.org/gmane.os.openbsd.misc/213373/focus=213377
>   sndiod_flags=-m play -f rsnd/1 -f rsnd/0
> 
> with the intention of using rsnd/1 (USB DAC) when it's available, and rsnd/0
> (built-in audio) when it's not.  However, this is what actually seems to
> happen when the USB DAC isn't plugged in (see DEFAULTS section in sndio(7)):
> 
>   - audio program tries to connect to snd/0, which fails because it doesn't
> exist (snd/0 is a sub-device of rsnd/1 (USB DAC), which isn't plugged in)
> 
>   - audio program then tries rsnd/0 (/dev/audio0), which works
> 
> The trouble is that, as shown by the second bullet, sndiod(8) is being
> completely bypassed if the USB DAC isn't plugged in:
> 
>   # fuser -u /dev/audio[0-2]# sndiod_flags=-m play -f rsnd/1 -f rsnd/0
>   /dev/audio2:
>   /dev/audio1:
>   /dev/audio0: 18636(_mpd)
> 
> If I set sndiod_flags to empty, then sndiod is no longer bypassed
> 
>   $ fuser -u /dev/audio[0-2] # sndiod_flags=
>   /dev/audio2:
>   /dev/audio1: 3291(_sndio)
>   /dev/audio0:
> 
> but, of course, the USB DAC won't be used at all.
>
> With that said, I'm wondering if it's even possible to set up sndiod so that
> (1) my USB audio device is always used when available and (2) sndiod isn't 
> bypassed
> if the DAC isn't available.
> 
> After reading various sndio/audio manual pages I'm still somewhat
> confused, so any help would be much appreciated.

Your understanding is right; this is a sndiod limitation.  We don't
have the code yet to do what you want.

One option would to patch libsndio to try more devices (how many?).

A nicer approach would be to handle this in sndiod by allowing
sub-devices (aka -s options) to change their device (aka -f
option).  The advantage of doing it in sndiod is that later this
could happen dynamically (ex.  unplug usb cable and programs
migrate to another device).