[oss-devel] mixer API question about rec buttons (bug in SNDCTL_MIX_WRITE? )

[Hannu Savolainen]

Yair K. kirjoitti:
> On Sunday 03 February 2008 19:04:33 Hannu Savolainen wrote:
>   
>> Hi,
>>
>>     
>>> Hi,
>>>
>>>   Most mixers contain "rec" buttons which let the user select recording
>>> source. Some mixers let multiple recording sources be selected.
>>>
>>> A. When setting the on/off value with SNDCTL_MIX_WRITE on a rec button,
>>> val.value is always returned as 1. Shouldn't it be 0 or 1 according to
>>> whether the source is selected?
>>>       
>> Right. This is a bug. It will be fixed in the next version.
>>
>>     
>
> On a more general complaint, there's a problem with the MIXT_ONOFF type - the 
> mixer application can't tell what they do. Let us examine a not uncommon use 
> case: A mixer application wants to make sure a certain control is muted[0].
>   
The main design princeple of the OSS 4.0 API has been to make it 
impossible to applications to figure out anything. The app should just 
show whatever is provided by the device and let the user to figure out 
what the control does.

In addition "normal" applications such as audio/media players/recorders 
should not use the mixer interface at all. Instead they should use the 
new audio API calls such as 
SNDCTL_DSP_SET_RECSRC/PLAYTGT/RECVOL/PLAYVOL. The mixer API is reserved 
for "privileged" utilities like ossxmix.

It is possible to implement applications that mute/unmute some controls 
by looking for a control with given name (say "front.mute"). However 
this kind of applications are not portable between devices.

> Well, we could set the control to zero.
> Except that according to the manual[1], this may not be enough, there may a 
> separate mute control.
> We can reasonably assume it's a control with type MIXT_ONOFF in the group 
> assigned to the control we want to mute (even though the manual doesn't say 
> that).
> But there may be more than one MIXT_ONOFF control (let's say it can be used as 
> a recording source, so we have a "rec" button). Which one is the mute button? 
> We can check for the name. It may labeled "mute", but it can also be labeled 
> as "silence", or "quiet", etc. So we don't have any way of actually being 
> sure.
>
>  Now, there are far too many device-specific options for everything to be 
> standardized, but currently, too little is standard, and it harms some use 
> cases[2]. I think the recording source selection and channel muting in 
> particular are affected.
>   
Devices can be very different. Old style consumer devices (like AC97) 
have predefined controls for cd, mic, line-in, etc. However professional 
audio devices don't usually have anything like this. Even the latest 
consumer devices don't fit in this model. They may have several 
independent recording engines which all have independent recording 
source selection. In addition the recording source selection may be 
based on a source selector (MIXT_ENUM), mute buttons or volume sliders 
for multiple parallel sources. It has proven to be pretty much 
impossible to define any predefined set of control names that works with 
all devices (past, present and future).
> IMHO, There are two possible solutions:
>   1. Gurantee "mute" name for mute buttons, "rec" for recording source 
> selection, etc.
>   2. Use the flags field to tell what the button does. mute buttons can have 
> MIXF_*VOL for example, since they do control the volume in a way. Not sure 
> about "rec" buttons.
>   
I have planned to add MIXT_MUTE that works like MIXT_ONOFF. However GUI 
applications can show special mute button widget for them instead of 
using the check box widget. In this way it's not necessary to have 
"mute" in the control name (which saves some space on the GUI).
> [0] Like a tv-recording app which wants to make sure "line" is muted, so that 
> the user won't hear the recording while it's being made. 
Applications cannot assume that TV audio comes from input that is named 
as "line", "tv" or "video". The TV audio signal can come from inputs 
like "analog1/2", "blue", or"hdmi-in" as well. Who knows what kind of 
devices we will have after 10 years. Applications need to be written in 
a way that they work without modifications or even recompile with any 
device.
> Making it call ossmix 
> doesn't solve anything, since the question simply become "what commands do we 
> send to ossmix?" rather than "what ioctls do we send to /dev/mixer?".
> [1] http://manuals.opensound.com/developer/mixer_value_scaling.html
> [2] Maybe we want to place "rec" buttons below the slider, but "mute" buttons 
> above, like kmix does.
>   
Typically applications should use SNDCTL_DSP_SET_RECSRC to select the 
recording source. Alternatively it could show the user a list of 
available mixer controls and let him/her to decide which ones should be 
set to predefined value.

Best regards,

Hannu