Re: M-Audio FTU remaining mixer controls and external clocking support.

[Daniel Mack <zonque@gmail.com>]

On Sat, Aug 20, 2011 at 10:52 AM, Aurélien Leblond <blablack@gmail.com> wrote:
>>Yes, sorry for this taking longer than expected. I've been working on
>>this for a while and will continue doing so next week. I just got too
>>much things to do in parallel these days. I'll get back to you once I
>>can show patches for testing.
>
> That's a great news, I'm ready any time for testing!

So, I've been working on this more or less full-time for a couple of
days now and so it's time for an update. Also, I would like to have
some oppinions before I continue.

I thought a lot about how this can be solved and what I come up with
now is a rather intrusive patch that re-writes the entire streaming
logic of the driver.

First tests show that this approach works quite well, and I actually
also like the new implementation better than the old one. Let me try
and explain the idea.

First off, I moved a bunch of code between the files to have a clearer
picture about which logic resides where. So in particular

- stream.c does the substream setup
- pcm.c cares for everything that is related to pcm (no more
cross-linking between pcm.c and urb.c)
- urb.c was replaced by endpoint.c which holds the logic about
everything that is related to an endpoint

So this last point is actually the major news here. The idea is to
have an entity that knows about an endpoint, which can either carry
audio data or sync data. It knows about its urbs and tracks them, and
is responsible for killing them again eventually. It can have links
(function pointers) to talk to an pcm stream to either let the pcm
logic fill in audio material to urbs (playback case) or lets it parse
audio material from urbs (capture case). It also implements a
refcounting, so an endpoint that is already in use as implicit data
feedback source can be re-used as record source for pcm streams
easily. The first user will start the stream, and only the last one
will tear it down.

So this is the cleanest de-coupling I actually think of right now, but
others might disagree. Hence, I would like to hear some oppinions
about this massive patch. I have a split version of it, but the major
part too intrusive to be split up nicely (at least without added tons
of API-compat code for the transition).

I tested this with an "usual" USB device that features a sync endpoint
as well as with the FTU.

For the FTU, we seem to have another problem which is that the two
endpoints are put into two different interfaces. That causes the code
to call usb_set_interface() once the record stream is opened, and in
case the playback stream is already active, it will stop streaming due
to usb_submit_urb() returning -ENOENT. It's probably easy to fix - any
ideas?

I put the patch online here:

  https://gist.github.com/1168715


Daniel