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

[qwx@sciops.net]

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