[PlanetCCRMA] kernel config file - building only 1394 drivers

Mark Knecht mknecht@controlnet.com
Tue Jan 7 09:37:01 2003

> -----Original Message-----
> From: planetccrma-admin@ccrma.Stanford.EDU
> [mailto:planetccrma-admin@ccrma.Stanford.EDU]On Behalf Of Steve Harris
> Sent: Tuesday, January 07, 2003 8:29 AM
> To: PlanetCCRMA
> Subject: Re: [PlanetCCRMA] kernel config file - building only 1394
> drivers
> On Tue, Jan 07, 2003 at 08:12:22 -0800, Mark Knecht wrote:
> > I've been trying to drum up a little interest for making a 1394 based
> > 'virtual audio card'. My idea is that I could have an Alsa
> driver on one PC
> > that appears to be an audio card to that PC, but all it really does is
> > transmit the digital audio over the 1394 bus to another PC with the same
> > card and driver.
> Me too, there is a low level driver in the kernel to send A+M protocol
> data over the 1394 bus, but no-ones ALSAfied it, Paul suggested that
> someone might like to do it, but there were no takers.
> It would need someone that understood alsa well, and there aren't many
> people with those skills.
> > So far, no programmers seem up for it, but I certainly like the
> idea. You
> > could then run Alsa and Jack apps on a PC with no sound card (less
> > expensive) and build a network of machines working together.
> Also an easy
> > way to get laptops into the picture.
> Yes, I planned a jack only soltuion, where one machine has a jack client
> that punts jack data across the 1394 bus and the other end has a 1394
> driver that sends the data from 1394 around the jack graph and then back
> over 1394. This way the two machines would run in sample sync, but with
> one or two buffers worth of latency. You can daisychain or, better, star
> network indefinatly this way.
> I described the design in detail on jack-dev some time ago.
> I wanted it at the time 'cos my laptop was much faster than my studio pc,
> but has crappy audio hardware :)
> I got as far as reading the docs, writing some test code and buying a
> couple of different 1394 cables, but I still only have one machine with a
> 1394 port, and its not really at the top of my TODO list anymore. It needs
> a dedicated hacker really, and my plate is a bit full as it is.
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!)

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.

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.

Lots of fun things to do!