Open Source DSP XOs

[Trevor White]

Originally Posted by steph_tsf

Interesting discussion. Let's focus on a Butterworth highpass 8th-order 30 Hz -3dB. Sampling frequency 96 kHz. What method would you advise, on a DSP56K, for getting rid of the noise & distorsion produced by the native (naïve ?) series IIR BiQuad implementation ? Keep in mind we need the exact same Bode plot. What would be most exact and efficient way ?
- Boosting the precision using more elaborate arithmetic routines for the multiply-accumulation (say, reaching a 32-bit data path inside the BiQuad, operating with 64-bit accumulator) ? What would be the computing time penalty ?
- Decimating the signal, applying a series IIR BiQuad in a lower sampling frequency context, upsampling the signal for getting back a 96 kHz sampling frequency ? What decimation factor to use ? Can we guarantee a Bode plot that's exact ?
- Any other method welcome

For low frequency filters I used state variable filters on an Analog Devices SHARC because the direct form and SIMD optimized library functions produced to much noise. I assume the state variable filters would work equally well for fixed point 32 bit and 24 bit DSP's.

[steph_tsf]

Originally Posted by Trevor White

For low frequency filters I used state variable filters on an Analog Devices SHARC because the direct form and SIMD optimized library functions produced to much noise.

Hi Trevor, would you dare saying that for the low frequencies (like a 2nd-order 30Hz highpass on a 96 kHz system with Q in the range of 0.3 to 3.0), that the output from a hand-coded Chamberlin Digital State Variable Filter will be cleaner than the output from a hand-coded Direct Form IIR BiQuad ?

[Trevor White]

Originally Posted by steph_tsf

Hi Trevor, would you dare saying that for the low frequencies (like a 2nd-order 30Hz highpass on a 96 kHz system with Q in the range of 0.3 to 3.0), that the output from a hand-coded Chamberlin Digital State Variable Filter will be cleaner than the output from a hand-coded Direct Form IIR BiQuad ?

yes it should be

[steph_tsf]

Originally Posted by chaparK

Finally, 24 bits is 144 dB of dynamic range: that covers everything from ants walking to the heart of the space shuttle's engines. If you can't do proper audio processing on a 24-bit platform then maybe you should indeed stick to analogue filters and let dsp to dsp guys.

A friendly reply is to recommend the Handbook of Digital Signal Processing Engineering Applications (Elliott, Vaidynathan, Harris, Pasthoon, Silva, +)

[steph_tsf]

Originally Posted by rsdio

By the way, if anyone knows of a professionally-designed DSP product that has an interrupt per audio sample, please let me know. That would be a very interesting design choice considering the number of cycles of overhead per interrupt.

Being from the old (naïve ?) "one interrupt per sample" audio DSP school, I feel great respect for any system that is not "one interrupt per sample", thus needing audio buffers (size from 256 to 1024 samples) like the Steinberg ASIO for MS Windows, that some skilled people can persuade to never crash during a live performance.
I feel the same respect for ALSA and JACK running on GNU/Linux and Mac OS X.
With the advent of multicore GHz-class CPUs, in a system featuring a single sampling frequency, I feel there should be a possibility to run ALSA and JACK with a "buffer_size = 1" setting.
Within ALSA and JACK, in a system featuring a single sampling frequency, a nice feature would be to get a CPU core and its associated cache memory, entirely dedicated to the audio occuring at Fs, thus one interrupt per sample. Is this currently feasible ? Knowing the 2.6 Kernel may not digest a 10 µs interrupt (96 kHz audio), it may be necessary to let the kernel think that he is dealing with an audio system operating at Fs/256 with a 256-sized buffer, allowing an other CPU core to deal with the details. The Fs/256 "software interrupt" would only be seen and processed by the main CPU cores running the kernel (like taking the user inputs), while the Fs "hardware interrupt" would only be seen and processed by the CPU core dedicated to ALSA and JACK.

[rsdio]

Originally Posted by steph_tsf

With the advent of multicore GHz-class CPUs, in a system featuring a single sampling frequency, I feel there should be a possibility to run ALSA and JACK with a "buffer_size = 1" setting.
Within ALSA and JACK, in a system featuring a single sampling frequency, a nice feature would be to get a CPU core and its associated cache memory, entirely dedicated to the audio occuring at Fs, thus one interrupt per sample. Is this currently feasible ?

The question is moot. Whether the OS can handle the interrupts or not, the audio hardware is not designed for this. USB Audio Class cannot interrupt any faster than 1 ms at Full Speed, which is 100 times slower than what you suggest for 96 kHz audio. I do not know the limits of FireWire audio, off hand, but they are probably similar due to the packet nature of most bus designs. PCI Audio designs might be capable of one interrupt per sample, but most are designed to use the system DMA rather than an interrupt.

Another consideration is that systems like OSX are designed around symmetric multi-processing, but you describe an asymmetric system where one processor handles audio exclusively while others handle general non-audio tasks. It would require quite a lot of kernel changes, I'd imagine, to implement what you suggest.

Basically, general purpose processors are probably always going to be limited to dealing with buffers of multiple audio samples. Meanwhile, embedded processors can be dedicated to audio and thus might be able to handle one interrupt per sample, but they will probably still need to communicate with general processors via buffers, unless the embedded system has its own media source (such as a CD Player).

[abraxalito]

Originally Posted by rsdio

Meanwhile, embedded processors can be dedicated to audio and thus might be able to handle one interrupt per sample, but they will probably still need to communicate with general processors via buffers, unless the embedded system has its own media source (such as a CD Player).

In my own implementations of DSP on the ARM Cortex M0 and M3, I've managed so far to avoid using interrupts entirely. Since processing audio is entirely deterministic, I can't see the point myself. Interrupts for me are when you can't really be sure when an event is going to happen - in contrast, digital audio is 100% predictable. Why spend the overhead of context save and restore when not absolutely essential?

[Trevor White]

Originally Posted by abraxalito

In my own implementations of DSP on the ARM Cortex M0 and M3, I've managed so far to avoid using interrupts entirely. Since processing audio is entirely deterministic, I can't see the point myself. Interrupts for me are when you can't really be sure when an event is going to happen - in contrast, digital audio is 100% predictable. Why spend the overhead of context save and restore when not absolutely essential?

The problem is if you use the DSP for anything else such as updating a display, reading buttons, serial comms, USB etc then you could run into trouble. The idea of using interrupts is to make sure the audio processing always gets priority over anything else. All of the lower priority tasks can be polled as usual.

[abraxalito]

Originally Posted by Trevor White

The problem is if you use the DSP for anything else such as updating a display, reading buttons, serial comms, USB etc then you could run into trouble.

Yep, I don't do that with my designs. All user interface I/O I'd typically offload to another CPU. That's one reason I really love the LPC43XX dual core approach. In the future, tablets will be so ubiquitous that they'll be the first choice for any user interfaces then all user I/O will happen over the interface to the tablet which might well be USB (or perhaps Bluetooth for wireless).

The idea of using interrupts is to make sure the audio processing always gets priority over anything else. All of the lower priority tasks can be polled as usual.

Yep, its one way to handle it. The way I prefer is to make sure the audio processing gets done first, then beyond that there's time for those less urgent tasks, most of which could be handled by polling.

[Trevor White]

Originally Posted by abraxalito

Yep, I don't do that with my designs. All user interface I/O I'd typically offload to another CPU. That's one reason I really love the LPC43XX dual core approach. In the future, tablets will be so ubiquitous that they'll be the first choice for any user interfaces then all user I/O will happen over the interface to the tablet which might well be USB (or perhaps Bluetooth for wireless).



Yep, its one way to handle it. The way I prefer is to make sure the audio processing gets done first, then beyond that there's time for those less urgent tasks, most of which could be handled by polling.

But unless you have something to interrupt those lower priority tasks then you run into trouble if they stretch out to long. This leads you back to a preemptive multitasking OS and that means interrupts. You can't escape it