Re: [Jack-Devel] Ethernet-based audio interface using (net)jack idea

>
> I've spoken briefly with Jeri Elsworth (a well-known electrical
> engineer and general gadget wizard!), and she has made recommendations
> on what FPGA-based hardware I could tackle this project with, but I
> think before I can proceed, I need to gather some more of the high-level
> questions that I'll need to ask and research in order to get started.
>



> The basic premise, like leloo's, is to create a multiple channel audio
> ADC that transports it's data to a slave computer via JACK (over
> Ethernet) for recording. There seem to be a lot of audio interfaces out
> there that use either Firewire or USB, but often don't support
> cross-platform compatibility. I suppose my partial intent is to create
> something like the Open OpenSound Controller, where the machines can be
> built by anyone, and tailored to their needs.
>
> So, my basic knowledge of JACK so far is that it will communicate with
> an audio device that it is connected to, and transfer that data to its
> intended destination. If this were to be done in a FPGA environment,
> what would be a good approach of connecting the ADCs to JACK?



> Secondly, what do I need to know in terms of sending JACK's network
> output over Ethernet? I'm looking at a board that has a built-in
> Ethernet interface, but will I need to tell the FPGA to send the data
> in a particular format (say, TCP or UDP)?
>
> I've done a couple of weeks of research so far, but I'm sure there are
> useful resources on the Internet that I've not yet stumbled upon. If
> anyone has any particular suggestions or advice, please let me know!
> I'm starting with very little experience as a developer, so this may
> take a while, but I do hope to come up with something useful and
> functional, as well as using this project as a learning exercise.


I'm just a Jack user, not a developer at all, but I do have some FPGA
knowledge.

 It looks to me that NetJack only relies on UDP. That will keep memory
requirements in your IP stack down. But for 128 channels you need to
transmit at least 4*128*48000 = 25MB/sec (Jack uses floats - just consider
that part of the 'learning exercise' ;-) ) That's a massive amount of data
for a network stack, let alone an embedded one running on a softcore. And
you need GbE.

The hard part is going to be the synchronisation. However, you're in the
unique position to be able to vary your clock...

Therefore: why not run your system as a *slave*, doing only 8 channels or so
?

I'm wondering if you would be able to send/receive only broadcast MAC
traffic (to/from FF:...:FF) to initiate the UDP communications with the
master and then strip the orig. MAC address from the server's response to
set up the final link without ARP. You may be able to drop the software IP
stack entirely in that case, allowing you to keep your program really small.

I think you could get that going on a cheap 144-pin Cyclone III EP3C5 or
EP3C10 without any external memories, interfacing to e.g. a CS5368 and a
Fast Ethernet PHY. And a MIDI port.

The hard part (making connections, doing qjackctl) remains on the server.

Need more channels ? Connect more slaves to a (gigabit) Ethernet switch. You
cannot do that with Jack servers.

Finally, lets you keep away from Gigabit on your board as well.

Just my initial thoughts. Feel free to comment.


J.


> Thanks in advance for your help!
>
> Dan
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

1312149850.11311_0.ltw:2,a <CAPRPZsAOf6m8rvfoUuj7wBfkRWZNCizvioorLAJN1NM4JAvyWw at mail dot gmail dot com>