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

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.
>

>
However, in the meantime we have evolved to implementing the Jack software
> on an embedded CPU. Is this really feasible ? Embedded hardware is usually
> seriously less powerful than a general-purpose desktop CPU. Jack is also a
> fairly large piece of software, relying heavily on all sorts of libraries.
>
>
These are most of the reasons why I'm reluctant to take that route - and
also an Embedded system has that word of 'emulation' associated with it. The
specifications that you've given in your first paragraph here seem to
coincide with the idea that I've started with. We could certainly look into
using an embedded board, but I think for me, a hardened FPGA solution would
make the most sense in the real world. Out of my (realitively few)
experiences of software and hardware working together in the music world,
software has always been the bottleneck, or the point of most failure.

I think I need to draw out your proposal as a flow chart, Jeroen, to see it
graphically, but it sounds like a very robust and performant angle to take.
Again from my post yesterday, we could use this as the core system for a
number of end-user interface configurations, changing the program on the
FPGA to suit each specific situation. I think if we aimed for the most
demanding configuration, then 'working down' from there.

I was watching a couple of FPGA tutorial videos on YouTube last night, and
after while it all started to make sense. I'm fairly good with logic, and
apparently I know more about programming than I thought!

When I was looking for ADC circuits and preamps, I tried to stick towards
the direction of 'prosumer' or 'professional' solutions, when it came to
specifications. For example, I'm not sure that using a C-Media chip on the
board as an ALSA device would be the ideal situation (even though routing 8
channels of audio through a processor like that wouldn't be difficult), so
I'll have a look around at what (ALSA compatible) hardware is available.
Then again, if I'm to use good ADCs with a good signal to noise ratio, or
(optical) isolation, then the CMI chip is just there to route the signals to
the FPGA as an audio interface to the JACK server.

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

1312647804.7185_0.ltw:2,a <CABhkv4O560hTDJk-Jnnb5BepqdJUf4Jer_4bFAxzCCoqH2D8dg at mail dot gmail dot com>