linuxaudio.org

On Sat, 14 Nov 2009 09:34:15 -0500

Paul Davis  wrote:
> On Sat, Nov 14, 2009 at 8:04 AM, Karl Hammar  wrote:

quoted text
>

> > So what is the consensus among the applications, is it e.g. "/mixer/1/

> > volume", "/mixer/a/vol", or what?

>

> To the best of my knowledge, there is no consensus about the format of

> any significant messages sent via OSC. There is no standard way to

> generate specific behaviour in an unknown OSC receiver, whether it is

> volume control, note generation, or anything else. All the uses of OSC

> that I am aware of involve a set of messages specified by the sender

> (in the case of, say, the Lemur or Monome control surfaces, or the

> Mrmr iPhone app) or by the receiver (in the case of, say, Ardour or

> Reaktor).

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

the master.
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.
(1)

http://www-net.cs.umass.edu/kurose/transport/UDP.html

(2)

http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102
--

Will J Godfrey

http://www.musically.me.uk

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

Linux-audio-user@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user