24 Nov
2009
24 Nov
'09
11:46 a.m.
Adrian Knoth:
Come on, we're talking about a new development here. New development
should never ever focus on IPv4, IPv6 has been there since 1998.
Manually assigning an IPv4 address feels so 1990s
I don't have any problem with that feeling.
On Tue, Nov 24, 2009 at 09:48:53AM +0100, Karl Hammar
wrote:
My goal is not to compete with high quality manufacturer, it is to see
how far this takes us. Others might have other goals.
So ich habe mal was zusammengedichtet ....
You don't say why we
should avoid analog stuff.
Like always: Analog parts are hard to build. You need to calibrate your
circuits, you have tolerances in almost every component, you need a lot
of knowledge to manufacture a high-quality ADC/DAC. The
rationale in brief:
No proprietry hardware soundcard needed.
Almost all modern computers have reasonably fast Ethernet connections.
Don't
know how much you already did for the hardware layout. If
possible, try to avoid analog stuff, that is, ADC/DAC. This is stuff you could easily avoid if you just
outsource the whole
ADC/DAC to a company which has the skills to do this. Luckily, there's
ADAT: eight channels of audio over a single, optical link. So all you
would need is one or more ADAT jacks somehow attached to your computer.
Even better: studios usually have ADAT-ADC/DAC around, they're only
looking for a way to get the data from/to the computer. If you want to
win the whole pro-audio scene for this project, just provide ADAT plugs.
I don't have any adat equipment, so I cannot test it, but if anyone
else is willing I might give it a try. Do you have any specific chips
in mind?
[...list of adat converters...]
Don't get me wrong, but I guess you cannot match their level of quality.
And I don't see why one should fiddle around with soldering some crappy
analog ports when he has decent studio gear around or can buy
good-enough quality like the Behringer ADA8000.
Well, you have to start somewhere. I'm not in this to compete with
Behringer ADA8000, I'm in this to fiddle around with soldering.
And while we are at it: RME and Apogee often also
don't even dare to
provide a preamp, because the studio guys have better stuff around:
http://www.thomann.de/gb/avalon_ad2022_preamp.htm
That one is clearly out of my shopping range.
But talking about RME we have:
http://www.thomann.de/gb/rme_quadmic.htm
which is in an more affordable price range, no I don't know how good it
is.
The preamp makes the music. If you feed your 4000EUR
Neumann M149
microphone into an Avalon, all you need is a decent A/D conversion and
you're halfway done with your radio production. ;)
Then this project might not be for thoose people. Let's face there are
"always" someone else that is better than me/you at this or that thing.
I will be perfectly happy if this project stops at some noisy 64channel
16bit 44.1 kHz thing with working protocols, because then someone else
migth take it further.
Sometimes, these preamps come with builtin A/D
converters. That's what I
use:
http://www.thomann.de/gb/focusrite_liquid_4_pre.htm
See it? It reads "ADAT I/O". If the FOSS soundcard provides an
IP-to-ADAT converter with zero latency mixing facilities and builtin DSP
effects, you'd be the man! You could instantly sell numbers of units, it
would be the perfect onstage mix/split/monitoring solution.
If someone lends me/us gear to test on and a spec to work from, links
to chips to use, preferrable some chips also, does some testing and
encouraging, I might be able to help. Otherwise it is simply out of budget.
One question tough. If you have ADAT, why go the longer way over an
ADAT-to-ethernet box than straight into your adat card in your computer?
What would one gain?
I'm also somewhat interested in the network part,
I feel IPv6 could help
a lot. It supports autoconfiguration and it has decent multicast
support, so it would be possible to broadcast/multicast the streams on
the net (LAN). This could be useful if you want to access the stream at
a mixing console for a life setup and simultaneously record it on a
computer.
At a live recording you probably have only your own gear connected to
the lan. In that case you can easily assign ip-adresses at will and to
your own taste. I don't see how IPv6 vs. IPv4 could matter at all. and increases complexity.
I don't mind this one time configuration.
With IPv6, you just put your device on the net and it
gets
a link-local address, that is, fe80:MAC-Address. (it's not exactly the
MAC-Address, but it's derived from it).
You could hack a similar thing into theese devices if you wish.
uint48_t ethernet_addr;
uint32_t ip_addr = 192 << 24 | 168 << 16 | ethernet_addr & 0xffff;
No need to assign anything, you're instantly ready
to go.
You do need to know which box is which, if it is only the local
workstation and the I/O box - ok, but if you have more than two
devices you need to know which one you are talking to. So, if you
take ten devices right out the boxes and puts them on the net,
you have to do "something" to know which cable goes where.
Some proposals to do this could be:
. do something on "master" and a led lights up on the slave
. read off some code or serial number on the device and match it to one
in your list
. do something to the slave (like talking into a connected mic) and see
response on master
. assign name/address in a 1990'th style
Well, we could provide for all thoose possibilities, since we all have
different preferences.
And you have
link-local multicast (read: broadcast in IPv4 terminology). Just use an
address starting with ff02 and send your streams to it. Everyone
subscribed to this address would receive it.
Yes, I see no functional difference IPv4 - IPv6.
I have a jack client streaming/receiving IPv6
multicast streams. It's so
easy. No configuration at all, I just fire up the application and I'm
ready to stream. I don't even care about the other addresses used on
this LAN.
Let's talk about discovery: how do you intend to find your devices on
the net? With IPv6 multicast, all soundcards could statically listen on
ff02::dead:beef. Then, the workstation sends its discovery packet to
ff02::dead:beef, all cards receive it and respond (connect back) to the
source IP (or an IP given in the packet, but that's not even necessary)
I personally don't need to find my devices, I already know about them.
In other words: A single address is sufficient to
trigger the callbacks.
One could make the devices respond to a broadcast ping wich gives you
the same functionality in IPv4.
The cards tell the workstation about their very own
IPv6 multicast
streaming address, and the workstation simply has to tune in. There you
go. Streaming and discovery within approx. 200 lines of code.
Don't get me wrong, I'd be happy to make it work with IPv6, and we can
make it ipv6 only, I would not mind.
Maybe someone like you could do the ipv6 testing.
Perhaps it's even a good idea to provide a master
clock on an IPv6
multicast address, but clocks are a separate issue (in a studio, the
workstation would probably slave to some decent specialised clock, e.g.,
Apogee Big Ben)
That is another question we are not yet prepared to tackle.
[RockNet, Roland Digital Snake, Ethersound]
Yes, but the devil is in the details as always. Having a working
example is as usual an working example. And we are missing an open
protocol for this.
Regards,
/Karl
-----------------------------------------------------------------------
Karl Hammar Aspö Data karl(a)aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
-----------------------------------------------------------------------
That tells us that it should be doable. But of
cause we want an open
protocol. Do you know the capacity limits of those systems?
Approximately what you could expect from a 100MBit/s link. At least 32
channels, rocknet even more, but they use 400MBit/s.