[EMAIL PROTECTED] kirjoitti:
> Hi all,
>
> maybe you remember that I'm currently trying to add OSSv4 support to kmix.
> Most sliders already work as expected, dcop is currently misbehaving, but I'm
> quite sure to be able to solve the issues. To my question now:
> Old versions of kmix used OSS v 3.x macros to map mixer extension names (e.g.
> line0) to types (e.g. "Volume, Microphon" etc.). In the documentation of
> OSSv4 I read that mixer applications using the new mixer API shouldn't make
> any assumptions about the extension names. So how could I properly classify
> the mixer extensions?
>
Approach 1: Fully featured mixer
The idea is that all controls form a tree and the parent field links the
actual controls (sliders, etc) to a group (MIXT_GROUP). Groups in turn
may belong to other groups and finally to the root group (ctrl number 0
which has type=MIXT_ROOT). So the mixer application should not care
about the name or function the control performs. Instead it should just
collect the controls under a group subwindow/widget (vbox or hbox in
GTK). The leaf groups (containing controls) are then place inside the
subwindow/widget of some other group.
Approach 2: Simple mixer applet
An easier approach (that be better suited for kmix) is to check the
MIXF_MAINVOL, MIXF_PCMVOL, MIXF_RECVOL and MIXF_MONVOL bits of the flags
field (SNDCTL_MIX_EXTINFO). These flags are used to mark important
controls that are used to control main output volumes (for
front/rear/etc), audio/pcm/wave output volumes, recording volumes or
(direct input->output) monitor volumes. In this way kmix can simply
create(up to) 4 subwindows and group the controls under them. However
there are OSS drivers that don't support this approach yet (including
hdaudio). In addition only the most important controls will be marked in
this way (others can only be accessed using fully featured mixers like
ossxmix).
Approach 3: Quick and dirty way
Organize all the controls to a scrollable window. Each line represents
one control. Sliders and peak meters are implemented as horizontal
controls instead of vertical.
Approach 4: Grid view
Like above but use a grid widget. Each group/subgroup can be
expanded/collapsed which makes the GUI more compact vertically.
Each mixer control has two names (id and extname). The extname field
contains the "dotted" name used by ossmix (say "envy24.ratelock"). The
id field contains the
local/private name (without the group path). Older OSS drivers used
unique control names such as ENVY24_RATELOCK" which should be
downshifted and the part before the first "_" should be removed
("ENVY24_RATELOCK" -> "ratelock").
I hope this helps.
Best regards,
Hannu
> Furthermore I'd like to add that I currently drop all vmixX-out[Y].pcmY
> sliders, because I think it's not kmix duty to deal with vmix channels.
> Instead I only made vmixX-vol visibile. What do you think about that? Any
> other suggestions?
>
> Regards
>
> apriori
> _______________________________________________
> 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
