Hi again, the biggest problem with kmix is that it doesn't even has the possibility to form a tree layout. If it could, the dicussion here wouldn't go so long :P
The problem I see is, that even not so experienced users want to for example choose the recording source (or activate spdif, micboost and similar), which is supported by the kmix API with that red button below the sliders. If I really drop every other control but those with with the MIXF_MAINVOL etc. flags set, the whole point about writing this backend is.. well useless. The goal of the backend was to write something so that average users can very well live without having to work with ossxmix (and its tons of controls) at all. Maybe the OSS devs should go a step further and add more to the (I call it this way now) MIXF_MAINVOL etc. (simplified) layer of the mixer API, by adding a flag like "MIXF_COMMONCTL" or similar. To summarize, features that usually are expected by kmix's users are: - recording source choice (if available of course): for that I need an device independent way to find out if that's available (and also control the values) - main volume and recording volume controls, also with mute button (which is currently solved by just decreasing vol to 0, also here it would be better if there is some standard way to use the mute mixexts instead) - currently I'd like to make decrease to vol 0 a fallback and use .mute where possible. But I'll likely run into the problem again, that I mustn't make assumptions about the controls - that's a problem. - the most used buttons, e.g. micboost, spdif and it's options Kmix, as far as I know, is meant to be more than an applet, it's a so called "fully featured mini mixer", with the features I just described. For a conistent user experience kmix must able to able to fullfill the named features in a completly device independant way. E.g. you said that using the simplified mixer API with hdaudio based cards will fail - unfortunately it's hard to accept such a limitation. Looking forward to hear further suggestions from you. Best regards > Hi All, > > I have updated the mixer_applet.c sample program in the hg tree to > demonstrate how to sort the available mixer controls to different bins > or tab pages. > The idea behind providding two variants of the OSS4 mixer API may > require some clarification. Many modern sound devices (some HDaudio > codecs in particular) have huge amount of controls. Some of them are > required by normal users, some of them are used only for extreme > tweaking and some of them don't have any use at all. For this reason > there is need for fully featured "control panel" program which is > currently ossxmix (until somebody develops better). There may even be > room for device specific control panel programs (that use their own > private micer API) in case the stock mixer API is not adequate. > > However for majority of users the full control panel interface is > impossible to understand. For this reason there is need for more user > friendly mixerr applets like the Gnome and KDE ones. These applets only > pick the controls marked with the MIXF_MAINVOL/etc flags and show them > to the user. If there are no such controls or if the user presses an > [Advanced Options] button the applet may fire ossxmix. > > In addition to the mixer API the audio API has some ioctl calls that may > be redundant with the mixer API. These calls can be used to control > play/record volumes and to do recording source selection. The benefit of > these calls is that they will always handle the right part of the mixer. > Modern sound cards may have several recording engines with their private > source/level conrol. Applications that try to use the mixer API for the > same purpose have no chances to do it right. > > Best regards, > > Hannu > ------- > > Hannu Savolainen wrote: > > 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 > > _______________________________________________ > oss-devel mailing list > oss-devel@mailman.opensound.com > http://mailman.opensound.com/mailman/listinfo/oss-devel _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
