From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <2577c8.0aa552af.tqKm.mx@tumtum.plumbweb.net> <2577c8.fe23c316.C0kk.mx@tumtum.plumbweb.net> <2577c9.12b19530.giyO.mx@tumtum.plumbweb.net> <6CCD7B4C-B298-4F85-91CD-DCD750E946D9@9srv.net> Date: Wed, 27 Oct 2010 14:05:15 -0700 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016e644025ef7021804939f943b Subject: Re: [9fans] kw audio -- /dev/audio and friends Topicbox-Message-UUID: 6fbc291c-ead6-11e9-9d60-3106f5b1d025 --0016e644025ef7021804939f943b Content-Type: text/plain; charset=ISO-8859-1 It seems like that would be a reasonable approach, to translate one older interface to the next, if needed, as a compatibility FS. In fact, one such compatibility FS could serve several translations. The best way to deal is to force everyone to update now, or cease functioning, in my opinion. This is where that 'benevolent dictator' approach can really be an advantage, and the disturbance is not usually too bad if you're in a small enough community. Dave On Wed, Oct 27, 2010 at 1:07 PM, Skip Tavakkolian < skip.tavakkolian@gmail.com> wrote: > would it be hard to provide the backward compatibility via a user fs > -- at least until apps are updated to the new structure? > > On Wed, Oct 27, 2010 at 11:58 AM, Anthony Sorace wrote: > > I've misplaced my USB audio kit, but I'm reasonably sure I read from > /dev/audio (and a cursory reading of the source suggests that ought to > work). Is there any reason to do otherwise? I don't know what audioin is > intended to buy. Given that it's never been in audio(3), I'm not sure it's > important to support it. > > > > It's unfortunate that volume and audioctl don't support the same > language. Don't add another. It's pretty easy to handle both; see > /sys/src/cmd/usb/audio/audiofs.c. The one for audioctl is reasonably regular > and comprehensive; it'd be nice to standardize our audio interfaces around > that. > > > > I'm more interested in audiostat. I don't see that in the usb > implementation, and I'm not clear on whether it could be provided there. > Anyone know? Should audio programs treat that as optional? > > > > "deprecation" in unix is a mess, where things can stay "deprecated" for > ages. it'd be nice to be able to say "/dev/volume (or /dev/eia0status) was a > mistake; here's a backwards-compatible improvement, and the old stuff goes > away in 6 months." > > > > > > --0016e644025ef7021804939f943b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It seems like that would be a reasonable approach, to translate one older i= nterface to the next, if needed, as a compatibility FS. =A0In fact, one suc= h compatibility FS could serve several translations. =A0The best way to dea= l is to force everyone to update now, or cease functioning, in my opinion. = =A0This is where that 'benevolent dictator' approach can really be = an advantage, and the disturbance is not usually too bad if you're in a= small enough community.

Dave

On Wed, Oct 27, 2010 = at 1:07 PM, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> would it be hard to provide the backward compatibility via a user fs
-- at least until apps are updated to the new structure?

On Wed, Oct 27, 2010 at 11:58 AM, Anthony Sorace <a@9srv.net> wrote:
> I've misplaced my USB audio kit, but I'm reasonably sure I rea= d from /dev/audio (and a cursory reading of the source suggests that ought = to work). Is there any reason to do otherwise? I don't know what audioi= n is intended to buy. Given that it's never been in audio(3), I'm n= ot sure it's important to support it.
>
> It's unfortunate that volume and audioctl don't support the sa= me language. Don't add another. It's pretty easy to handle both; se= e /sys/src/cmd/usb/audio/audiofs.c. The one for audioctl is reasonably regu= lar and comprehensive; it'd be nice to standardize our audio interfaces= around that.
>
> I'm more interested in audiostat. I don't see that in the usb = implementation, and I'm not clear on whether it could be provided there= . Anyone know? Should audio programs treat that as optional?
>
> "deprecation" in unix is a mess, where things can stay "= ;deprecated" for ages. it'd be nice to be able to say "/dev/v= olume (or /dev/eia0status) was a mistake; here's a backwards-compatible= improvement, and the old stuff goes away in 6 months."
>
>


--0016e644025ef7021804939f943b--