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

[Bob Knight]

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
bk at minusw.com
925-449-9163