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,UNPARSEABLE_RELAY autolearn=no autolearn_force=no
	version=3.4.4
Received: (qmail 14825 invoked from network); 20 Dec 2023 17:53:48 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 20 Dec 2023 17:53:48 -0000
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Wed Dec 20 12:52:50 -0500 2023
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1703094688;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=m+md9AcTaOnPXwl8Oc5PLcWfIH7p0JlpBA7dw8etZFM=;
	b=H/GeRl4EcDMS0Z8IEvqEcTDBDyZv/rBaQ+T8Xh+SnaDOi3GhBeSYxhEkCMLE7VGHE/ikNI
	nOl/e+2osQSlyZHepXi6mlibxjs7Fp1h9EARVhclc1xTrYsYHu7s4k6lKHreSUcYgQqpkw
	jVb7ZddhACCD1O6zdJUH410+RNCqTCs=
Received: from localhost (wopr.sciops.net [local])
	by wopr.sciops.net (OpenSMTPD) with ESMTPA id f4a3bbb2
	for <9front@9front.org>;
	Wed, 20 Dec 2023 09:51:28 -0800 (PST)
Date: Wed, 20 Dec 2023 09:51:28 -0800
From: Kurt H Maier <khm@sciops.net>
To: 9front@9front.org
Message-ID: <ZYMpoGnV_4vvV8la@wopr>
Mail-Followup-To: 9front@9front.org
References: <ZYMiKbk6pTfDe93V@wopr>
 <146BB18F210DE2AF418F9FDF65275339@wopr.sciops.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <146BB18F210DE2AF418F9FDF65275339@wopr.sciops.net>
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: private responsive component-aware app 
Subject: Re: [9front] [PATCH] Fix nusb/audio /dev entries
Reply-To: 9front@9front.org
Precedence: bulk

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