On Sat, 14 Nov 2009 09:34:15 -0500
Paul Davis wrote:
> On Sat, Nov 14, 2009 at 8:04 AM, Karl Hammar wrote:
Well it's been wet and windy all day today, so instead of going out I
did some more reading :)
With this lack of standardisation is there any point in going for OSC
with it's quite significant overhead? Netjack also seems to have quite
a high overhead, and no specific mechanism for RT syncing audio.
It seems that the UDP protocol is already the preferred protocol for a
number of streaming media apps (1) for the same reasons as I mooted
earlier. Low packet overhead, virtually any packet size, chuck it out
as fast as the transport layer can cope with.
Maximum packet size for Ethernet is 1500 bytes, but I suggest we really
don't want to get anywhere near that big if we are to keep latency
down. Off the top of my head, a 'full' frame would hold about 15mS of 1
channel 48kHz 16bit.
The downside is no congestion control, so if the network gets congested
you will lose packets rather than have them stack up in a (probably
high latency) buffer.
With just one card talking to the computer I don't think packet loss is
a significant problem.
With enough bandwidth, I would suggest a simple round-robin system
whereby every slave listens continously, but only sends when told to by
On the hardware side, that Atmel development kit (2) looks very
interesting as a proving ground as it already has both the network and
the 48kHz DAC parts built in.
For rough testing it could be used to lock a pair of ADCs. TLC4545ID
looks like a good (cheap) possibility here.
Will J Godfrey
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Linux-audio-user mailing list