On Wed, May 12, 2010 at 08:41:28AM +0200, Clemens Ladisch wrote:
Daniel Mack wrote:
... Thanks! One of the noted TODOs is that UAC2 offers the ability to a device to dynamically change the supported range of options for a given control. So an enum-driven control can get new values, lose some, whatever. What would be the best way to map that to ALSA controls?
The control callbacks accept and return the new values; userspace gets notified of the changed control information with snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_INFO, &elem_id);
I'm quite sure that alsamixer can cope with this, but I don't know about any other mixers. :)
I think "alsactl restore" already does the right thing for controls that have changed.
Another thing that we would need to support at some time is clock selectors to switch from an internal clock to some external one. And this can also be notfied dynamically - so for example: once an external S/PDIF transmitter is connected, the driver gets informed about a new valid clock source. I haven't found anything how this could be passed on to higher levels from a driver, but I might have missed something :)
With a mixer control "Clock Source", of course. :) Or are you talking about new samples rates made available?
This is in theory possible, yet rather unlikely in reality. But a range descriptor for available (valid) clock sources could do such a thing.
Ok, I'll go ahead and implement it, and then see what it takes.
Thanks, Daniel