On Sun, 2010-07-04 at 22:15 +0200, Ralf Mardorf wrote: (only) Trying again, I accidentally sent this off list the first time.... It is more that a general purpose preemptive multitasking OS is less good for audio/midi. If you are working in a world where you know the available hardware in detail LOTS of things become easy, for example I can time stamp an incoming MIDI byte with the sample number of reported as current position by the sound card (There is only one), instant way to get effectively zero latency jitter. This doesn't work nearly so well when there is more then one sound card, the MIDI UART has effectively a fixed fifo (USB midi), and there is an SMM interrupt that cannot be masked. Conversely the upside is that we can mostly plug in a soundcard or a midi interface designed after the application and the thing will work. I have done audio on ARM if that counts (Both under Linux and on bare sand). If you need to support a GUI and networking Linux is a huge win, otherwise if just implementing a special purpose audio cruncher you are better off running standalone. Regards, Dan.

On Sun, 2010-07-04 at 23:35 +0200, fons(a)kokkinizita.net wrote: Could do it even with separate midi and audio cards, as long as the midi RX ISR can somehow grab a timestamp from the audio card driver (in an interrupt context), and as long as the midi RX ISR is getting serviced with negligible latency (Otherwise you need to timestamp in hardware). In reality is is probably only practical in an embedded context where you have total control over the hardware. Note that even with this you will have some jitter due to the way a UART typically over samples to get the centre location of each bit (But at midi rates this should only be measured in tens of microseconds). MIDI on general purpose hardware with a general purpose OS is hard to get really right. Regards, Dan.

On Sun, Jul 04, 2010 at 11:05:02PM +0100, Dan Mills wrote: It shouldn't be, and you don't even need an UART. Just handle it as an analog signal, i.e. one more audio channel. Even 44.1 kHz is enough to preserve all information. The ratio of bit frequency vs. sample frequency is a bit odd, but that is in practice not a real problem. On input just use some DSP to recover the bits (peanuts on a modern CPU). On output all you need to ensure is that the zero-crossings of the generated analog waveform (after the antialias filter) are correct, then let the HW turn it into the required square wave. Result: sample-accurate MIDI. Ciao, -- Je veux que la mort me trouve plantant mes choux, mais nonchalant d’elle, et encore plus de mon jardin imparfait. (Michel de Montaigne)

On Sun, Jul 4, 2010 at 5:35 PM, <fons(a)kokkinizita.net> wrote: not quite the same thing, but the very first audio interface to be supported on linux - the gravis ultrasound - could function as an interrupt source driven by the MIDI UART. 1 interrupt per MIDI byte transmit/receive cycle. awesome ... and, AFAIK, never repeated.

On Sun, Jul 4, 2010 at 8:17 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: I disagree. These processors used pipelining techniques pioneered in RISC processor designs, but have nothing to do with the concept of "RISC" ... especially because such pipelining and execution optimization in CISC processors use a lot of transistors -- the very thing being conserved with RISC. The modern x86 adopted some of the optimizations of RISC, but they are certainly not RISC -- by definition -- because they do not employ Reduced Instruction Set Computing: Their instruction sets are huge and complex, and their transistor counts are astronomical: Core i7 has 731 MILLION transistors. ( http://en.wikipedia.org/wiki/Transistor_count ). ... In fact, with Floating Point Arithmetic ops, SSX, 3DNow, SSE, etc these architectures provide an ever-growing specialized instruction sets (the opposite of RISC) and transistor counts (opposite of RISC). RISC was a stupid idea in the first place. A temporary hack based on fabrication limitations at the time. Now that those fabrication limits have been solved, there's no need for RISC, in general computing -- which is why Sun Microsystems was bought by Oracle for pennies on the dollar, and why AMD and Intel dominate. However, for embedded, apps, RISC is king because it allows you to put the same processor subcomponent on a variety of different application specific chips. For example, Broadcom sticks the same MIPS core in a variety of set top box/DVR chips: http://www.broadcom.com/products/Cable/Cable-Set-Top-Box-Solutions/BCM7125 . http://en.wikipedia.org/wiki/X86#Current_implementations ................. During execution, current x86 processors employ a few extra decoding steps to split most instructions into smaller pieces (micro-operations). These are then handed to a control unit that buffers and schedules them in compliance with x86-semantics so that they can be executed, partly in parallel, by one of several (more or less specialized) execution units. These modern x86 designs are thus superscalar, and also capable of out of order and speculative execution (via register renaming), which means they may execute multiple (partial or complete) x86 instructions simultaneously, and not necessarily in the same order as given in the instruction stream. When introduced, this approach was sometimes referred to as a "RISC core" or as "RISC translation", partly for marketing reasons, but also because these micro-operations share some properties with certain types of RISC instructions. However, traditional microcode (used since the 1950s) also inherently shares many of the same properties; the new approach differs mainly in that the translation to micro-operations now occurs asynchronously. Not having to synchronize the execution units with the decode steps opens up possibilities for more analysis of the (buffered) code stream, and therefore permits detection of operations that can be performed in parallel, simultaneously feeding more than one execution unit. The latest processors also do the opposite when appropriate; they combine certain x86 sequences (such as a compare followed by a conditional jump) into a more complex micro-op which fits the execution model better and thus can be executed faster or with less machine resources involved. .................. http://en.wikipedia.org/wiki/Reduced_instruction_set_computing#RISC_and_x86 .................... Although RISC was indeed able to scale up in performance quite quickly and cheaply, Intel took advantage of its large market by spending vast amounts of money on processor development. Intel could spend many times as much as any RISC manufacturer on improving low level design and manufacturing. The same could not be said about smaller firms like Cyrix and NexGen, but they realized that they could apply (tightly) pipelined design practices also to the x86-architecture, just like in the 486 and Pentium. The 6x86 and MII series did exactly this, but was more advanced, it implemented superscalar speculative execution via register renaming, directly at the x86-semantic level. Others, like the Nx586 and AMD K5 did the same, but indirectly, via dynamic microcode buffering and semi-independent superscalar scheduling and instruction dispatch at the micro-operation level (older or simpler ‘CISC’ designs typically executes rigid micro-operation sequences directly). The first available chip deploying such dynamic buffering and scheduling techniques was the NexGen Nx586, released in 1994; the AMD K5 was severely delayed and released in 1995. Later, more powerful processors such as Intel P6, AMD K6, AMD K7, Pentium 4, etc employed similar dynamic buffering and scheduling principles and implemented loosely coupled superscalar (and speculative) execution of micro-operation sequences generated from several parallel x86 decoding stages. Today, these ideas have been further refined (some x86-pairs are instead merged, into a more complex micro-operation, for example) and are still used by modern x86 processors such as Intel Core 2 and AMD K8. ............... -- Niels http://nielsmayer.com