[alsa-devel] M-Audio FTU issues

[Aurélien Leblond]

Hi Daniel,

All clicks gone as Felix already said :)

And confirmed, the kernel crashed with playback and capture streams
started at the same time :)

Aurélien

On Fri, Jun 24, 2011 at 5:10 PM, Daniel Mack <zonque at gmail.com> wrote:
> On Fri, Jun 24, 2011 at 5:58 PM, Clemens Ladisch <clemens at ladisch.de> wrote:
>> Daniel Mack wrote:
>>> I started to implement some logic for this, but I'm not really happy
>>> with it yet. Some reference counting would be much better than what I
>>> currently have, but I don't see a good solution yet. Maybe I've been
>>> looking at this for too long now, and someone else has an idea?
>>
>> The overall structure of the code handling the PCM streams becomes
>> different: not only must the starting/stopping of the USB capture stream
>> be decoupled from the ALSA stream, but the handling of audio formats and
>> URB buffers changes because capturing can be started before the ALSA PCM
>> capture stream is configured.
>
> Yes, I've seen this, too.
>
>> 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.  (I'm doing this for FireWire
>> streaming right now, and always wanted to do the same for USB.  Many
>> thanks for volunteering!  :-)
>
> Can you outline how the API will look like?
>
> 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.
>
> Could you outline how you would do the decoupling?
>
>
> Thanks,
> Daniel
>