[PlanetCCRMA] kernel config file - building only 1394 drivers

[Mark Knecht]

> -----Original Message-----
> From: planetccrma-admin@ccrma.Stanford.EDU
> [mailto:planetccrma-admin@ccrma.Stanford.EDU]On Behalf Of Steve Harris
> Sent: Tuesday, January 07, 2003 10:12 AM
> To: PlanetCCRMA
> Subject: Re: [PlanetCCRMA] kernel config file - building only 1394
> drivers
>
>
> On Tue, Jan 07, 2003 at 09:35:44 -0800, Mark Knecht wrote:
> > So is mine. I'm not a programmer, as you know, but I actually
> did manage to
> > write and sell some software years ago. (A DX-7 patch editor.
> Actually made
> > a couple of thousand dollars, but learned I shouldn't quit my day job!)
>
> Thought about porting it to linux?

No. I actually still have a DX-7, out in the garage, but don't use it any
more. I'd have to look for the code. Turbo Pascal. (And I didn't know how to
program. It's not a requirement for making money!) ;-)
>
> > I should go look up your discussions as I do 1394 for a living,
> and you're a
> > smart guy. Could only be good for me, I think.
>
> I think I refered to it as a "jack firewire/1394 bridge", good luck
> finding it, I had a look in my sent foolder but I couldn't find a relevant
> mail to get you a message-id or something to help find it.
>
> The original mail wasn't very enlightening IIRC, pretty much what I just
> said + an ascii diagram.
>
> > One technical issue that would be 'interesting' top solve would be that
> > Isochronous Cycles on a 1394 bus guarantees timely delivery, unlike
> > Ethernet, but the bus runs at 8KHz. (125uS clicks) This would
> fit well with
> > no buffering on 48K samples, but would not be an exact transfer
> with 44.1K.
> > Possibly that's not a problem as you could always transfer
> 44100 samples,
> > and then just throw away the other 3900. (48000-44100) Or
> possibly use those
> > cycles to transfer MIDI info, or other control structures.
>
> MIDI gets sent on seperate subchannels, but 1394 packets are really small
> IIRC, 32 bytes or something, so padding isn't much of an overhead.
>
Actually not true, or slightly true depending on what you are sending.

Asynchronous packets - there are packets that send a single DWORD (32-bits)
and then there are packets that send blocks of data. For an S-400 solution,
which you and I would enforce, the packet size is 2048 bytes. There is no
guaranteed deliver time with this sort of packet. There is no allocation of
this bandwidth. Any device is allowed to send these packets according to the
rules of 1394.

Isochronous packets - depending on how you send them, these may be up to
4098 bytes. 4K bytes/packet times 8K packets per second yields 32MB/second
during ISO time, or and approximately 250Mb/S bit stream. The rest of the
bandwidth is used up by some Async traffic and bus overhead for arbitration
and what not. This bandwidth is allocated to the transmitting device, but
it's possible to build a software protocol that allocates bandwidth for a
group of devices.

So, there is plenty of bandwidth.

The 1394 developers already have a library of interface calls for sending
Async and Iso data, so it's really just a matter of writing a program. From
my perspective, this 'entity' that I envision might not even have to know
about Alsa is you just made it a jack client. Start the thing, it announces
itself to jack, gets hooked up and sends data.

Seems simple to me, but what do I know?!?!? ;-)