[9fans] kw audio -- /dev/audio and friends

[9fans] kw audio -- /dev/audio and friends

[Tristan Plumb]

i've been working on an an audio driver for the kirkwood for a while now,
indeed it's been working well for a while now. at this point i'm mostly
struggling to figure out the mixer/controls/codec filesystem interface.

if any of this is incorrect, please correct me.

the soundblaster driver has audio for data and volume for control:
name [in l r] [out l r]

usb/audio has audio and audioin for data and audioctl for control:
name (in|out) val min [max [res]]
with writes looking like volume

as yet, i have audio and audioin with audioctl and audioinctl:
name min max( val)+
writes:
name( val)+

mostly this just feels better to me. it has both single and multiple
values, it can handle cards with more than one channel in or out (not
that i'm working with one), and it's simple. but it doesn't indicate
card-wide controls (i have a few), and it's yet another incompatable
interface.

do any of you folks have opinions on these interfaces? i would like to
use a simple and extendible interface for the kirkwood driver, and am
willing to convert the soundblaster and usb drivers and sound programs
(though i don't have the hardware to test).

tristan

--
All original matter is hereby placed immediately under the public domain.

Re: [9fans] kw audio -- /dev/audio and friends

[Russ Cox]

Changing a device's file format in a backwards-incompatible way
is not something to be done lightly.  In addition to changing all
drivers you'd have to change every user program that reads from
or writes to them, even ones that you don't know exist.

Russ

Re: [9fans] kw audio -- /dev/audio and friends

[erik quanstrom]

On Tue Oct 26 10:32:15 EDT 2010, rsc@swtch.com wrote:
> Changing a device's file format in a backwards-incompatible way
> is not something to be done lightly.  In addition to changing all
> drivers you'd have to change every user program that reads from
> or writes to them, even ones that you don't know exist.

great point.  this thinking should be applied to changing even
simpler interfaces, like the uart one.

- erik

Re: [9fans] kw audio -- /dev/audio and friends

[Tristan Plumb]

> Changing a device's file format in a backwards-incompatible way
> is not something to be done lightly.  In addition to changing all
> drivers you'd have to change every user program that reads from
> or writes to them, even ones that you don't know exist.

i am not offering to change the interface, but to implement a simpler
third interface (as usbaudio implements volume). poor diction on my part.

the point is that there are currently two semi-incompatable interfaces,
do people consider the current two adequate? (apparently volume was not,
and i don't consider audioctl to be). and what do other people think
about an alternative?

tristan

--
All original matter is hereby placed immediately under the public domain.

Re: [9fans] kw audio -- /dev/audio and friends

[Lucio De Re]

On Wed, Oct 27, 2010 at 08:30:29AM -0400, Tristan Plumb wrote:
>
> i am not offering to change the interface, but to implement a simpler
> third interface (as usbaudio implements volume). poor diction on my part.
>
No one is going to "reject" your efforts, although it may be harder
to get them "accepted" into the distribution.  But if you can make the
results backwards compatible, one assumes there will be others who will
make good use of them.

But if the encouragement you seek is, as is often the case around here,
more a request for approval, _that_ is seldom granted here.  Also,
actual contributions from the audience are rare, specially positive ones.
Don't look for such and go ahead and code, that is what gets you noddy
points :-)  If you have a specific question, this is a great place to
get an answer, not a great place to give shape to vague ideas.

I sincerely hope the above can be construed as encouragement, it is
certainly intended as such.

++L

Re: [9fans] kw audio -- /dev/audio and friends

[erik quanstrom]

> i am not offering to change the interface, but to implement a simpler
> third interface (as usbaudio implements volume). poor diction on my part.
>
> the point is that there are currently two semi-incompatable interfaces,
> do people consider the current two adequate? (apparently volume was not,
> and i don't consider audioctl to be). and what do other people think
> about an alternative?

- why do you assume that the old interface was not considered
sufficient?
- if you read usb(4) the first sentence on usb audio notes the
interface is backwards compatable.  is your interface backwards
compatible with the other two?

- erik

Re: [9fans] kw audio -- /dev/audio and friends

[Tristan Plumb]

> - why do you assume that the old interface was not considered
> sufficient?
if volume were sufficient, there was no reason to add audioctl.

> - if you read usb(4) the first sentence on usb audio notes the
> interface is backwards compatable.
it notes that the names are backwards compatable, but audio only accepts
writes (or so it appears). in terms of the volume file, yes.

> is your interface backwards compatible with the other two?
my interface does not conflict with either of the other two (the
filenames do not overlap), and mapping aud[io]ctl to volume is trivial,
unless multiple channels exist, which volume cannot express.

that said, i havn't written the backwards compatibility yet.

tristan

--
All original matter is hereby placed immediately under the public domain.

Re: [9fans] kw audio -- /dev/audio and friends

[Anthony Sorace]

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

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."


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [9fans] kw audio -- /dev/audio and friends

[Skip Tavakkolian]

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 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."
>
>

Re: [9fans] kw audio -- /dev/audio and friends

[David Leimbach]

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

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 <a@9srv.net> 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."
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 2362 bytes --]

Re: [9fans] kw audio -- /dev/audio and friends

[Tristan Plumb]

> Anthony:
> The one for audioctl is reasonably regular and comprehensive; it'd be
> nice to standardize our audio interfaces around that.

my concern with audioctl is multiple channels. for now control-left and
control-right are fine (if clunky), with 5.1 (or 7.1) audio that becomes
control^(1 2 3 4 5 6), yuck. maybe we should worry about that when we get
there, but as there are still very few drivers, the impact is less now.

the other problem with both volume and audioctl will come with multiple
streams. in1 and out1 might work, but it starts to look ugly. usbaudio
appears to ignore multiple inputs or outputs.

> "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."

> Skip:
> would it be hard to provide the backward compatibility via a user fs --
> at least until apps are updated to the new structure?

that was exactly what i was planning to write. if audio stops working
running a compatibility fs isn't a big deal. but for anything involved in
the access to the system... it can be. (anybody have network over audio?)

tristan

--
All original matter is hereby placed immediately under the public domain.

Re: [9fans] kw audio -- /dev/audio and friends

[Anthony Sorace]

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

> the other problem with both volume and audioctl will come with multiple
> streams. in1 and out1 might work, but it starts to look ugly. usbaudio
> appears to ignore multiple inputs or outputs.

i'm not entirely sure what you mean by "streams" in this context. multiple inputs or outputs? if so, my first pass would be do something like what #l does: #l0, #l1, &c. Alternately, let any (theoretical future) driver for such a thing implement /mnt/fancydriver/0/audio &c, and bind as needed.

> (anybody have network over audio?)


that'd be fun. ppp over audio coupling? :-)


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [9fans] kw audio -- /dev/audio and friends

[yy]

2010/10/28 Anthony Sorace <a@9srv.net>:
>> the other problem with both volume and audioctl will come with multiple
>> streams. in1 and out1 might work, but it starts to look ugly. usbaudio
>> appears to ignore multiple inputs or outputs.
>
> i'm not entirely sure what you mean by "streams" in this context. multiple inputs or outputs? if so, my first pass would be do something like what #l does: #l0, #l1, &c. Alternately, let any (theoretical future) driver for such a thing implement /mnt/fancydriver/0/audio &c, and bind as needed.
>

Wouldn't it be better to use #A0, #A1, ... for the case of multiple
audio devices instead of multiple in/outs in one device? I don't see
why control^(1 2 3 4 5 6) or in1, out1 are so ugly (specially
considering that this is just a potential "problem").

-- 
- yiyus || JGL . 4l77.com

Re: [9fans] kw audio -- /dev/audio and friends

[Tristan Plumb]

>> multiple inputs or outputs? if so, my first pass would be do something
>> like what #l does: #l0, #l1, &c.
> Wouldn't it be better to use #A0, #A1, ... for the case of multiple
> audio devices instead of multiple in/outs in one device?
that would make sense to me, though if there's a ethernet card that had
multiple interfaces in an analogous way, #l0, #l1 would probably be used.

> I don't see why control^(1 2 3 4 5 6) or in1, out1 are so ugly
> (specially considering that this is just a potential "problem").
the cs42l51 (the codec used on the openrd) audioctl looks like this:

power in 1 0 1
pgapower in 1 0 1
boost in 0 0 1
micdiff in 0 0 1
micbias in 0 0 3 1
micboost0 in 0 0 1
micboost1 in 0 0 1
gain0 in 0 -6 24 1
gain1 in 0 -6 24 1
atten0 in 0 -96 0 1
atten1 in 0 -96 0 1
vol0 in 0 -103 24 1
vol1 in 0 -103 24 1
mute0 in 0 0 1
mute1 in 0 0 1
power out 1 0 1
hpgain out 3 0 7 1
vol0 out 0 -103 24 1
vol1 out 0 -103 24 1
mute0 out 0 0 1
mute1 out 0 0 1
treble out 0 -21 24 1
bass out 0 -21 24 1
volume0 out 0 -204 12 1
volume1 out 0 -204 12 1
mix0 out 0 0 3
mix1 out 0 0 3

with my current incarnation that becomes:
audictl:
power 0 1 1
pgapower 0 1 1
boost 0 1 0
micdiff 0 1 0
micbias 0 1 0
micboost 0 1 0 0
gain -6 24 0 0
atten -96 0 0 0
vol -103 24 0 0
mute 0 1 0 0

audoctl:
power 0 1 1
hpgain 0 7 3
vol -103 24 0 0
mute 0 1 0 0
treble -21 24 0
bass -21 24 0
volume -204 12 0 0
mix 0 3 0 0

to me, that is ugly, without in1 and out1. ugly enough to talk about
change, maybe not ugly enough to change.

volume is fairly nice: (except with percentages of the range)

power in 1 out 1
pgapower in 1
boost in 0
micdiff in 0
micbias in 0
micboost in 0 0
hpgain out 3
gain in 0 0
atten in 0 0
vol in 0 0 out 0 0
mute in 0 0 out 0 0
treble out 0
bass out 0
volume out 0 0
mix out 0 0

and easially extendable:
vol in 0 0 0 0 0 0 out 0 0 0 0 0 0 out1 0 0 0 0 0 0

but it doesn't give the ranges.

? vol -103 24 in 0 0 out 0 0

which looks liable to break things (out being optional).

tristan
(with apologies for such a long post)

--
All original matter is hereby placed immediately under the public domain.

Re: [9fans] kw audio -- /dev/audio and friends

[Gorka Guardiola]

On Thu, Oct 28, 2010 at 2:38 PM, Tristan Plumb <9p-st@imu.li> wrote:
>>> multiple inputs or outputs? if so, my first pass would be do something
>>> like what #l does: #l0, #l1, &c.
>> Wouldn't it be better to use #A0, #A1, ... for the case of multiple
>> audio devices instead of multiple in/outs in one device?
> that would make sense to me, though if there's a ethernet card that had
> multiple interfaces in an analogous way, #l0, #l1 would probably be used.
>
>> I don't see why control^(1 2 3 4 5 6) or in1, out1 are so ugly
>> (specially considering that this is just a potential "problem").
> the cs42l51 (the codec used on the openrd) audioctl looks like this:
>

I am guessing the io in audio does not mean in/out.
I think audioinctl audiooutctl is a little bit more readable.
At least do audinctl audoutctl if you are shooting for shortness.
--
- curiosity sKilled the cat

Re: [9fans] kw audio -- /dev/audio and friends

[Tristan Plumb]

> I am guessing the io in audio does not mean in/out.
i was just changing the name to not overlap, and bacronyms are fun.

> I think audioinctl audiooutctl is a little bit more readable.
agreed.

--
All original matter is hereby placed immediately under the public domain.