(Sorry for the delay, I don't have much free time.)
Daniel Mack wrote:
On Fri, Jun 24, 2011 at 5:58 PM, Clemens Ladisch clemens@ladisch.de wrote:
I think the best solution would be to move the USB streaming into a module, add implicit feedback support there, and create a separate driver for the FTU and similar devices.
However, I'm not sure whether making a special driver for the FTU is really the way to go. Even though I haven't seen any device around yet that implements this in a class-compliant way, this type of streaming model is in fact part of the USB Audio specification, at least in version 2. It's more than likely that there will be more devices around in the future, and so it would be good to have support for it in the standard driver.
Only the parts that are different would go into the separate drivers. This would be device detection, parsing of the descriptors, stream management and configuration (i.e., choosing and setting alternate settings, and class-specific interface/endpoint requests), and most of the interfacing with the ALSA framework. (USB Audio 1.0 and 2.0 are not really compatible, so the latter might become a separate driver, too.)
Common parts (snd-usb-lib) would be the actual streaming (sending/ receiving packets, buffer handling), and whatever random stuff turns out to be needed by multiple drivers.
Can you outline how the API will look like?
Something like this:
struct usb_pcm_stream;
usb_pcm_stream_init(stream, snd_pcm_stream, usb_device, flags); usb_pcm_stream_destroy(stream);
usb_pcm_stream_configure(stream, endpoint, rate, format); usb_pcm_stream_set_clock_source(stream, master_stream);
usb_pcm_stream_start(stream); usb_pcm_stream_stop(stream);
// helpers to implement ALSA PCM callbacks usb_pcm_stream_pcm_prepare(stream); usb_pcm_stream_pcm_trigger(stream, start); usb_pcm_stream_pcm_pointer(stream);
(There are obvious similarities with firewire/amdtp.c.)
As far as I can tell, this affects mostly urb.c.
Regards, Clemens