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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
