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