[EMAIL PROTECTED] kirjoitti: > Hi, > > unfortunately I can't test the mic boost, because I don't have a microphone > or > headset, currently. The codec reported is AD1888. > > About the general usage of maxvalue.. I guess I got that, kmix seems to work > correctly there now. Well, I currently face some problems with its limited > API, though. That's why I need to ask further questions. > > E.g. I got the following routine to find, whether the given mixext allows > recording source choice ($mainclass.rec). In there I assume that a > $mainclass.rec is always one element after $mainclass. Is that assumption > correct? > It's not correct. The fact is that you cannot make any assumptions about the mixer. It's all dynamic and depends on the actual device. So applications using the mixer API should handle all the controls fully transparently. Also applications using /dev/dsp too are not permitted to use the mixer API for things like recording source selection.
You cannot assume that recording source selection is always $mainclass.rec. This is only true for older (AC97/etc) sound cards that are now mostly out of production. Other devices may not have recording source selection capability at all, there may be multiple independent recording devices with independednt source selections or almost anything else. > > I read in the docs about SNDCTL_DSP_GET_RECSRC_NAMES etc., but those > access /dev/dsp* (well, any sound device) directly. I don't know how to get > there properly (more precise, which one I'd have to open then), that's why I > use that function instead. > If you are doing a mixer program then you cannot use the SNDCTL_DSP_ API. > Another remaining problem: Classify recording mixexts. Take a look at the > attached screenshot first. This shows the kmix oss4 backend on a machine with > VIA 823x AC97 (ALC658). None of the controls "Line" (line), "Microphone" > (mic), Aux1, Phone etc. have the MIXF_RECVOL flag set. > But "Microphone" for example definetly belongs to the recording controls .. > am > I missing something here? > For mixer applets similar to Windows and ALSA you can use the simplified version of the API. You can observe the MIXF_MAINVOL, MIXF_MONVOL, MIXF_PCMVOL and MIXF_RECVOL flags returned by SNDCTL_MIX_EXTINFO (http://manuals.opensound.com/developer/SNDCTL_MIX_EXTINFO.html). You can use these fields to group the controls under four bins: - Main volumes for speakers (front/rear/side/center/LFE/etc). - Monitor volumes (for example direct signal from mic->front). - PCM/wave volumes that control output level of applications. - Recording levels. However the above flags will only be used for the most important controls. There will be less important controls that don't have any of these flags present (they can be grouped under fift bin ("misc") but it will become really huge). Another problem is that in OSS4.0 all drivers don't support these flags (yet). Another alternative is to use the full API in the way ossxmix does it. In short you need to construct a tree based on the 'parent' fields. Then create an hierarchical widget structure that matches the tree. MIXT_GROUP/MIXT_ROOT nodes will become container widgets (hvox/vbox in GTK+) populated by the actual controls. This kind of fully featured mixers should not try to figure out what kind of function the controls have. This should be left to the user. Now with the new SNDCTL_MIX_DESCRIPTION feature the driver can tell the user what exactly the control is supposed to do (tooltips and help text). Best regards, Hannu _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
