On Mon, Nov 09, 2009 at 01:42:00AM +0100, Karl Hammar wrote:
Folderol:
On Sun, 8 Nov 2009 16:53:31 +0100 (CET)
karl(a)aspodata.se (Karl Hammar) wrote:
...
> Would a network connection solve that
problem?
> In that case the DACs and ADCs could reside on an embedded computer
> and stream the sound data to/from the pc. And one could envision
> such little things near each mic and ethernet cables or possible wifi
> to the control room.
...
Ethernet looks interesting, and I know there is
stuff out there, but
have no idea what latency and timing issues there may be. I would
imagine syncing multiple 'drops' to a stable clock might be problematic.
Lets say we have pc <> switch <> lots of network boards for a single mic
PC could broadcast the clock to all micboards and the would hopefully
arrive without noticeable skew or jitter. And the micboards could
answer with that timestamp and the converted value. In this case
the PC requests each sample one at a time from all micboards.
Would that be good scheme?
A simple ping here, has a rund trip time of 0.25 to 0.8 ms depending
on end equipment.
That's a fascinating idea.
Instead of messing with USB2 protocols, design a board that attaches a ADC/DAC to a
microcontroller and shoves the raw floats in and out over... Gigabit Ethernet??!
I don't know if any of the cheap microcontrollers out there-- or the free network
stacks available for them-- could also handle the speed of a large amount of audio.
But the thought of a hardware audio interface that talks NetJACK natively, however, is
really intriguing. Use OSC to control the interface....
Hmm. It'd be more than just a native Linux-supported audio interface, it'd be a
JACK-specific audio interface.
The devil's in the details, though. Which DAC/ADC chip? Which microcontroller? How
much RAM? Which network stack? Which preamp circuitry? How many channels? Etc, etc.
It's not a trivial project.
-ken