From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 14291 invoked from network); 20 Dec 2023 17:49:27 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 20 Dec 2023 17:49:27 -0000
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Wed Dec 20 12:48:02 -0500 2023
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1703094399;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=wwECGrS/0swdYU6tO5ALOq1BpHD7lNiGBAiHbQ3S9lc=;
	b=qrZHx5FLArSO4h21kMDxE8+mbyTd4iv7d4FSKxp//tOuVqgV5p1BZ+hu256ngvcW0EaLbj
	XMWB+3iDxJu3ua8h+cgPV4PS5KWJMmWtCYuyB1Ny8zU8CtkSEvXS04t26BiWbsQ64aUN5a
	tQn8tmI+HHJ+dDLuvzarlP0c9XULUFU=
Received: 
	by wopr.sciops.net (OpenSMTPD) with ESMTPSA id 36c79160 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Wed, 20 Dec 2023 09:46:39 -0800 (PST)
Message-ID: <146BB18F210DE2AF418F9FDF65275339@wopr.sciops.net>
Date: Wed, 20 Dec 2023 18:47:57 +0100
From: qwx@sciops.net
To: 9front@9front.org
In-Reply-To: <ZYMiKbk6pTfDe93V@wopr>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: scale-out CMS-aware frontend 
Subject: Re: [9front] [PATCH] Fix nusb/audio /dev entries
Reply-To: 9front@9front.org
Precedence: bulk

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