[LAU] open hw soundcard

[Karl Hammar]

Folderol:
> On Sat, 14 Nov 2009 09:34:15 -0500
> Paul Davis <paul at linuxaudiosystems.com> wrote:
> 
> > On Sat, Nov 14, 2009 at 8:04 AM, Karl Hammar <karl at aspodata.se> 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 at aspodata.se
Lilla Aspö 148                                                 Networks
S-742 94 Östhammar          +46  173 140 57                   Computers
Sweden                     +46  70 511 97 84                 Consulting
-----------------------------------------------------------------------