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

PrevNext  Index
DateTue, 02 Aug 2011 11:51:54 -0600
From David Nielson <[hidden] at comcast dot net>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToAdrian Knoth 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
I've had a similar idea for a while, but slightly different: I have 
wanted to use a newer ARM chip (like what's in a modern smart phone) as 
the central design piece of the box.

It could run Linux (and therefore netjack) directly, so it wouldn't 
require a bunch of FPGA design.

If there's enough CPU left over, or a second core, perhaps it could even 
do some processing via LV2 or LADSPA within the box... maybe it has 8 
inputs and 8 outputs, and it acts as a network-programmed effects box 
with network sends for recording.

If the design is flexible enough, maybe there's an 8-channel power 
amplifier that gets its signal over the network, and it handles its own 
digital crossover, with EQ, delay, whatever there's CPU power for.

A number of people who are knowledgeable in this field have pooh-poohed 
this idea, so I've put it out of my mind for the most part . . . But if 
there were, say, a 4-in, 4-out model for $299, or 8x8 for $499, or 16x16 
for $799, and a 4-channel high-power amplifier that could run off either 
a 12-volt car system or a standard 120 or 240 AC setup, I'd buy lots and 
lots of them.

So why don't we design this thing using free and open-source tools, 
publish the design under an open hardware license, and sell finished, 
polished products, which people could also build on their own if they 
really wanted to?

David Nielson

On 08/02/2011 07:06 AM, Adrian Knoth wrote:
> On 08/02/11 05:48, Dan Swain wrote:
>
>>>   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
> Given that you're most likely writing your own RX/TX code, you can
> forget about floats and stick to your ADC/DACs data format, which
> probably means 24bit integer, maybe 16.
>
> You then do float<->int conversion in your RX/TX software module. OTOH,
> any modern FPGA shouldn't be too stressed by floats, so you could
> offload this work to your hardware.
>
>>> 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*
> I second this. Especially since the ADC should always be the driving
> clock. I assume the DAC shares the clock signal on the PCB.
>
> Of course, adding multiple of those boards to the same network without
> synchronization on the audio side could be cumbersome and sooner or
> later would lead to AVC, but let's keep things simple and assume a
> single unit or external (digital) syncing for now. (unless you're aiming
> for the one-fits-all solution)
>
>> I did also wonder about Leeloo's approach in terms of having the hardware
>> device being the master, rather than the computer.
> Go for it, it saves you a lot of trouble.
>
>> In one way I can understand it in that the hardware clock may be more
>> reliable, but with a Linux machine that has a programmable kernel
>> timer, so the flexibility there would definitely supersede that.
> See, time is just an idea, it only exists in the real world, the whole
> digital side has no notion of time whatsoever. It only counts state
> changes. And your only relation to the real world is at the ADC/DAC
> ports.
>
> That said, you clock inside the audio box, send it to the PC, let it
> process it and feed the result back to the audio box. No woe about
> resampling.
>
>> So, in your slave scenario, would you have the device instantly begin to
>> send UDP data once it starts?
> This should do the trick, yes. And if you add timestamps (in a sense of
> presentation time, IOW, when the audio signal hit (left) the ADC or will
> hit the DAC), you can reuse this timestamp in your RX/TX backend, add
> your jackd buffer size and send it back to the audio box for the
> outgoing stream. (mind the hw-rx buffers in your device)
>
>
> Cheers
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
PrevNext  Index

1312307577.25160_0.ltw:2,a <4E38393A.5060709 at comcast dot net>