[alsa-devel] A plea for help on mixer support for Fast Track Ultra (8R)

[Felix Homann]

Please, Clemens, Daniel and Takashi.

Every single one of you knows at least one way of doing it correctly. I 
don't.

I don't understand most of your suggestions, I don't understand the 
whole quirk framework. I'm just a layman who knows one way of making the 
FTU mixer work which would break others (just by calling 
snd_usb_create_mixer() too many times).

The "blueprint patch" I've send is very small. It's just three 
functions, one of them is very simple the others are almost identical to 
already present functions.

So please, couldn't someone fill the gap between what I have found and a 
proper implementation? As I see it, you might easily spend the same 
amount of time explaining to me how it should be done or why my next 
proposed patch (which would probably take at least a couple of weeks) is 
not acceptable and so on. But this would probably run for weeks or even 
months.

Please, help.

Thanks,

Felix

Am 19.05.2011 09:24, schrieb Takashi Iwai:
>
> In this particular case, you can call snd_usb_create_mixer() then
> create your mixer elements in addition in your quirk function.  This
> is more straightforward than adding branches in multiple points.
>
> Of course, there can be some room for refactoring to share codes
> between different quirks.  But it's a thing to be done in quirk
> codes.
> What I'm thinking is also to keep the thing simple.
> My points are:
>   - Try to avoid conditional branches, don't touch the main path as
>     much as possible
>   - You can call the standard parsers in the quirk itself
>   - You can create additional mixer contents in the quirk as well
>     (so just use your simplified snd_ftu_controls_create()).


Am 19.05.2011 09:15, schrieb Clemens Ladisch:
>
> So create a FTU mixer quirk for intf 0 (or a generic quirk
> with a separate table of mixer controls).
>

Am 18.05.2011 23:30, schrieb Daniel Mack:
> Well in that case, I would add the mixers in
> mixer_quirks.c just like you did in your patch, but I would basically
> copy some code from build_feature_ctl() and allocate and fill a
> special cval from within your quirk function. I would suggest making
> usb_feature_unit_ctl (the struct) public (remove the static, prefix
> the name with snd_usb_ and add the prototype to the header), so you
> can reference it from mixer_quirks.c. That way, you would keep all the
> _info, _get and _put functions privately to mixer.c, but still have
> the ability to reuse most of the code. You just need to fill your cval
> with data the generic functions can cope with. Does that make sense?
>