Re: [LAU] open hw soundcard

From: Folderol <folderol@email-addr-hidden>
Date: Sun Nov 15 2009 - 19:50:46 EET

On Sat, 14 Nov 2009 23:41:35 +0100 (CET)
karl@aspodata.se (Karl Hammar) wrote:

> Folderol:
> > On Sat, 14 Nov 2009 09:34:15 -0500
> > Paul Davis <paul@linuxaudiosystems.com> wrote:
> >
> > > On Sat, Nov 14, 2009 at 8:04 AM, Karl Hammar <karl@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.

Exactly!

> > 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?

I was trying to avoid that word :)

> > 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.

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.

> 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@aspodata.se
> Lilla Aspö 148 Networks
> S-742 94 Östhammar +46 173 140 57 Computers
> Sweden +46 70 511 97 84 Consulting
> -----------------------------------------------------------------------
>
>

-- 
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
Received on Sun Nov 15 20:15:02 2009

This archive was generated by hypermail 2.1.8 : Sun Nov 15 2009 - 20:15:02 EET