15 Nov
2009
15 Nov
'09
1:50 p.m.
On Sat, 14 Nov 2009 23:41:35 +0100 (CET)
karl(a)aspodata.se (Karl Hammar) wrote:
I was trying to avoid that word :)
There is a chip select feature, and also a count overrun, both of which
put the output into high Z state. Therefore the outputs can be
paralleled, and count pulses sent to the appropriate chips by the
processor. It also has an interesting feature of having it's own high
speed conversion clock, so presumably, once a conversion has been
done you can read the result at your leisure - not sure how this would
actually work. I hadn't read far enough to find out if/how this could
be synced.
--
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.
Folderol:
Exactly!
On Sat, 14 Nov 2009 09:34:15 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
Same here :)
On Sat, Nov 14, 2009 at 8:04 AM, Karl Hammar
<karl(a)aspodata.se> wrote:
Well it's been wet and windy all day today, so instead of going out I
did some more reading :) 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). 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),
Not sure how you'd effectively squeeze in multiple channels of 24 bits
parallel without quite a lot of juggling. Also don't know how fast the
spi interface can run. Ultimately we'd be limited by the speed the
ethernet chip can work.
(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(a)aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
-----------------------------------------------------------------------