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

[Raymond]

In theory, and sound cards with hardware mixing can support this kind of
volume control.

au88x0 driver may provide this kind of volume control on playing PCM
streams by using hardware mixers.

However the hardware mixers are dynamically allocated in routine
snd_vortex_pcm_hw_params(), this means that the kcontrol can be put/get
only between snd_pcm_hw_params() (return no error) and
snd_pcm_hw_free()/snd_pcm_close().

Is there any flag in kcontrol which enable/disable the put/get from
mixer application ?

How do the alsa mixer application get notification when a PCM stream is
play by another alsa application ?

May be the volume controls can only be accessed by the alsa application
which open the PCM stream. (e.g. The hardware acclerated version of
openal http://www.lost.org.uk/openal.html or sound mixing/recording
application )

Is there any limitation of ctlid if the kcontrol is dynamically created
on snd_vortex_pcm_hw_params() and deleted on snd_vortex_pcm_hw_free() ?

There is no need for alsactl to store/restore the values of these kind
of volume controls.

Clemens Ladisch wrote:
> Takashi Iwai wrote:
>
>
> > At Wed, 27 Jul 2005 10:30:36 +0200,
> > I wrote:
> >
> > > The problem is that it's not clearly defined how to find the bound
> > > control for the currently opened pcm.  We may assume that the index
> > > number corresponds to the substream index, but this may be different
> > > on drivers.
> >
> > Well, I mean, we have no API for providing this information.
> > Not only PCM but other controls (e.g. effects like chorus/reverb)
> > would be bound to a PCM voice, so only defining consistent control
> > names wouldn't suffice.
> >
> > I believe PCM iface attribute could be used for such a purpose,
>
>
> As far as I see, the iface/device/subdevice fields were designed for
> exactly this purpose, i.e., associating a control with a specific
> (sub)device.
>
>
> > but unfortunately, the situation is confusing.  Some drivers
> > already use PCM iface for different purposes (e.g. hdsp) and some
> > use mixer iface for exactly this purpose (e.g. emu10k1)...
>
>
> Then I'd consider these drivers buggy.
>
> I'll write a patch unless anybody objects ...