[linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Open firewire audio interface: A back-of-an-envelope prototype plan
From: Simon Jenkins (sjenkins_AT_blueyonder.co.uk)
Date: Fri Nov 26 2004 - 06:10:37 EET


Hi all:

I've been thinking some more about a prototyping/development board (not
a production board) for a free open multi-channel firewire audio interface.
The objective would be to keep initial development time and costs down
even at the expense of pushing component costs slightly up.

Here are my very rough, version 0, not-fully-thought-out thoughts:

~ Use off-the-shelf asics for the firewire link and physical layers
~ Use a small-ish xilinx spartan 3 fpga for the rest of the "signal
path" logic
~ Use a microchip dsPIC for everything that's off the "signal path"
~ Leave A/D, DA converters (or dig audio I/O) etc entirely off the board:
Just provide headers for adding them on a sub-board later.

There's a block diagram here:

http://www.sjenkins.pwp.blueyonder.co.uk/fwboard/block01.png

Some notes:

1. The smaller spartan 3 fpgas are supported by the free, downloadable ISE
WebPACK software.

2. The PCI block in the fpga doesn't need to be that fancy or versatile.
It just
needs to handle the one TI component fast enough to get data in and out of
its FIFOs on time plus the occasional (much less time-critical) interactions
between the dsPIC and the link layer. It doesn't need to do this stuff
as fast
as possible - there's nothing else on the PCI bus to contend the bandwidth -
it just needs to do it fast enough.

3. The dsPIC never, ever touches the audio data. The converter interface
engine directly handles all transfers between the link-layer fifos and
its own
buffering. It also directly handles any other time-critical interactions
with
the link layer.

4. The dsPIC does everything else: It...
~ stores and programs the fpga configuration data
~ performs all non-time-critical interactions with the link layer and, via
the link layer, with the driver.
~ initialises the converter interface engine ready for whatever formats of
audio I/O may be about to start
~ stores user configuration data
~ handles any LEDS, switches, pots, encoders, LCDs or whatever might
go on an interface front panel.
~ does any non-time-critical control of an analog I/O subboard. (eg if
analog
monitoring were implemented the dsPIC would do the necessary switching).
~ could handle a first-cut implementation of MIDI, although this might
better be migrated to the fpga.

Comments?

Cheers

Simon


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Nov 26 2004 - 05:06:10 EET