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 _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
