Driver(s) for IEEE 1394 based break out boxes

Driver(s) for IEEE 1394 based break out boxes

[Daniel Wagner]

Hi,

There're several IEEE 1394 based break out boxes on the market for
which no drivers exist for Linux [1] (The web site has a translation
to english, but the content seems to disappear, at least for the IEEE
1394 boxes.) .  The interesting fact about those boxes is that all
but one are using the same chip (dm1000).  Furthermore, the
communication protocol(s) between break out box and computer is
documented and "public" available.  Yes, you have to be member of those
groups to read the documents but in the general idea it's available.

Relevant standards are:
  IEC 61883
  1394ta AVC
  1394ta Audio and Music Data Transmission Protocol

I'm still trying to figure out what's the best way to write a driver.

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.

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...

thanks,
daniel

[1]  http://www.soundkartenkatalog.de/deu2/pi-1117011340.htm?categoryId=28



-------------------------------------------------------
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

Re: Driver(s) for IEEE 1394 based break out boxes

[Takashi Iwai]

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

Re: Driver(s) for IEEE 1394 based break out boxes

[Jack O'Quin]

> 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.

Takashi Iwai <tiwai@suse.de> writes:
> IIRC, JACK has already a driver for IEC61883.
> Don't know whether it really works, though.

Bob Ham wrote an experimental IEC61883 driver which has been part of
JACK CVS for quite a while.  I doubt it's getting much use.

I don't know if it works either, having no hardware to test it.

> > 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.

An ALSA solution would be great, either user- or kernel-space.
-- 
  joq


-------------------------------------------------------
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

Re: Driver(s) for IEEE 1394 based break out boxes

[Daniel Wagner]

> Bob Ham wrote an experimental IEC61883 driver which has been part of
> JACK CVS for quite a while.  I doubt it's getting much use.

Great, it seems most things have already been written... ok, that might
be overexaggerated but I don't have to start at nothing :)

thanks,
daniel


-------------------------------------------------------
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

Re: Driver(s) for IEEE 1394 based break out boxes

[Daniel Wagner]

> IIRC, JACK has already a driver for IEC61883.
> Don't know whether it really works, though.

Ah good knews.  I will definitely give it a try.

> The user-space driver can be implemented on alsa-lib as a plugin.
> For example, you can find ALSA <-> JACK transparent layer.

Cool. 

> 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.

I think libiec61883 and libraw1394 are flexible enough to handle this.
From my earlier expierence with libraw1394 it should be possible.

> IMO, the implementation of the kernel driver is the last resort.

Good point.

> It might be easier as a result, but we can try at first the user-space
> implementation...

I have to get my hands on some test plattforms and I need a IEEE 1394
card at home before I can really start with it :)

BTW: If someone is really interested to help out, I can arrange that
this persons can have a test plattform for a certain period.

thanks for your enlightenments, 
daniel


-------------------------------------------------------
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

Re: Driver(s) for IEEE 1394 based break out boxes

[Steve Harris]

On Tue, Jul 13, 2004 at 11:34:24PM +0200, Daniel Wagner wrote:
> > IIRC, JACK has already a driver for IEC61883.
> > Don't know whether it really works, though.
> 
> Ah good knews.  I will definitely give it a try.

I dont think its very complete. It may predate libiec61883 though, so
maybe it can be adapted to use that.

- Steve


-------------------------------------------------------
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