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

On Tue, Aug 2, 2011 at 11:51 AM, David Nielson <[hidden]>wrote:

> 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
>
>
Thanks David and Adrian for your thoughts and input - this is turning out to
be a very interesting thread...I apologise for lagging behind in my
response!

I think there are a few more companies looking at this kind of technology
now, and as mentioned in my initial post, Focusrite are using such
technology based on reference designs from Audinate:
http://www.focusrite.com/rednet/

Of course, their approach is quite extensive in terms of remote control of
devices beyond adjustment of gain, but I agree with the notion that this
(our idea here) could become an open-source project. ARM is certainly an
option, and a couple of years ago I was made aware of the Beagle Board
systems, which are pretty flexible.

I'm not sure if that's my intent though - it might be better to take the
approach of something that is quite robust, with a minimal amount of
software. Then again, if there are no reliability comparisons to be made
between the two approaches, I'd certainly go with the slightly easier option
of running a tiny Linux distribution from say a CF card or ROM chip which
basically executes the netJACK system as a command line with all of the
configuration pre-set, kind of like a firmware. I think there would be more
of a personal gain working on a more hardware-orientated system, as I would
be forced to learn a number of elements that may be useful to a career in
the future :-)

On the network side, using a switch to route the network traffic to the
computer sounds like a very good method of combining multiple units. The
company I work for at the moment make use of TrendNet switches, and from
their 8-port PoE units to their 48-port 1Gbps in both directions units, they
seem to make some very reliable hardware, and certainly these and other
reliable brands could be used as the 'backbone' of a good audio network.

I've found a couple of ADC and DAC circuits through my searches on the
internet, so replicating those would certainly make this an open-source
project! However, the analogue side of this scenario is always the easy
side, at least for me. In order for a system like this to work, and based
from what I've read about the JACK system so far, would I need to 'spoof'
some kind of audio interface that JACK would connect to?

Another 'guess' of mine is that if we're going to approach this hardware as
a slave device to the main computer, are we going to need some kind of
bi-directional connection when it comes to the synchronisation? Or, is it
feasible for the whole system, given that low latency is a requirement (or
at least a desirable element) that we could have the machine send out the
'master clock' signals, and assume that they reach the end unit as intended?

I'm still leaning towards the development board that Jeri Elsworth
recommended, as I've not been able to find a similar board that uses the
FPGA that Jeroen noted. However, please keep the comments and suggestions
coming, as I'll do some more research based upon your recommendations, and
try to bring together a system that is compatible with itself :-)

Once again, thanks for your thoughts and comments, and I hope to make some
more headway this weekend.

Kind Regards,

Dan

1312516666.16512_0.ltw:2,a <CABhkv4PCwu=L+VPTZEbGQaA7HcSn-yvtq7cZWc9h3_3hBEgOAg at mail dot gmail dot com>