Re: [LAU] open hw soundcard

Folderol:
> Giso Grimm <gg3137@email-addr-hidden> wrote:
...
> > b) own protocol, multiple OSHw, master clock:
> >
> > Master Clock
> > Host sound card
> > ||
> > jackd <===> OSHw
> > <===> OSHw
> > <===> OSHw
...
> It appears there is a software suite for the 'other' OSs that can
> manage 16 channels of 48k over the Internet (not just a LAN) provided
> you have an upstream of greater than 150Mbps and downstream better
> than 750Mbps.

Then, beginning with 8channels on a lan would be a starting point.
When that works we can add channels as see what happens.

> Also, there is a very useful looking fully self-contained Ethernet chip
> that can deliver 25Mbps at application level. This is the WIZnet W5000.
> It can also open up to 4 sockets, so I'm not clear as to whether that
> is 25Mbps per socket, or in total.

I found [1]. On a 100Mb/s net it must be "total". In a simple test a
few years ago I got 50Mb/s between two ordinary pcs.

> Very empirically speaking, with 1 channel at 24 bit depth that's a
> potential sample rate of 1MHz,

Isn't the sample rate something like 44.1, 48, or 96kHz ?
Data rate for 1ch * 24bit * 48kHz = 1.152 Mb/s (+overhead).

> or putting it another way 20 channels of
> 48k! OK, OK, I know I'm leaving out huge swathes of control, collisions
> etc. :)

So, if we have multiple 100BASE-TX trough a gigabit switch to a pc with
a 1000BASE-T, we "shouldn't" have any problems with the network
performance with < 100 channels...

Or on with a simple crossed cable only 100Base-tx network, it should be
possible to transfer 30-40 channels.

...
> Being a bit simplistic if you have a master clock (not necessarily
> the computer) send just a timecode at 48kHz everything can lock on to
> this immediately, and keep updating its copy of the timecode.

For a network solution, that would be the job of PTP (ieee1588) it seems.

> Something wanting to transmit audio would then send back it's own ID,
> the current timecode followed by up to 24bits of A/D stream.
>
> Packets would be small and latency low, buffer size could probably also
> be quite small.
>
> The computer would pick up all the incoming data streams and sort them
> into their appropriate channels and time points. At this level, the
> occasional out of sequence packet could probably be put back into it's
> right place with only a relatively small additional buffer - well I
> hope so!
...

So this would be like Giso's "own protocol" alternative b above ?

Regards,
/Karl

[1] http://www.wiznet.co.kr/en/data/WIZnet_e-brouchure_2009.pdf

-----------------------------------------------------------------------
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-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Fri Nov 13 20:15:03 2009