[9front] [PATCH] Fix nusb/audio /dev entries

[9front] [PATCH] Fix nusb/audio /dev entries

[Arne Meyer]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Hello,

commit 4bc5793a removed #u from default device binds. Now #u gets bound after #A in nusbrc. Because nusb/audio uses #u to provide its /dev/audio entries this means they are shadowed by the #A device and never picked up. So use 'bind -b' in nusbrc to prefer nusb/audio over #A.

Greetings,
Arne

[-- Attachment #2: nusbrc.patch --]
[-- Type: application/octet-stream, Size: 229 bytes --]

diff 34e7b54c139826b55713702910a1280e6651df60 uncommitted
--- a/rc/bin/nusbrc
+++ b/rc/bin/nusbrc
@@ -2,7 +2,7 @@
 
 if(! test -e '#σ/usb/usbevent')
 	exit
-if(! bind -a '#u' /dev)
+if(! bind -b '#u' /dev)
 	exit
 @{
 	rfork ne

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[qwx]

On Wed Dec 20 12:23:12 +0100 2023, meyer.arne83@netcologne.de wrote:

> Hello,
> 
> commit 4bc5793a removed #u from default device binds. Now #u gets bound after #A in nusbrc. Because nusb/audio uses #u to provide its /dev/audio entries this means they are shadowed by the #A device and never picked up. So use 'bind -b' in nusbrc to prefer nusb/audio over #A.
> 
> Greetings,
> Arne

Hi Arne,

Thanks for the patch.  One could argue against the previous behavior
-- what is your use case?

Here are some arguments against it:

- It pulls the rug under you by automatically changing the device you
write audio to, and imho the interaction between #u, #A and mixfs gets
confusing

- If more devices are plugged in, only the last one would be used,
switching output yet again

- If the usb device is disconnected, audio will break for programs
currently writing to /dev/audio and they would have to reopen it

It all amounts to having more control over what happens.  Obviously,
the old behavior might also be desired.  It might make more sense to
have the users themselves control which device to use as needed.  This
could be done automatically by watching /dev/usbevent and switching
accordingly, for instance in a machine-specific termrc or the user
profile, and possibly only for a given device.  One could also always
rearrange the namespace to get #u on top as before.

What do you think, would that work in your case?

Cheers,
qwx

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[Kurt H Maier]

On Wed, Dec 20, 2023 at 05:44:35PM +0100, qwx@sciops.net wrote:
> - If more devices are plugged in, only the last one would be used,
> switching output yet again

Not my circus, but isn't this how people would expect things to work?
If you plug in an audio device, surely you expect that to become the
active device?

> - If the usb device is disconnected, audio will break for programs
> currently writing to /dev/audio and they would have to reopen it

This sounds like a bug worth fixing -- we need aan for /dev/audio.  We
can call it aaa.

khm

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[qwx]

On Wed Dec 20 18:22:08 +0100 2023, khm@sciops.net wrote:
> On Wed, Dec 20, 2023 at 05:44:35PM +0100, qwx@sciops.net wrote:
> > - If more devices are plugged in, only the last one would be used,
> > switching output yet again
> 
> Not my circus, but isn't this how people would expect things to work?
> If you plug in an audio device, surely you expect that to become the
> active device?
I've relied on this behavior in the past, but it's not always what I
want for instance, I may connect a usb audio interface for recording,
then a synth that I'd like to interact with with MIDI but not write
audio to it; I would have to rearrange the namespace to make sure I
send audio where I want it, I can't just run play(1) or whatever.
Importing some other machine's #u, recording from a specific device,
reopening /dev/audio at runtime, interactions with the plumber...
There are fringe scenarios.  Point being, yes, but not always.  I
don't know what the right thing to do is.


> > - If the usb device is disconnected, audio will break for programs
> > currently writing to /dev/audio and they would have to reopen it
> 
> This sounds like a bug worth fixing -- we need aan for /dev/audio.  We
> can call it aaa.
> 
> khm

Well that's the thing, it's the intended behavior.  Should we
implement a new aaa(1) or just reorder the binds?  Dunno.  In
my case there are advantages on both sides.

Cheers,
qwx

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[Kurt H Maier]

On Wed, Dec 20, 2023 at 06:47:57PM +0100, qwx@sciops.net wrote:
> I've relied on this behavior in the past, but it's not always what I
> want for instance, I may connect a usb audio interface for recording,
> then a synth that I'd like to interact with with MIDI but not write
> audio to it; I would have to rearrange the namespace to make sure I
> send audio where I want it, I can't just run play(1) or whatever.
> Importing some other machine's #u, recording from a specific device,
> reopening /dev/audio at runtime, interactions with the plumber...
> There are fringe scenarios.  Point being, yes, but not always.  I
> don't know what the right thing to do is.

Ok, you've convinced me.  I withdraw my objection.

> Well that's the thing, it's the intended behavior.  Should we
> implement a new aaa(1) or just reorder the binds?  Dunno.  In
> my case there are advantages on both sides.

If there's a valid, configured audio device connected, writing to
/dev/audio shouldn't fail.  If the system is doing something which
causes that, then I'd call it a bug.  I understand it's not as simple as
this description, but we should at least have the cases where it happens
identified so we can put them in the faq or a wiki or something. 

khm

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[qwx]

On Wed Dec 20 18:51:48 +0100 2023, khm@sciops.net wrote:
> On Wed, Dec 20, 2023 at 06:47:57PM +0100, qwx@sciops.net wrote:
> > Well that's the thing, it's the intended behavior.  Should we
> > implement a new aaa(1) or just reorder the binds?  Dunno.  In
> > my case there are advantages on both sides.
> 
> If there's a valid, configured audio device connected, writing to
> /dev/audio shouldn't fail.  If the system is doing something which
> causes that, then I'd call it a bug.  I understand it's not as simple as
> this description, but we should at least have the cases where it happens
> identified so we can put them in the faq or a wiki or something. 
> 
> khm

To me, that's equivalent to not relying on the previous behavior and
having a watcher program, or maybe a change in mixfs as suggested on
#cat-v, to switch audio devices as specified by the user rather than
automatically.  Whether or not a program reopens /dev/audio when the
device disconnects or the driver crashes, but there is another audio
file, why should it now always be routed to this arbitrary one?  For
instance, you cannot yet control volume on usb audio cards which
currently just play at full blast, I've had accidents with that
(that one is a bug).  The point I'm trying to make is that the
previous behavior would hinder usage escaping the one typical case,
whereas a more manual approach would not, I hope that makes sense.

qwx

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[Arne Meyer]

Hello qwx,

> qwx@sciops.net hat am 20.12.2023 17:44 CET geschrieben:
> 
> Thanks for the patch.  One could argue against the previous behavior
> -- what is your use case?

I have a thin client with hda audio that is not quite working with the 9front driver. So
I use a cheap usb sound card to get audio. In this case I could probably do
'unmount #A' in a namespace file and have it work as intended?

> Here are some arguments against it:
> 
> - It pulls the rug under you by automatically changing the device you
> write audio to, and imho the interaction between #u, #A and mixfs gets
> confusing
> 
> - If more devices are plugged in, only the last one would be used,
> switching output yet again
> 
> - If the usb device is disconnected, audio will break for programs
> currently writing to /dev/audio and they would have to reopen it
> 

Yes, those are all good points.

> 
> What do you think, would that work in your case?

If I plug in a usb device I expect it to become the default device. Maybe mixfs
can do some clever stuff here?

> 
> Cheers,
> qwx

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[qwx]

On Wed Dec 20 19:54:05 +0100 2023, meyer.arne83@netcologne.de wrote:
> Hello qwx,
> 
> > qwx@sciops.net hat am 20.12.2023 17:44 CET geschrieben:
> > 
> > Thanks for the patch.  One could argue against the previous behavior
> > -- what is your use case?
> 
> I have a thin client with hda audio that is not quite working with the 9front driver. So
> I use a cheap usb sound card to get audio. In this case I could probably do
> 'unmount #A' in a namespace file and have it work as intended?

There's a few ways in which you can achieve this, but yeah I imagine
that something like `unmount '#A' /dev` at the right place is enough
for your purposes (eg.  /cfg/$sysname/termrc, $home/lib/profile,
etc.).  You can also disable the card in plan9.ini.  Of course, best
would be to fix the driver, but that's work.


> > What do you think, would that work in your case?
> 
> If I plug in a usb device I expect it to become the default device. Maybe mixfs
> can do some clever stuff here?

Maybe, but I'm not sure how that would work, and it would be a bunch
of additional code, when in reality the simplest thing you could do is
to unmount #A and #u and remount them in the opposite order, or in
your case, just unmount #A.  After the discussions I've had, I'm
leaning towards having the user configure this themselves (usually
this would be a one time setup), leaving a note about it in nusb(4).
So far, the people who have participated in the discussion have all
had somewhat different opinions about this, so imho it's not really
clear what the expected behavior would be for most.

Cheers,
qwx

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[Sigrid Solveig Haflínudóttir]

Write a tool (script?) that watches usbevent and does that. Run it in the right place so that namespace is updated properly for your programs.
Bonus: a tool (I'd suggest separate from mixfs) that does that but also provides its own /dev/audio that never craps out on writes unless there is no audio devices at all, and can be configured in runtime to point at different "real" devices for input and output.
That might be more useful than nusbrc running nusb/audio and modifying the namespace when one least expects it.

On December 20, 2023 7:53:57 PM GMT+01:00, Arne Meyer <meyer.arne83@netcologne.de> wrote:
>Hello qwx,
>
>> qwx@sciops.net hat am 20.12.2023 17:44 CET geschrieben:
>> 
>> Thanks for the patch.  One could argue against the previous behavior
>> -- what is your use case?
>
>I have a thin client with hda audio that is not quite working with the 9front driver. So
>I use a cheap usb sound card to get audio. In this case I could probably do
>'unmount #A' in a namespace file and have it work as intended?
>
>> Here are some arguments against it:
>> 
>> - It pulls the rug under you by automatically changing the device you
>> write audio to, and imho the interaction between #u, #A and mixfs gets
>> confusing
>> 
>> - If more devices are plugged in, only the last one would be used,
>> switching output yet again
>> 
>> - If the usb device is disconnected, audio will break for programs
>> currently writing to /dev/audio and they would have to reopen it
>> 
>
>Yes, those are all good points.
>
>> 
>> What do you think, would that work in your case?
>
>If I plug in a usb device I expect it to become the default device. Maybe mixfs
>can do some clever stuff here?
>
>> 
>> Cheers,
>> qwx

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[hiro]

agreed.
just it should also not crap out on writes when there is no audio
device at all. at first i thought like you, but now i slept about it
for a night and i realize khm was correct. usb audio is too flakey and
we don't want errors in other applications for intermittent usb crap.

On 12/21/23, Sigrid Solveig Haflínudóttir <sigrid@ftrv.se> wrote:
> Write a tool (script?) that watches usbevent and does that. Run it in the
> right place so that namespace is updated properly for your programs.
> Bonus: a tool (I'd suggest separate from mixfs) that does that but also
> provides its own /dev/audio that never craps out on writes unless there is
> no audio devices at all, and can be configured in runtime to point at
> different "real" devices for input and output.
> That might be more useful than nusbrc running nusb/audio and modifying the
> namespace when one least expects it.
>
> On December 20, 2023 7:53:57 PM GMT+01:00, Arne Meyer
> <meyer.arne83@netcologne.de> wrote:
>>Hello qwx,
>>
>>> qwx@sciops.net hat am 20.12.2023 17:44 CET geschrieben:
>>>
>>> Thanks for the patch.  One could argue against the previous behavior
>>> -- what is your use case?
>>
>>I have a thin client with hda audio that is not quite working with the
>> 9front driver. So
>>I use a cheap usb sound card to get audio. In this case I could probably
>> do
>>'unmount #A' in a namespace file and have it work as intended?
>>
>>> Here are some arguments against it:
>>>
>>> - It pulls the rug under you by automatically changing the device you
>>> write audio to, and imho the interaction between #u, #A and mixfs gets
>>> confusing
>>>
>>> - If more devices are plugged in, only the last one would be used,
>>> switching output yet again
>>>
>>> - If the usb device is disconnected, audio will break for programs
>>> currently writing to /dev/audio and they would have to reopen it
>>>
>>
>>Yes, those are all good points.
>>
>>>
>>> What do you think, would that work in your case?
>>
>>If I plug in a usb device I expect it to become the default device. Maybe
>> mixfs
>>can do some clever stuff here?
>>
>>>
>>> Cheers,
>>> qwx
>

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[Arne Meyer]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

Ok,

how about this? Bring audio more in line with the rest of nusb. Postfix all
the device nodes with U<hname> so we can have as much usb audio devices as we like
and are not dependent on bind order. 
The nusbaudio script can be put in termrc to provide the "old" behavior.

[-- Attachment #2: nusbaudio.patch --]
[-- Type: application/octet-stream, Size: 1430 bytes --]

diff 34e7b54c139826b55713702910a1280e6651df60 uncommitted
--- /dev/null
+++ b/rc/bin/nusbaudio
@@ -1,0 +1,28 @@
+#!/bin/rc
+
+if(! test -e /dev/audio)
+	aux/stub /dev/audio
+if(! test -e /dev/volume)
+	aux/stub /dev/volume
+
+@{
+	rfork e
+	fn attach {
+		switch($4){
+		case *01
+			sleep 2
+			bind /dev/audioU$5 /dev/audio
+			bind /dev/volumeU$5 /dev/volume
+		}
+	}
+
+	fn detach {
+		switch($4){
+		case *01
+			unmount /dev/audio
+			unmount /dev/volume
+		}
+	}
+
+	rc < '#σ/usb/usbevent' &
+}
--- a/sys/src/cmd/nusb/audio/audio.c
+++ b/sys/src/cmd/nusb/audio/audio.c
@@ -365,6 +365,7 @@
 	int dir = e->dir;
 	Aconf *c;
 	Range *f;
+	char buf[32];
 
 	for(;e != nil; e = e->next){
 		c = e->iface->aux;
@@ -395,9 +396,12 @@
 	devctl(d, "sampledelay %d", audiodelay);
 	devctl(d, "hz %d", speed);
 	if(e->dir==Ein)
-		devctl(d, "name audioin");
+		snprint(buf, sizeof buf, "name audioinU%s", audiodev->hname); 
 	else
-		devctl(d, "name audio");
+		snprint(buf, sizeof buf, "name audioU%s", audiodev->hname);
+	
+	devctl(d, buf);
+
 	return d;
 }
 
@@ -549,7 +553,8 @@
 		sysfatal("no output stream found");
 
 	fs.tree = alloctree(user, "usb", DMDIR|0555, nil);
-	createfile(fs.tree->root, "volume", user, 0666, nil);
+	snprint(buf, sizeof buf, "volumeU%s", audiodev->hname);
+	createfile(fs.tree->root, buf, user, 0666, nil);
 
 	snprint(buf, sizeof buf, "%d.audio", audiodev->id);
 	postsharesrv(&fs, nil, "usb", buf);

Re: [9front] [PATCH] Fix nusb/audio /dev entries

[hiro]

> how about this? Bring audio more in line with the rest of nusb. Postfix all
> the device nodes with U<hname> so we can have as much usb audio devices as
> we like
> and are not dependent on bind order.

oh in...deed.
thank you.