[alsa-devel] M-Audio FTU issues

Clemens Ladisch clemens at ladisch.de
Mon Jul 25 15:07:56 CEST 2011

(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 at 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_configure(stream, endpoint, rate, format);
	usb_pcm_stream_set_clock_source(stream, master_stream);


	// helpers to implement ALSA PCM callbacks
	usb_pcm_stream_pcm_trigger(stream, start);

(There are obvious similarities with firewire/amdtp.c.)

As far as I can tell, this affects mostly urb.c.


More information about the Alsa-devel mailing list