Re: [Openvortex-dev] Re: [Alsa-devel] Re: Volume per voices [Feature Request]

[Alien]

> Hi,
>
> On 7/28/05, Maarten Vanraes <address@hidden> wrote:
>> > Raymond wrote:
>> >> There is no need for alsactl to store/restore the values of these
>> kind
>> >> of volume controls.
>> >
>> > Indeed.  Most applications just get the first free substream.
>> > Allowing the user to change 16 (or 32) different volume controls just
>> > doesn't make sense in this context.
>>
>> maybe an application should only change it's own volume control (not the
>> master volume control); if there is no such thing, it can make it in
>> software.
>
> I totally agree with that. Such a interface should handle not only
> volume (gain) IMHO. There are many other caracteristics that would be
> "very" interesting to make available to applications. Hopefuly one
> should be able to do gain or whatever settings using the PCM device
> handle, without requiring to figure out control names. Just like
> setting hwparams, but something that is possible to do in while the
> PCM device is running. By the way, why cant hwparams be set while the
> PCM device is running ? Many cards support changing samplerate and
> such while running (doppler effect simulation).
>
>> but! shouldn't it also be possible to make an application that can
>> change
>> all these volume controls? like a switchboard or something?
>
> There is a problem with that, because you never know, which
> application is using which subdevice. Even if you know that, many
> application open the PCM device just for the amount of time required
> to do playback/recording. That means that you wont be fast enough
> trying to catch a gain setting with your mouse or keyboard. And for
> the next time a application makes use of a PCM device, it could be a
> different one, and the question arrises, how do you remember the
> setting of a application on a specific device ?
>
> Better let each application handle that kind of controls/settings. If
> they don't do, then its the applications fault.

you have a good point there, but it might be usefull anyway...

at start, show only the ones used at that time, if there are added, add
them; if there are deleted, don't delete them, but remember and hold,
cause if new ones start, these get used anyway, and you can force it on
the newly started application as a default value, if the appl does it
himself, it just gets changed, one could even reset it or deny the appl to
change it...