On Tue, 6 Oct 2009, Takashi Iwai wrote:
> [Forgot to follow up the first part]
>
> 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.
>
> Yes, but then why not providing functions for all types from the
> beginning? There shouldn't be so many different types.
Merging functions with same types might be a good compromise between one
function and separate functions for each values.
So at least, the API basics is now clear. I'll prepare a branch in
alsa-lib GIT tree to have a start point for first accepted implementation.
Jaroslav
-----
Jaroslav Kysela <perex@xxxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
