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

PrevNext  Index
DateSat, 06 Aug 2011 14:15:02 -0600
From Dan Swain <[hidden] at gmail dot com>
ToJeroen Van den Keybus <[hidden] at gmail dot com>
Ccjack-devel <[hidden] at lists dot jackaudio dot org>
In-Reply-ToDan Swain Re: [Jack-Devel] Ethernet-based audio interface using (net)jack idea
Follow-UpDan Swain Re: [Jack-Devel] Ethernet-based audio interface using (net)jack idea
On Sat, Aug 6, 2011 at 10:22 AM, Dan Swain <[hidden]> wrote:

> On Sat, Aug 6, 2011 at 3:17 AM, Jeroen Van den Keybus <
> [hidden]> wrote:
>
>> In my original post, I proposed slave hardware that would synchronize its
>> local clock to sync packets from a regular Jack server (digital PLL),
>> advertise a fixed amount of (floating point) and MIDI channels to the
>> server, get packet/period/... data from the server and start sending
>> receiving data over UDP continuously. The software needs to emulate a
>> fixed-configuration NetJack2 client, which can eventually be done without an
>> IP stack, since the initial communication is done using broadcasts.
>> Therefore: small software footprint ==> no EEPROM or DRAM on the board
>> ==> low pin-count FPGA ==> low cost. Since we're trying to digitize
>> precision analog signals, reduction of power (no high-current
>> switching voltage regulators) and omission of memory (no noisy digital
>> memory lines) is also a good thing for circuit design.
>>
>
>>
> ...

>
> Jeroen, are the components you listed in your first response still
> applicable for this method?
>

I've just been researching the parts that you've listed, and I'll make sure
to download and read the data sheet for the EP3C10.

As for the Ethernet, I've found two controllers that may be worth looking at
- either the Microchip ENC424J600 (10/100 Base-T), or the Marvell Yukon
Ultra II (8E8057, which is 1000 Base-T). The microchip design sounds quite
promising, as I came across its 10Base-T 'cousin' when looking at the Open
Open Sound Controller project.

I may be thinking about this incorrectly, but my approach to have the ADC
talk to JACK on the FPGA was to have some kind of ALSA 'driver' for that
chip running in the FPGA, passing the data through JACK to the Ethernet
controller. Alas, the CS5368 chip isn't supported in ALSA, but we could use
the CMI8788 chip, which is almost exactly the same.

Then again, am I thinking about this incorrectly? If we could pass the
signals directly to the JACK system (literally give the data it wants), that
would circumvent another software layer in the FPGA...
PrevNext  Index

1312661721.1266_0.ltw:2,a <CABhkv4O02fx+SKOSBYQJpTVsJgGrokYRmkq=a8z0oAVP3cNZAA at mail dot gmail dot com>