[alsa-devel] [PATCH 0/5] RFC for snd-usb: rework usb endpoint logic

Aurélien Leblond blablack at gmail.com
Tue Nov 1 09:50:39 CET 2011

Hi Daniel,


I have a question though, related to how you guys in Alsa work and
what processes you follow.

Are you looking for testers already?

Or more for some kind of approval first from some other Alsa gurus to
get the code accepted?


On Mon, Oct 31, 2011 at 12:38 PM, Daniel Mack <zonque at gmail.com> wrote:
> On 10/31/2011 01:10 PM, Daniel Mack wrote:
>> I didn't sign-off the patches on purpose, as I would really like to
>> get them reviewed before they go in. Can people have a look and state
>> whether the whole idea is at all sane?
> To briefly state the idea as such: the new implementation defines a model
> (snd_usb_endpoint) that handles everything that is related to an USB
> endpoint and its streaming. There are functions to activate and deactivate
> an endpoint (which call usb_set_interface()), and to start and stop its
> URBs. It also has function pointers to be called when data was received or
> is about to be sent, and pointer to a sync slave (another snd_usb_endpoint)
> that is informed when data has been received. A snd_usb_endpoint knows about
> its state and implements a refcounting, so only the first user will actually
> start the URBs and only the last one to stop it will tear them down again.
> With this sort of abstraction, the actual streaming is decoupled from the
> pcm handling, which makes the "implicit feedback" mechanisms easy to
> implement. All the code that actually handles the payload of a stream's
> packets is now implemented in pcm.c, which is were it belongs to.
> But I'm sure there are some unresolved corner cases which need attention.
> Daniel

More information about the Alsa-devel mailing list