Edward Pilatowicz wrote:
> 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.)
>
Eventually, this whole AUDIODEV hack will go away. I don't want to
create a new environment variable. Users are used to dealing with
AUDIODEV, and it works well enough for now.
Frankly, were it not for Sun Ray, we wouldn't need AUDIODEV. OSS style
applications have no standard environment variable override.
- Garrett
