I want an open ethernet audio device. I do not want or need to deal with pci, firewire, usb.
Use one of many controllers out there with a good embedded linux port and build in ethernet. Use a TDM or GPIO type interface for the analog side of the world.
TDMoE would work just fine for audio. One thing that linux does well these days is ethernet.
I need a minimum of 32 channels for live recording. The idea would be to just suck in the ethernet frames and write them to disk. Then mix them down back in the studio after the show.
I am a noop (programmer) with a EE back ground and would glad to help anyone build something like this.
Simon Jenkins wrote:
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
-- Bob Knight [-w] the work option [EMAIL PROTECTED] 925-449-9163
