Open Source DSP XOs - Page 23 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 12th May 2012, 02:21 AM   #221
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by steph_tsf View Post
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 (nave ?) 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.
  Reply With Quote
Old 12th May 2012, 07:52 AM   #222
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by Trevor White View Post
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 ?
  Reply With Quote
Old 13th May 2012, 02:15 AM   #223
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by steph_tsf View Post
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
  Reply With Quote
Old 13th May 2012, 10:26 PM   #224
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by chaparK View Post
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, +)
  Reply With Quote
Old 13th May 2012, 11:33 PM   #225
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by rsdio View Post
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 (nave ?) "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.

Last edited by steph_tsf; 13th May 2012 at 11:46 PM. Reason: udio),
  Reply With Quote
Old 14th May 2012, 01:34 AM   #226
rsdio is offline rsdio  United States
diyAudio Member
 
Join Date: Feb 2008
Location: Seattle
Quote:
Originally Posted by steph_tsf View Post
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).
  Reply With Quote
Old 14th May 2012, 01:46 AM   #227
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 96
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Quote:
Originally Posted by rsdio View Post
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?
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 14th May 2012, 02:09 AM   #228
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by abraxalito View Post
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.
  Reply With Quote
Old 14th May 2012, 02:16 AM   #229
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 96
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Quote:
Originally Posted by Trevor White View Post
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).

Quote:
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.
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 14th May 2012, 02:57 AM   #230
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by abraxalito View Post
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
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Volume / Source selector - open source project ? AuroraB Analog Line Level 22 22nd September 2012 02:21 PM
Violet DSP Evolution - an Open Baffle Project cuibono Multi-Way 211 18th May 2010 02:26 AM
Open call for suggestions on Open Source DIY Audio Design gfergy Everything Else 1 15th April 2007 07:33 AM
Open Source, Open Architecture! zenmasterbrian Digital Source 185 23rd February 2007 10:35 PM


New To Site? Need Help?

All times are GMT. The time now is 10:19 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2