Re: [LAD] FOSS Ethernet Soundcard

Adrian Knoth:
> On Tue, Nov 24, 2009 at 09:48:53AM +0100, Karl Hammar wrote:
> > So ich habe mal was zusammengedichtet ....
> > > > 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.
> > 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.

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
> 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.
>
> 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.

> 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]
> > 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.

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@email-addr-hidden
Lilla Aspö 148 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
-----------------------------------------------------------------------

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Nov 24 20:15:02 2009