From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Aur=E9lien_Leblond?= Subject: Re: M-Audio FTU issues Date: Tue, 28 Jun 2011 21:37:58 +0100 Message-ID: References: <4E045058.6000405@showlabor.de> <4E04B42E.2080906@ladisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-vx0-f179.google.com (mail-vx0-f179.google.com [209.85.220.179]) by alsa0.perex.cz (Postfix) with ESMTP id CFC862446D for ; Tue, 28 Jun 2011 22:38:00 +0200 (CEST) Received: by vxb40 with SMTP id 40so490343vxb.38 for ; Tue, 28 Jun 2011 13:37:58 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Daniel Mack Cc: Takashi Iwai , alsa-devel@alsa-project.org, Grant Diffey , Clemens Ladisch , Felix Homann List-Id: alsa-devel@alsa-project.org 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=E9lien On Fri, Jun 24, 2011 at 5:10 PM, Daniel Mack wrote: > On Fri, Jun 24, 2011 at 5:58 PM, Clemens Ladisch wro= te: >> 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. =A0(I'm doing this for FireWire >> streaming right now, and always wanted to do the same for USB. =A0Many >> thanks for volunteering! =A0:-) > > 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 >