From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Driver(s) for IEEE 1394 based break out boxes Date: Tue, 13 Jul 2004 18:41:38 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20040712191930.GA20382@vis.ethz.ch> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by alsa.alsa-project.org (ALSA's E-mail Delivery System) with ESMTP id 8592122A for ; Tue, 13 Jul 2004 19:00:57 +0200 (MEST) In-Reply-To: <20040712191930.GA20382@vis.ethz.ch> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Daniel Wagner Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Mon, 12 Jul 2004 21:19:30 +0200, Daniel Wagner wrote: > > On the on hand, there exists already the IEEE 1394 stack with IEC > 61883 support in user-land. I don't know if the libiec61883 is already > ready to use but still it exists. As I understand the general idea > behind libraw1394 and libiec61883 is to do as much as possible in > users-pace. Any application which wants to take advantage of IEEE 1394 > based sound cards has to use those libraries. I guess it means for > jack to have a new backend in order to use those cards. But most > application wont be aware of this interface, I suppose. IIRC, JACK has already a driver for IEC61883. Don't know whether it really works, though. > On the other hand ALSA provides a well known interface which most > sound based application are using. To write a new driver for a sound > card, you end up writing an ALSA kernel driver because libasound is > not designed to use other interfaces than the ALSA kernel interface > (this is an assumption). So it is not possible to use libraw1394 and > libiec61883. A new kernel driver has to be written with implements > those parts. Of course it needs some more things but I'm just writing > my lousy ordered thoughts down. > > The question is which way to go? Get the break out boxes working with > the existing libraries or write an ALSA driver which implements those > parts again? Personaly, I think ALSA might be the better idea but it > does not make use of the already written code. Maybe there exists a > better way... The user-space driver can be implemented on alsa-lib as a plugin. For example, you can find ALSA <-> JACK transparent layer. I once thought of that for usb driver, but it wasn't possible because usbfs can't work with isochronous transfer. If libiec61883 provides for stream reading/writing, it wouldn't be too hard to implement. IMO, the implementation of the kernel driver is the last resort. It might be easier as a result, but we can try at first the user-space implementation... Takashi ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com