11 Sep
2014
11 Sep
'14
11:44 a.m.
Len Ovens:
I thought I would move this over here. I know there is
already work being
done on this hw wise. These thoughts are for a point to point raw
ethernet audio transport That still allows some normal network traffic as
well.
On Tue, 2 Sep 2014, Len Ovens wrote:
...
Why don't you prototype it with netcat:
Terminal 1:
$ nc -u -l -p 4000 localhost
hej
asdf
^C
$
Terminal 2:
$ nc -u localhost 4000
hej
asdf
^C
$
Instead of two terminals, use two computers and write a sender and
a receiver program, and start debugging.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
My thought is something like this:
We control all network traffic. Lets try for 4 words of audio. For sync
purposes, at each word boundry a short audio packet is sent of 10 channels.
This would be close to minimum enet packet size. Then there should be room
for one full size enet packet, in fact even at 100m the small sync packet
could contain more than 10 channels (I have basically said 10m would not be
supported, but if no network traffic was supported then 10m could do 3 or 4
channels with no word sync). So:
Word 1 - audio sync plus 10 tracks - one full network traffic packet
word 2 - audio sync plus 10 tracks - one full audio packet 40 tracks
split between word 1 and 2
wors 3 - audio sync plus 10 tracks - one full audio packet 40 tracks
split between word 2 and 3
word 4 - audio sync plus 10 tracks - one full audio packet 40 tracks
split between word 3 and 4
Nobody commented that this could not work :) 4 samples on a 100mbit link
is still less than one full 1500byte data packet. The reason I am thinking
about this right now, is that my studio has been flooded :P and so I
have no access to work on my control surface project right now.