Re: [LAU] open hw soundcard

On Sat, 14 Nov 2009 09:34:15 -0500 Paul Davis <paul(a)linuxaudiosystems.com> 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 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.