Folderol: > On Sat, 14 Nov 2009 09:34:15 -0500 > Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > On Sat, Nov 14, 2009 at 8:04 AM, Karl Hammar <karl@xxxxxxxxxxx> wrote: > > > > > 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 :) Same here :) > With this lack of standardisation is there any point in going for OSC > with it's quite significant overhead? Even if OSC has a "significant" overhead, I assume you don't exercise it so much that it would matter ? > 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. I'd turn off udp checksum. > 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. If you have a controlled network, you can minimize congestion. > 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. You mean something that could be called polling? > 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. Found it, datasheet at [1], it seems to cost ~12USD. There is no "start" pin to be able to simultaneously start multiple converters. And you cannot daisychain this chip. [2] can be daisy-chained, but with a maximum of eigth channels, but it can be synced. If we are going to have multiple analog inputs at higt sample rate, isn't it better to have a parallell interface. With spi the number of channels will be limited to something like 8 for a 24bit converter. Plus that the AT32AP7000/AT91SAM9260 only has two spi-busses. Maybe ad7762 [2] could be useful (28 USD), > (1) http://www-net.cs.umass.edu/kurose/transport/UDP.html > (2) http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102 [1] http://focus.ti.com/lit/ds/symlink/tlc4545.pdf [2] http://www.analog.com/static/imported-files/data_sheets/AD7764.pdf [3] http://www.analog.com/static/imported-files/data_sheets/AD7762.pdf Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Aspö Data karl@xxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
