At Tue, 6 Oct 2009 11:00:18 +0200 (CEST),
Jaroslav Kysela wrote:
>
> On Tue, 6 Oct 2009, Takashi Iwai wrote:
>
> > At Tue, 6 Oct 2009 10:23:56 +0200 (CEST),
> > Jaroslav Kysela wrote:
> >>
> >> Hi,
> >>
> >> Some ideas, proposal for further discussion...
> >>
> >> On Mon, 5 Oct 2009, Stefan Schmidt wrote:
> >>
> >>> Hello.
> >>>
> >>> On Mon, 2009-10-05 at 11:14, Jaroslav Kysela wrote:
> >>>> On Mon, 5 Oct 2009, Stefan Schmidt wrote:
> >>>>
> >>>>> On Thu, 2009-10-01 at 17:08, Stefan Schmidt wrote:
> >>>>>>
> >>>>>> For an updated patch with all your comments inlcuded see below.
> >>>>>
> >>>>> Here is another update on this patch. Fixed a problem I introduced in the last
> >>>>> iteration and changed the config tokens from MasterPlaybackVolume to Master
> >>>>> Playback Volume, etc. That's based on a siggestion from Mark which we had
> >>>>> offlist. Let me quote it here to explain the good reasoning behind it.
> >>>>
> >>>> Question: What's the IDs (integers) returned with
> >>>> snd_scenario_get_master_playback_volume() etc. functions?
> >>>
> >>> That is part of the code Liam wrote, but let me answer it (and maybe
> >>> Liam chime in if it is wrong or needs more explanation).
> >>>
> >>> It's just the numid of an alsa control which should be used as master
> >>> playback, etc in this scenario. It aliases the function we can use with
> >>> ascenario to the real ones in alsa which can bedifferent for different
> >>> scenarios.
> >>
> >> It's not very clear. The exported functions should be documented at least
> >> with doxygen.
> >>
> >> Also, I would move all _get_ functions to one with this interface:
> >>
> >> #define SND_SCENARIO_KEY_KCTL_MASTER_PLAYBACK_VOLUME 1
> >> .....
> >>
> >> int snd_scenario_get(scenario, int key, void *result);
> >>
> >> It will allow us to extend this interface without adding many functions in
> >> future, something like:
> >>
> >> #define SND_SCENARIO_KEY_PCM_PLAYBACK 11
> >> .....
> >
> > I find it's good to have a generic interface, too, but a void pointer
> > is discouraging. It's too ambiguous and inconvenient when you use it
> > ("What type do I have to pass for SND_SCENARIO_XXX on earth???").
>
> It might be solved with inline functions in header files to cover all
> types. My opinion is to not use so much function in alsa-lib for each
> trivial interfaces.
>
> > I personally have no particular preference regarding the configuration
> > syntax between these two, but...
> >
> >> Also, I would like to consider moving the parser from alsactl
> >> initialization code (see alsactl_init.c in alsa-utils package) to alsa-lib
> >> and use this parser also for these files. It gives much flexibility,
> >> although udev-like syntax is not ideal, I know.
> >
> > Not ideal, it's awful :) So please don't spread it over...
>
> It's not so awful. The base syntax is very clear in form key->value
> binding. What's awful on this?
>
> CTL{reset}="mixer"
> CTL{name}="Master Playback Volume", CTL{value}="-21dB"
> CTL{name}="Master Playback Switch", CTL{value}="on"
> CTL{name}="Headphone Playback Switch", CTL{value}="on,on"
> CTL{name}="Front Playback Volume", CTL{value}="-29dB,-29dB"
> CTL{name}="Front Playback Switch", CTL{value}="on,on"
> CTL{name}="PCM Playback Volume", CTL{value}="0dB,0dB"
This is all fine, but as you wrote below:
> Solving complex tasks requires complex description.
This is the reality.
The alsactl's default config shows its limit.
> I'm open to
> discuss things to make this udev-like syntax more nice. The most
> irritating thing in this syntax are build-in commands for me, but having
> another special key for these actions are not a big win, because
> configuration writers must learn them.
The crazy goto is also painful. It reminds me the day of MS BASIC.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
