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).

sndiod fallback trouble

[Michael Reed]

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.

Regards,
  Michael Reed






OpenBSD 5.9 (GENERIC.MP) #1880: Sat Feb 20 16:48:33 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3941945344 (3759MB)
avail mem = 3818278912 (3641MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries)
bios0: vendor LENOVO version "G7ET98WW (2.58 )" date 12/16/2013
bios0: LENOVO 23539LU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! 
UEFI UEFI MSDM SSDT SSDT UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) 
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.51 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus -1 (EXP5)
acpiprt6 at acpi0: bus -1 (EXP6)
acpiprt7 at acpi0: bus -1 (EXP7)
acpiprt8 at acpi0: bus -1 (EXP8)
acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1