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@gmail.com wrote:
On Fri, Jun 24, 2011 at 5:58 PM, Clemens Ladisch clemens@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