Re: [PATCH 1/2] ALSA: include/linux/usb/audio.h: add __attribute__((packed))

[Daniel Mack <daniel@caiaq.de>]

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