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

Dan,

2011/8/14 Dan Swain <[hidden]>

> Apologies for not getting back to this thread for a week. While I've been
> 'away', I've been thinking about how to tackle having the digital audio from
> the AD Jeroen mentioned make its way into JACK. Looking at the diagram (
> http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack2) it looks like a
> backend would have to be created that talks to both the FPGA and the CS5368.
>
>
Don't forget that the 'backend' you want to create is probably a hardware
interface (= VHDL file) to the ADC. You will probably be clocking the ADC
from the FPGA as a master on its MCLK pin and read your TDM frames using
SCLK and LRCK/FS. The tricky bit is going to be the generation of this MCLK
clock signal; it will need to become synchronized with the sync packets the
system will receive from the master Jack server. When that happens, the ADC
values from the ADC can be directly fed into Jack packets (after floating
point conversion and a FIFO to cope with jitter and Ethernet packetization).

It think this may eventually end up by you generating a square wave
synchronous to the Jack server sync packets, and feeding that signal back
(externally - FPGA PLL inputs are always dedicated inputs) into one of the
FPGA PLLs to generate MCLK. Beware that the square wave will really need to
be 'good' in a sense that simply clocking the FPGA PLL with sync pulses will
not do (too low a frequency - too much jitter). Therefore you will need a
digital PLL (= VHDL file) first. Beware that clock generation in this
fashion isn't common at all (let alone recommended), but since it would save
so much trouble processing the data, I think it's worth trying...

If this low-level clock synchronization is not possible, be prepared for
some tedious signal interpolation (as is actually done in 'audioadapter').

The next logical place for you to look is the netjack source code, in order
to understand the mechanism of synchronization and to find out how the Jack
server expects the data to be laid out in the Ethernet packets (i.e. have
the FPGA *emulate*, rather than *run*, NetJack).

The hardware design for this project is not entry-level, to say the least. I
suggest you contact Uwe Beis for assistance in this project. He apparently
has also useful experience with the analog front end.

As for PHYs, avoid anything with QFN or BGA package for a DIY project. Also,
again, stay away from GbE, or face getting GMII timings right to 1ns.


> For now, I'd like to think that the PCM data coming from the AD can be
> directly connected to JACK's audio 'inputs'...channel 1 going to audio input
> 1, 2 to 2 and so on, and then JACK broadcasts that data to the network. In
> that case, all we'd need to do on the FPGA is route the right audio channels
> to the relevant JACK inputs running on that chip.
>
> Would that be a fair assumption?
>
>
Yes, but I sincerely doubt you'll ever get 'jackd -dnet' running properly on
a Nios II embedded Linux. My idea is therefore to have the FPGA (or the
softcore CPU on it) directly generate Ethernet packets conforming to a
predefined NetJack layout.



> This project may be a bit slow to get started, but I do intend on keeping
> it going!
>
> As always, thanks for all of your help!
>
> Dan
>
>

1313442214.15673_0.ltw:2,a <CAPRPZsDSdj5y8nNvc7qYctjmd0EPTTHbVeYB4cK_9aZwz+ZD3g at mail dot gmail dot com>