My goal is not to compete with high quality manufacturer, it is to see
how far this takes us. Others might have other goals.
> This is stuff you could easily avoid if you just outsource the whole
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
> [...list of adat converters...]
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
That one is clearly out of my shopping range.
But talking about RME we have:
which is in an more affordable price range, no I don't know how good it
> The preamp makes the music. If you feed your 4000EUR Neumann M149
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
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
I don't have any problem with that feeling.
> and increases complexity.
I don't mind this one time configuration.
> With IPv6, you just put your device on the net and it gets
You could hack a similar thing into theese devices if you wish.
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
> And you have
Yes, I see no functional difference IPv4 - IPv6.
> I have a jack client streaming/receiving IPv6 multicast streams. It's so
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
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
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.
Karl Hammar Asp