linuxaudio.org

Folderol:

quoted text
> Giso Grimm  wrote:

...

quoted text
> > b) own protocol, multiple OSHw, master clock:

> >

> > Master Clock

> > Host sound card

> >  ||

> > jackd <===> OSHw

> >       <===> OSHw

> >       <===> OSHw

...

quoted text
> 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

quoted text
> 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

quoted text
> 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

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

quoted text
> 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,

quoted text
> 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