On Mon, Nov 16, 2009 at 11:02:34AM -0800, Garrett D'Amore wrote: > Edward Pilatowicz wrote: > >so i assume that in the man page below you'll be doing > >s/mixerctl/audioctl/. if that's the case then i wonder about the need > >for AUDIODEV support. AUDIODEV normally points to SADA style audio > >devices, right? but since your introducting a new audioctl tool, > >shouldn't it be designed to work on boomer audio devices, not SADA > >devices? > > Yes, it should have the "s/mixerctl/audioctl/". I am going to have > another set of updates, as since I've made changes to the code I've > altered a few more things. > > As far as $AUDIODEV goes, the code actually will work with either a > SADA device node or a Boomer node. The underlying code only > operates on Boomer nodes, but it operates by finding the associated > "mixer" device node for the device file you supply. > > So it will work to supply any of: > > /dev/audio > /dev/audioctl > /dev/sound/0 > /dev/dsp > /dev/dsp1 > /dev/sound/audiohd:0 > /dev/sound/audiohd:0dsp > /dev/sound/audiohd:0mixer > > The goal here is that end-users should not need to be aware of SADA > vs. Boomer. Those are API details. >
ok. but for familiarity sake (since those are common to all OSS based systems), and to facilitate any possible future removal of SADA compatibility, shouldn't we only document the new boomer interfaces? in this case the device path doesn't seem like an API detail. the user as to set AUDIODEV to something. since mixerctl(1) is SADA specific and legacy, it's ok for it to talk about /dev/audio* paths, but shouldn't any newish, non-legacy documentation (say audioctl(1)) and apis always refer to boomer/oss device paths? (note that i'm not talking about the implementation here, just the documentation that end users see.) ed
