On Wed, Nov 11, 2009 at 10:32:40PM +0100, Karl Hammar wrote: OSC info, including specs, is here: http://opensoundcontrol.org/ I suggested it for control/status data, i.e. to configure the sound card, choose sample rates and channel configurations, etc. It's used by some Linux softsynths to communicate with their GUIs. I would not suggest OSC for shuffling ADC data back and forth. For that, either NetJack or some lightweight homegrown int/longint-based protocol would be better. I am very excited to see so much progress on this. That ATMEL dev board also seems like a fast way to get something up and running. -ken

[ about OSC ] Oh, I wasn't specific enough. It ([1,2]) only defines the "on the wire" format. For it to be useful the "OSC Address Patterns" mapping to real controls must be defined. So what is the consensus among the applications, is it e.g. "/mixer/1/ volume", "/mixer/a/vol", or what? Yes, since it is supported by the applications, it seems to be something we must have. And it should not take much to make it work. No, I didn't think so either. Yes it is, but the processor on the cheap (~80USD) AT32NGW100 [3] is AT32AP7000 [4], which has a BGA [5] package only, which puts it out of the home hw hacker domain (special equipment is required to solder it). Regards, /Karl [1] http://opensoundcontrol.org/spec-1_0 [2] http://cnmat.berkeley.edu/system/files/attachments/Nime09OSCfinal.pdf [3] http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102 [4] http://www.atmel.com/dyn/products/product_card.asp?part_id=3903 [5] http://en.wikipedia.org/wiki/Ball_grid_array ----------------------------------------------------------------------- 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 -----------------------------------------------------------------------

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.

On Sat, 14 Nov 2009 23:16:16 +0100 fons(a)kokkinizita.net wrote: I'm quite aware of that. I don't know what makes you think I was trying to make a direct comparison. In fact, I think I actually compared UDP to TCP in an earlier post. Well, maybe I'm wrong, but looking through the info I could find I got the impression there was a lot of identification stuff going on before you got anywhere near actual data. -- 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.

On Sat, Nov 14, 2009 at 10:31:00PM +0000, Folderol wrote: Anywhere where packets of different types have to be transmitted over the same channel you need to add some data to identify the packet type. It can be a simple as a single byte or int. OSC does two things: 1. It encodes packet type in textual strings, which can be structured in the same way as pathnames in file system are. 2. It defines a way to describe and encode the data that follows, so you are not limited to a set of predefined formats. Both are done in a way that make the conversion from/to a textual representation very simple, which is some cases is a desirable feature. Neither of these is essential in the application we are discussing, it could as well use a fixed set of binary formats. If the limits of doing that are acceptable then you don't need OSC or anything similar. If you don't want such limitations then OSC is a good choice. That's all. And anyway, until the fundamental hardware design issues are solved, all this is in fact quite irrelevant. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Sun, Nov 15, 2009 at 10:03:24AM +0100, Karl Hammar wrote: This 'telnet style' has existed for almost as long unix has, and clearly there was a need for something more efficient in some types of application. A typical use for OSC is as an the interface between a composition language and a real-time sysnthesis engine. For example SuperCollider works this way. If you send 1000 messages per second to 25 granular synthesis channels each (i.e. 25k messages/s) then the printf(),scanf() overhead is not trivial at all. And you certainly don't want to read all of them. In many cases (if only a limited set of commands is required, no wildcards, no timed commands) OSC encoding/decoding can be done almost 'zero-copy' and using just a few lines of very simple code. The biggest error you can make in such cases, if efficienty is an issue, is to use a general purpose 'full' implementation such as e.g. liblo. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Sun, Nov 15, 2009 at 6:38 AM, Karl Hammar <karl(a)aspodata.se> wrote: OSC is not a new thing - its been around for more than a decade. It is widely known that its text-based format represents significant, measurable overhead when the message rate is high, primarily calls to strcmp (or any equivalent function that you want to write - one way or another, you have to do byte-by-byte comparisons to identify the message and its destination). OSC is a remarkably flexible protocol that has many potential uses, but as fons noted if you increase the message rate to the level that would be needed for some kinds of less conventional control, and the text based format is demonstrably a *proven performance issue*. does that mean that OSC is useless? far from it. this is much less of an issue than the lack of any clear semantics. but its still an issue to be aware of depending on the use case. actually, the "lo" in liblo stands for "lightweight OSC", and is very specifically NOT a full implementation of the protocol. steve chose to implement just the parts that seemed actually useful. i have not come across anything that liblo can't handle, but its a mistake to think that its the whole thing. it is, though, as fons notes, more expensive than a custom designed codebase that delivers primarily preformatted messages to a socket. i strongly suggest that you spend time defining precisely what you want the control protocol to be able to do before you start this kind of experiment.

Folderol wrote: I like to to see it the other way around: Information about the data (format, timing) needs to be sent with the audio stream to enable all listeners to decode it. This way, the audio stream can be sent multicast. In addition, it will be useful to be able to parametrise the sound card in a way like you describe. Some ideas about using OSC: - yes, there is an overhead in using OSC. But the protocol is very simple, and the text based routing protocol can be used in a very efficient matter if it is coded efficiently (e.g. using short address patterns). - it could be very useful to have a bridge OSC<->jack - OSC is transport agnostic. Usually it is implemented on top of UDP, but it is equaly valid to make it sit on top of TCP. It is thus possible to use UDP for "best effort" scenarios, where latency must be minimized but packets may get lost, and alternatively TCP for situations where packet loss is not acceptable, such as for recording. To implement OSC transport for audio, there should be an agreement about some formatting, especially the OSC address patterns used and what data shall be sent in addition to audio. In a very naive approach, it would then suffice to send the data stream and decode it on the other side. The timing / synchroinisation is a different matter, but can be solved if the system clocks are synchronised. If UDP is used, there should be a mechanism to cope with lissing packets, and packets arriving out of order. There is a nice mechanism for that in jacktrip: https://ccrma.stanford.edu/groups/soundwire/software/jacktrip/ https://ccrma.stanford.edu/~jcaceres/publications/PDFs/2009-caceres_chafe-I… Jacktrip: I have not looked at the code of jacktrip, but maybe a lightweight version of that could be implemented instead of the OSC approach? / Hans -- Hans Wilmers NOTAM Nedre Gate 5 N-0551 Oslo Norway tlf.: +47 22358065 http://www.notam02.no

Folderol: Same here :) Even if OSC has a "significant" overhead, I assume you don't exercise it so much that it would matter ? I'd turn off udp checksum. If you have a controlled network, you can minimize congestion. You mean something that could be called polling? 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://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 -----------------------------------------------------------------------

Folderol: ... The chip select comes with the spi bus interface, which(s) chip shall respond to the clock. That is normal for chips with spi bus. Some has an internal clock and some need an external. At most this will affect component count. It doesn't seem to be an easy way to sync TLC4545ID's. The sampling start after 5 clcks after chip_select, it need another 20 clcks for the sampling. Then you release the chip and it will convert the analog value to digital and it takes < 2.94us. During the sampling time the previous is clocked out. That is why I'm looking for a "start" pin on the chip, to be able to say to all ADCs to start simultaneously. Do we understand each other correctly? With a parallell bus I mean a bus with multiple data lines and multiple address lines. Examples of parallell buses are ISA and PCI. For the above chip you connect 16data lines cpu<->chip, the address lines from the cpu must be connected to some decoding logic defining the chips address. To use this chip you activates sync, wait till all chip signalled drdy and for each chip do two read cycles. The ad7762 has a 16bit wide data bus, and one could potentially put one chip on the top half and another on the lower half of the processors 32wide data bus. I don't know the memory interface speed of the sam9260, but if it is 10MHz and you spend two read cycles to get the data for two chips, the raw data rate would be 10Mwords / s. If you divide that with 96kHz, you see that the bus limit is 100channels (with a few ifs). Where the bus limit on spi would be more along the lines of 8-16 channels. According to [4] you can run it up to 50MHz, but it depends on the cpu and the chip you are communicating to, so 5-10MHz is more of what you can expect. ... Regards, /Karl [4] http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus ----------------------------------------------------------------------- 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 -----------------------------------------------------------------------

Martin Peach: ... ... I tend to dislike bitbanging, but yes, that should be doable, something like: void read_all_adcs() { uint32_t adc[32]; // up to 32 adc converters int ix; int kx; uint32_t bits; chip_select(0); // the first few bits are to start converter bits = get_data(); bits = get_data(); bits = get_data(); bits = get_data(); bits = get_data(); for (ix = 0; ix < 24; ix++) { bits = get_data(); for (kx = 0; kx < 32; kx++) { adc[kx] <<= 1; adc[kx] |= bits & 1; bits >>= 1; } } chip_select(1); } I have to think about that. The big "but" would be that the clock (the frequency of get_data()) should be stable, I don't know how much variation is allowed. 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 -----------------------------------------------------------------------

On Mon, 16 Nov 2009 21:13:54 +0000 Folderol &lt;folderol(a)ukfsn.org&gt; wrote: Talking to myself again :) Too late, it dawned on me that we are no longer talking about using spi so the above line is nonsense :( generate, not 'transmit' OK guys, back to normal! -- 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: .. BTW, I found: http://pmbus.org/Data_Communications_Issues_For_Digital_Power_Management_20… which discusses several types of buses. It classes (p30) spi as "Good Speed (1MHz)" 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 -----------------------------------------------------------------------

On Tue, 17 Nov 2009 23:04:19 +0100 "Martin Homuth-Rosemann" &lt;linuxaudio(a)cryptomys.de&gt; wrote: I had a look at this and my first thought was that it looks very nice and has a lot going for it, but my next one was that it puts us right back into dependence on a propriety piece of kit. -- 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.

Martin Homuth-Rosemann: ... Hello and welcome to the discussion. Shall take that as a question (you have no ?)? Don't you always have to separate the digital and the analog domains? My plan is to build a card frame based system with one main power module, one cpu card, with the possibility to add a lot of different i/o cards. One such card could be for audio input/output. (Although my main interest is industrial measurement and control.) With this the "dirty business" of ADC is separated to another card like an ordinary old soundcard you attached to your motherboard. Do we need more separation? Could it possible be because of: . space constraints . noise and audio quality . power constraints . economical factors . "time-to-market" etc. What are the key factors for you ? Do you have a spec. which you'd like to discuss ? E.g. how many channels are you regulary using, what s/n ratio is a minimal requirement for you ? Is your point, that the system should behave as an spdif etc. device instead of delivering the audio over ethernet? SPDIF [1], seems to be able to carry 20bit (maybe 24) 2 or 4 channels at 44.1 or 48kHz (possible other) sampling rates. AES-3 [2], seems to have the similar (24bit though) carrying capacity. ADAT [3], seems to be limited to 8 channels at 48 kHz, 24 bit. MADI [4], seems to be limited to 64 channels at 96kHz, 24 bit. If this project shall implement any of theese interfaces it might then be the ADAT or MADI, since I see no reason to implement the smaller interfaces. But if we successfully implement adat or madi, we are still missing the adat/madi part on the pc. So we still have a problem... And if we get i/o capacity problems with ethernet, we could easily add another ethernet card at relatively low cost. But then you might find that the rest of the computer is to small. Are you suggesting that that unit's spec is something to aim at ? Or is your point that it would be better to do a ADAT, or MADI interface for the pc instead of doing a "soundcard" ? Doing a adat/madi interface for the pc is outside of the scope of my projet, so I cannot help you there. Regards, /Karl [1] http://en.wikipedia.org/wiki/S/PDIF [2] http://en.wikipedia.org/wiki/AES/EBU [3] http://en.wikipedia.org/wiki/ADAT [4] http://en.wikipedia.org/wiki/MADI ----------------------------------------------------------------------- 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 -----------------------------------------------------------------------

On Thu, 19 Nov 2009 23:06:21 +0100 "Martin Homuth-Rosemann" &lt;linuxaudio(a)cryptomys.de&gt; wrote: I don't think anyone thought you were bugging them, just that you're looking in a different direction. I think we need to avoid all pulling in different directions, otherwise we end up with nothing. ... been there ... got the T shirt :( -- 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.

On Fri, 20 Nov 2009 02:00:47 +0100 (CET) karl(a)aspodata.se (Karl Hammar) wrote: Very similar Currently I have 3 stereo sources and one microphone, these are currently all fed into a D.I.Y. mixer with switched gain settings and then on to a 2496 soundcard (2 in + 2 out). The soundcard is quite old now, and requires an ordinary PCI interface. My immediate wish would be for 8 in x 2 out so I could get rid of the mixer (just keep a simple mic amp) and more precisely -and repeatably- define the input levels. Later it would be nice to have both more inputs and outputs so I could bring in another rarely used synth and start to experiment with surroundsound etc. I should also point out that I also put 2 softsynths into the mix. I've been working at 44.1kHz 16bit up to now for ease of producing CDs (not that I've sold any), but rather think I should be moving up to 48kHz 24bit ############ My thoughts would be that a first move would be for a 2 in card with ordinary unbalanced line level inputs, not worrying about noise level but trying to get a reasonably clear idea of THD as well as hammering out a communication protocol. My programming knowledge is limited, as are my hardware facilites. I can however test things out I have an analogue sine/square/triangle generator with less than 0.01% sinewave distortion (100Hz-10kHz), pretty clean square response and linear triangle output. I used to use this for testing amplifiers, along with a twin T notch filter, scope and valve voltmeter. I would be happy to buy a made-up development board with initial programming done, and then work in parallel with developers testing and improving both the software and hardware. -- 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.

On 11/21/2009 10:25 PM, Karl Hammar wrote: I'm certain you will find others will help with both. At this point I wonder if it might be better on the LAD list due to the level of detail being now discussed. I can help with this. Patrick Shirkey Boost Hardware Ltd

On 11/23/2009 05:52 AM, Folderol wrote: There is no Linux Audio Software Developers list and likewise no Linux Audio Hardware Developers list. The LAD list is meant for advanced technical discussions whereas the LAU list is meant for the discussions that don't fit into advanced technical realm. Prior to LAU list being setup everything was discussed on LAD which made it LAD and LAU combined. The noise ratio crept up as the user issues started creeping in. Patrick Shirkey Boost Hardware Ltd

Patrick Shirkey: ... Good. I will start working on this so we can have something to show. My stuff will be available mostly throu git and mailinglinst. 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 -----------------------------------------------------------------------

Folderol: Ok, I should get starting then. 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 -----------------------------------------------------------------------

On Sat, Nov 14, 2009 at 02:04:16PM +0100, Karl Hammar wrote: BGA does not put it out of the home hw hacker domain, it just requires a slightly more dedicated hacker. The interwebs are filled with guides for doing BGA at home, including toaster ovens (modified or plain), electric skillets, and hot air reflow.

On Wednesday 11 November 2009 11:48:30 Karl Hammar wrote: BeagleBoards seem to be gaining popularity too.. they're small, and go for about 150 $... sincerely, Marije