I was fooling around with a lunky 12 band EQ when it donned on me how cool a completely software-based very-high resolution equalizer would be. Perhaps this exists. I don't know. Still, it intruiged me. I came to the idea of designing a program build to implement minute alterations to all DirectSound programs. It wouldn't be all that hard to do create an EQ that had a specific band for each hertz in the audible range. It might slow an older computer signifigantly, but perhaps not. My knowledge of computer audio stiffly drops off past making relatively simple things. However, I'm a quick study when it comes to DirectX. Does anybody think this sort of stuff would be actually useful? Or does it already exist?
Also, it would only be a step away from implementing all sorts of fun algorithms designed to counted distortions caused by amplification and speaker imperfections. I have almost know nowledge of those sorts of maths - except basic things - so it would be a "learning" process should I attempt to code such software.
Also, it would only be a step away from implementing all sorts of fun algorithms designed to counted distortions caused by amplification and speaker imperfections. I have almost know nowledge of those sorts of maths - except basic things - so it would be a "learning" process should I attempt to code such software.
This exists, but ....
Hi there,
This exists today. Steinberg VST24 and Nuendo, probably others.
It would still be useful since I don't have this type of system presently (and I DO want it badly) so there is more to it than meets the eye!
What would be very useful is if it could upsample to 24/96 and work in full resolution. Most bands need to be low frequency -- need a shitload of bands under 1000Hz, not all that many over. Phase neutral. Also need phase filters. Low latency would be nice, also digital crossover (split 2 channels into left/right tweeter/bass). Also an option for adding digital gain to the tweeter (less energy in treble) to make full use of dedicated tweeter DAC and reduce gain in associated amplifier.
Do you have all the software you need?
Petter
Hi there,
This exists today. Steinberg VST24 and Nuendo, probably others.
It would still be useful since I don't have this type of system presently (and I DO want it badly) so there is more to it than meets the eye!
What would be very useful is if it could upsample to 24/96 and work in full resolution. Most bands need to be low frequency -- need a shitload of bands under 1000Hz, not all that many over. Phase neutral. Also need phase filters. Low latency would be nice, also digital crossover (split 2 channels into left/right tweeter/bass). Also an option for adding digital gain to the tweeter (less energy in treble) to make full use of dedicated tweeter DAC and reduce gain in associated amplifier.
Do you have all the software you need?
Petter
Good ideas. I don't know how one would implement a software crossover, though. The only way I can think of doing that is using multiple stereo sound cards or using surround cards like the SB Live! in some sort of hybridized stereo setup. It would be relatively easy should someone purchase two sound cards to create digital crossovers. One could design a very complex active crossover network with almost limitless options in that way. In fact, that is such a cool idea I think I will buy a second SB Live! and do just that. The only forseeable obstacle would be getting two sound cards to work simultaneously, but I doubt that's a real problem. DOS-mode compatability drivers would probably mess up, but that's not a problem at all.
First things first though: I need to read up a bit on how I would integrate the program(s). It's easy enough to design DirectSound plugins, or global effects for a specific program, but I haven't the foggiest idea of how to do it on a windows-wide level. I assume it's reasonably easy, though.
Oh, and should anybody know something about this stuff or think they could learn and can code in C/C++ With Windows API / MFC (whichever, MFC is generally easier but sort of annoying sometimes.. It's pretty much a must for DirectX though) and would like to help me, I would welcome it.
The other thing I was thinking about was the feasability of creating a digital profile of your speaker linearity (or lack thereof) and use it to create (near) linear response via software filtering.
[Edited by Ignite on 07-31-2001 at 05:15 PM]
First things first though: I need to read up a bit on how I would integrate the program(s). It's easy enough to design DirectSound plugins, or global effects for a specific program, but I haven't the foggiest idea of how to do it on a windows-wide level. I assume it's reasonably easy, though.
Oh, and should anybody know something about this stuff or think they could learn and can code in C/C++ With Windows API / MFC (whichever, MFC is generally easier but sort of annoying sometimes.. It's pretty much a must for DirectX though) and would like to help me, I would welcome it.
The other thing I was thinking about was the feasability of creating a digital profile of your speaker linearity (or lack thereof) and use it to create (near) linear response via software filtering.
[Edited by Ignite on 07-31-2001 at 05:15 PM]
I have a digital profiler (frequency and phase for in-room response) + unfinished speaker (missing crossover + port.
The problem with profiling is the calibrated microphone. Sound-cards + CPU's can do the job. My system is Clio-lite from Audiomatica (still in DOS, so I have an old Compaq colour portable in docking without hard-drive -- less noise that way!)
Maybe I could beta-test? Soon i will have access to a 16 channel digital output card.
Petter
The problem with profiling is the calibrated microphone. Sound-cards + CPU's can do the job. My system is Clio-lite from Audiomatica (still in DOS, so I have an old Compaq colour portable in docking without hard-drive -- less noise that way!)
Maybe I could beta-test? Soon i will have access to a 16 channel digital output card.
Petter
Listening room optimiser
In an issue of Hi-fi world (a UK magazine)some while back there was an article on a listening room optimiser.
The digital output from the CD player was passed though a DSP chip and then out again to whatever DAC you were using.
The LRO box came with a calibrated microphone - you set the thing up by defining a "Sweet spot" in the listening room by placing the mic at each corner of an imaginery 1 yard cube around your head. The box than worked out the freq response, effect of standing waves, etc and automatically calcualted a digital filter for the DSP to correct the signal with.
As the whole thing worked in the digital domain there was no analogue signal degradation.
The unit was a prototype and didn't go into production, the DSP used in the design has since been superceded by much faster versions, so whatever the previous cutoff frequency was it could be significantly improved upon now.
In an issue of Hi-fi world (a UK magazine)some while back there was an article on a listening room optimiser.
The digital output from the CD player was passed though a DSP chip and then out again to whatever DAC you were using.
The LRO box came with a calibrated microphone - you set the thing up by defining a "Sweet spot" in the listening room by placing the mic at each corner of an imaginery 1 yard cube around your head. The box than worked out the freq response, effect of standing waves, etc and automatically calcualted a digital filter for the DSP to correct the signal with.
As the whole thing worked in the digital domain there was no analogue signal degradation.
The unit was a prototype and didn't go into production, the DSP used in the design has since been superceded by much faster versions, so whatever the previous cutoff frequency was it could be significantly improved upon now.
DSP based in Audio Electronics
In a recent Audio Electronics (www.audioxpress.com) there was such a beast where the guy built the whole thing from scratch. It seems to me there are better ways to do this (in order of priority):
1. PC based
2. Buy an eval DSP board with necessary ports (and software libraries).
It would likely be so much easier and cheaper to do it on a PC.
Petter
In a recent Audio Electronics (www.audioxpress.com) there was such a beast where the guy built the whole thing from scratch. It seems to me there are better ways to do this (in order of priority):
1. PC based
2. Buy an eval DSP board with necessary ports (and software libraries).
It would likely be so much easier and cheaper to do it on a PC.
Petter
DSP Audio cards for PC's
Perhaps using a PC card with a sufficiently powerfull DSP card in it would be a way forward - i believe such cards exist but they are expensive.
Not sure that what kind of processing power would be required from a PC to appropriately condition the digital audio stream in real time, hence the use of a DSP card.
I'm interested in doing this if anyone's got any ideas about software.
Perhaps using a PC card with a sufficiently powerfull DSP card in it would be a way forward - i believe such cards exist but they are expensive.
Not sure that what kind of processing power would be required from a PC to appropriately condition the digital audio stream in real time, hence the use of a DSP card.
I'm interested in doing this if anyone's got any ideas about software.
I suspect a PC is good enough
but if you want to go the DSP way, get an evaluation board from http://www.ti.com or http://www.analog.com or http://www.cirrus.com which has all the inputs and outputs you need.
They also have software ...
But the PC method is where I would go. Check out the specks of nuendo or VST24 to see what can be done in real time.
An alternative is a good soundcard with a programmable DSP. These things are becoming more and more powerful by the minute.
Petter
but if you want to go the DSP way, get an evaluation board from http://www.ti.com or http://www.analog.com or http://www.cirrus.com which has all the inputs and outputs you need.
They also have software ...
But the PC method is where I would go. Check out the specks of nuendo or VST24 to see what can be done in real time.
An alternative is a good soundcard with a programmable DSP. These things are becoming more and more powerful by the minute.
Petter
I've been studying digital audio and digital signal processing extensively for the past few years. Right now I'm working on building a high-powered audio DSP processors for just the type of tasks mentioned above...
The basic design revolves around an Analog Devices SHARC processor. You need this kind of power if you want to implement the really kinky algorithms (eg big FIR filters or convolutions). The trouble is, these computations require hundreds or even thousands of MAC (Multiply and Accumulate) operations *per sample*!!! So, you can see that 300 MFLOPS is barely enough to handle even some of the simpler algorithms in real time. Today's PC's are not really up to the task, because although they can have fast processors, they're general purpose processors which are not optimized to handle real-time signal processing, and a PC also has the overhead of a klunky OS like windoze. Then, of course, there's the fan noise, or that you can't use your 1GHz Athlon while your music's on...
I did look at using eval boards, but was put off by the price and the limited capabilities and i/o options you have with them... perhaps some new ones have come along lately, but I'm already well on the way to finishing this monster.
Anyway, when I'm finished, the DSP box I'm building should be able to perform some smokin cool tricks, like speaker impulse response correction (which removes all phase and frequency response errors from the speaker) as well as linear-phase crossovers for subwoofers (where phase errors are most apparent) and so on... whatever you're up to programming!
My preliminary design was finished as my graduating university project in May of this year, but I'm doing some rework with my project partner to improve the design. The final design will include:
- multiple digital SPDIF inputs
- AD1896 ASRCs to remove jitter and resample everything to either 48 or 96kHz, 24 bit (selectable)
- ADSP-21065L processor (32 bit floating point processor)
- microcontroller for LCD panel display and host control with spare ports for controlling whatever goodies someone wants to add on.
- good output DACs (currently under review, but probably the CS43122), with I2S outputs for alternate DACs.
So, right now the design is sidetracked somewhat while I build some more test DACs to evaluate. Hopefully I'll get my website back up again soon, and can post updates as more progress is made...
The basic design revolves around an Analog Devices SHARC processor. You need this kind of power if you want to implement the really kinky algorithms (eg big FIR filters or convolutions). The trouble is, these computations require hundreds or even thousands of MAC (Multiply and Accumulate) operations *per sample*!!! So, you can see that 300 MFLOPS is barely enough to handle even some of the simpler algorithms in real time. Today's PC's are not really up to the task, because although they can have fast processors, they're general purpose processors which are not optimized to handle real-time signal processing, and a PC also has the overhead of a klunky OS like windoze. Then, of course, there's the fan noise, or that you can't use your 1GHz Athlon while your music's on...
I did look at using eval boards, but was put off by the price and the limited capabilities and i/o options you have with them... perhaps some new ones have come along lately, but I'm already well on the way to finishing this monster.
Anyway, when I'm finished, the DSP box I'm building should be able to perform some smokin cool tricks, like speaker impulse response correction (which removes all phase and frequency response errors from the speaker) as well as linear-phase crossovers for subwoofers (where phase errors are most apparent) and so on... whatever you're up to programming!
My preliminary design was finished as my graduating university project in May of this year, but I'm doing some rework with my project partner to improve the design. The final design will include:
- multiple digital SPDIF inputs
- AD1896 ASRCs to remove jitter and resample everything to either 48 or 96kHz, 24 bit (selectable)
- ADSP-21065L processor (32 bit floating point processor)
- microcontroller for LCD panel display and host control with spare ports for controlling whatever goodies someone wants to add on.
- good output DACs (currently under review, but probably the CS43122), with I2S outputs for alternate DACs.
So, right now the design is sidetracked somewhat while I build some more test DACs to evaluate. Hopefully I'll get my website back up again soon, and can post updates as more progress is made...
oh, forgot to mention.. I designed this thing with my student budget in mind, but the expensive part is going to be the 4-layer circuit board.
However, if enough people are interested, a larger production run would bring the PCB cost down dramatically. If anyone's interested in the possibility of helping review the design, programming software, or just building one for themselves, please drop me an email and let me know what kind of target price range you would consider...
However, if enough people are interested, a larger production run would bring the PCB cost down dramatically. If anyone's interested in the possibility of helping review the design, programming software, or just building one for themselves, please drop me an email and let me know what kind of target price range you would consider...
hifiZen
How does the the Cystal DPS compare with the Shark? I noticed that Crystal has a lot of reference design info on their website for DSP based audio projects (including source code). Free software always makes me happy, but it seems as though the Crystal DSP is an older generation product and may not have the horsepower for doing more complicated processing.
Have you looked at the Yamaha DSP Factory sound card? This card is marketed to the studio recording market, but it is an incredible audio product. The DSP Factory has 5 DSP chips on-board and does an incredible amount of real time sound processing without consuming any of the host processor's bandwidth.
Here is a feature list for the DSP Factory:
- 24 channel, 32-bit digital mixer
- 10 bus outputs and 6 aux sends
- 104 bands of 4-band parametric EQ
- 26 dynamics processors
- 2 effect processors equal in quality to Yamaha's REV500
- Channel delay on 20 channels
- Comprehensive metering
- Digital cross-patching for channel inputs and outputs
- 2 channel 20-bit AD/DA converter
- Stereo DIGITAL(Coaxial) input and output
- ALL the above features are available all the time
Here is a review of the board:
http://www.prorec.com/prorec/articles.nsf/files/5BD5DE332CEF2FF5862565C3007CF838
Can you imagine if someone wrote an audiophile app for this card? You might be able to create a system to do real time room acoustics compensation (using a room mic as an input), plus all of the normal eq and crossover duties. If you combine this with a surround sound system you could even have the system monitor where people are located in the room and adjust the sweetspot for best results. Of course then I would need to have an RF tag on my keychain so the system would know where I was sitting and give me priority. ;^)
Phil
How does the the Cystal DPS compare with the Shark? I noticed that Crystal has a lot of reference design info on their website for DSP based audio projects (including source code). Free software always makes me happy, but it seems as though the Crystal DSP is an older generation product and may not have the horsepower for doing more complicated processing.
Have you looked at the Yamaha DSP Factory sound card? This card is marketed to the studio recording market, but it is an incredible audio product. The DSP Factory has 5 DSP chips on-board and does an incredible amount of real time sound processing without consuming any of the host processor's bandwidth.
Here is a feature list for the DSP Factory:
- 24 channel, 32-bit digital mixer
- 10 bus outputs and 6 aux sends
- 104 bands of 4-band parametric EQ
- 26 dynamics processors
- 2 effect processors equal in quality to Yamaha's REV500
- Channel delay on 20 channels
- Comprehensive metering
- Digital cross-patching for channel inputs and outputs
- 2 channel 20-bit AD/DA converter
- Stereo DIGITAL(Coaxial) input and output
- ALL the above features are available all the time
Here is a review of the board:
http://www.prorec.com/prorec/articles.nsf/files/5BD5DE332CEF2FF5862565C3007CF838
Can you imagine if someone wrote an audiophile app for this card? You might be able to create a system to do real time room acoustics compensation (using a room mic as an input), plus all of the normal eq and crossover duties. If you combine this with a surround sound system you could even have the system monitor where people are located in the room and adjust the sweetspot for best results. Of course then I would need to have an RF tag on my keychain so the system would know where I was sitting and give me priority. ;^)
Phil
Take a look at the Pro world
Meyers has been doing this for sound reinforcement for years. On their website are some great white papers. Given that pro sound companies have to go into different venues every night, have the ability to do computer based eq and tweaking is almost required. While it has been several years since I actual played with it, it can offer amazing results. They do a real time compare signal to eq mic and add correction.
Given the price of computer stuff today, there is no reason that we cannot begin to implement this in our homes. The microphone will be the hard part. I know the card I want - Digigram makes some fantastic DSP cards. You will be able to calibrate the mic pretty easy, but it will need consistant response. Good mics are not cheap.
[Sawzall enters dreamland]
I can imagine having a computer based system as a head end. It would have a touch screen controller that can list all the music in my database, allowing me to choose the music I wanted to hear in the order I wanted. It would also control the system for loudness, eq, delay, effects, etc (basically a small mix desk). No reason it could not control my TV, DVD and other media stuff too. Finally, it would have the eq mentioned above.
That would be a great system to build, and there is no tech reason it cannot be built. It would not even be that expensive, considering the cost of our systems anyhow. It would be a great deal of computer programming, so having it done in open source would be great so that we can all share the work and more importantly, the results. I know the commercial software is out there now - I have had my hands on it - we just need to get a hobby version.
Meyers has been doing this for sound reinforcement for years. On their website are some great white papers. Given that pro sound companies have to go into different venues every night, have the ability to do computer based eq and tweaking is almost required. While it has been several years since I actual played with it, it can offer amazing results. They do a real time compare signal to eq mic and add correction.
Given the price of computer stuff today, there is no reason that we cannot begin to implement this in our homes. The microphone will be the hard part. I know the card I want - Digigram makes some fantastic DSP cards. You will be able to calibrate the mic pretty easy, but it will need consistant response. Good mics are not cheap.
[Sawzall enters dreamland]
I can imagine having a computer based system as a head end. It would have a touch screen controller that can list all the music in my database, allowing me to choose the music I wanted to hear in the order I wanted. It would also control the system for loudness, eq, delay, effects, etc (basically a small mix desk). No reason it could not control my TV, DVD and other media stuff too. Finally, it would have the eq mentioned above.
That would be a great system to build, and there is no tech reason it cannot be built. It would not even be that expensive, considering the cost of our systems anyhow. It would be a great deal of computer programming, so having it done in open source would be great so that we can all share the work and more importantly, the results. I know the commercial software is out there now - I have had my hands on it - we just need to get a hobby version.
The trouble with fancy DSP...
well, it's far too broad a subject for me to give a complete dissertation on this forum, but I'll attempt to explain some of the audio algorithms.
Get ready, cuz this is a long one...
Basically, there are two broad classes of algorithms we can use to process audio:
1. IIR or Infinite Impulse Response filters
2. FIR or Finite Impulse Response filters
In the case of (1), we have algorithms implemented as digital equivalents of their analog counerparts (at least in some abstract sense). A signal (datastream) enters the filter, which consists of a number of data paths in the form of a matrix of feedback loops. An architecture of this type is capable of producing an infinite length output sequence from a single non-zero input sample (or impulse) due to the feedback. Hence, the Infinite Impulse Response nomenclature. Due to their architecture, IIR filters are extremely computationally efficient, and so we can have a DSP using IIR filters which can do many hundreds of EQ bands and so forth. However, there are problems with IIR techniques. For starters, these filters can be very sensetive to quantization effects, and great care must be taken to use sufficient word length to ensure that errors are kept to a minimum. This sensetivity is strongly affected by the specific architecture used to implement the transfer function (there are usually several different ways to implement a given filter). Perhaps most significantly, IIR filters are limited to transfer functions that can be implemented in the analog world. This is due to the fact that IIR filters are *causal* systems... that is, an output response cannot start before the input has arrived, just like in the real world.
Now, here's where things get really cool... FIR filters! If we are willing to accept a small delay, we can buffer up some data and build a NON-CAUSAL system! eg.. one that is capable of doing things which are impossible in the analog world!!!
Ok, now FIR algorithms work on an entirely different principle than IIR filters, and it's fundamental nature requires an immense amount of computational power to implement. Now, at this point, you may be thinking to yourself "don't digital filters like the DF1704 use FIR filters?, and they don't seem like very powerful or expensive chips.". Well, suffice it to say that a dedicated hardware architecture can do a whole lot more with a whole lot less than a programmable processor. The DF1704 and similar digital audio processors are only capable of doing one, fixed task.
So, on to FIR filters. If we take the inverse Fourier transform of the ideal brick wall lowpass filter, we get something called the sinc function, or sin(x)/x. Umm, I'd like to draw a picture here, but uh... ok i'm sure if you're that curious, you can browse around the net until you find a picture of what I'm referring to. OK, so this thing (the sinc function) is what the output from a perfect lowpass filter would look like if we put a very short pulse into it's input... the key point here is that the sinc function goes from t = -infinity to +infinity... eg, it is a non-causal impulse response. Thus, it cannot be implemented with IIR algorithms, but it can be done with FIR algorithms. Now, if we implement an FIR filter based on the sinc function, we'll have a perfect brickwall lowpass filter. The kicker is that if we then look at the phase response of this thing, we find that it has zero degrees phase shift at ALL frequencies (aka linear phase)! Truly beautiful, isn't it??? *sigh*... So this is how interpolation is performed inside chips like the DF1704, and a variation of this type of calculation allows the AD189x devices to acheive asynchronous sample rate conversion, all with completely flat frequency response, and PERFECT phase response.
Now, FIR filters are not strictly limited to lowpass filters, nosirree! In fact, we can implement absolutely any desired impulse response we like (provided we have enough computational power to do this). Now, the reason the aforementioned filter is linear phase has to do with the fact that the impulse response function (sinc) is symmetric about t=0. By using an asymmetric impulse response, we can tailor the phase response to be anything we desire, independent of the frequency response chosen. Now, we have a REALLY POWERFUL tool!!! ...something only dreamt about by the likes of Blumlein and our other audio forefathers. To sweeten the pie even more, it just so happens that FIR filters are not susceptible to the same quantization sensetivity problems of IIR filters, and an FIR filter is guaranteed to be stable, unconditionally. But, this all comes at a price: it can take many hundreds or even thousands of calculations *per audio sample* to do FIR filtering.
With FIR capability, we can remove acoustic echos in the listening room, or correct the frequency and phase response of a loudspeaker, or implement a speaker crossover which is near-perfect!
For the sake of completeness, I should mention that IIR and FIR filters are not the only classes of algorithms we can use... but it is generally accepted that for high-performance audio, these are the algorithms of choice. Other classes of algorithm can make use of the FFT or DCT to break down a waveform in the manner used to prepare data for MP3 compression. The data can then be manipulated in the frequency domain and translated backusing the inverse transform. This process generally causes a loss of resolution which may or may not be acceptable to the audiophile. There are also wavelet techniques, which are emerging as a very powerful and useful class of algorithms.
Anyway, as you can see, these DSP processors such as the Cirrus parts and Yamaha boards most probably use strictly IIR filters, and so they don't do anything particularly interesting as far as I'm concerned - and it is a misconception to believe that these algorithms are "perfect" because they take place in the digital domain... IIR filters still suffer from the phase response problems of analog filters.
Now, imagine a SHARC ADSP-21065L sitting quietly on your shelf, providing a genuine zero-phase, 60Hz crossover for your subwoofer... suddenly, the bass is all in perfect phase, right in the region where even small phase shifts can cause perceptible time-delays in the bass output. Personally, I can't wait to hear how it will sound!
Here's to the advent of high-powered DSP! The holy grail may be upon us...
Cheers,
[Edited by hifiZen on 09-10-2001 at 04:51 AM]
well, it's far too broad a subject for me to give a complete dissertation on this forum, but I'll attempt to explain some of the audio algorithms.
Get ready, cuz this is a long one...
Basically, there are two broad classes of algorithms we can use to process audio:
1. IIR or Infinite Impulse Response filters
2. FIR or Finite Impulse Response filters
In the case of (1), we have algorithms implemented as digital equivalents of their analog counerparts (at least in some abstract sense). A signal (datastream) enters the filter, which consists of a number of data paths in the form of a matrix of feedback loops. An architecture of this type is capable of producing an infinite length output sequence from a single non-zero input sample (or impulse) due to the feedback. Hence, the Infinite Impulse Response nomenclature. Due to their architecture, IIR filters are extremely computationally efficient, and so we can have a DSP using IIR filters which can do many hundreds of EQ bands and so forth. However, there are problems with IIR techniques. For starters, these filters can be very sensetive to quantization effects, and great care must be taken to use sufficient word length to ensure that errors are kept to a minimum. This sensetivity is strongly affected by the specific architecture used to implement the transfer function (there are usually several different ways to implement a given filter). Perhaps most significantly, IIR filters are limited to transfer functions that can be implemented in the analog world. This is due to the fact that IIR filters are *causal* systems... that is, an output response cannot start before the input has arrived, just like in the real world.
Now, here's where things get really cool... FIR filters! If we are willing to accept a small delay, we can buffer up some data and build a NON-CAUSAL system! eg.. one that is capable of doing things which are impossible in the analog world!!!
Ok, now FIR algorithms work on an entirely different principle than IIR filters, and it's fundamental nature requires an immense amount of computational power to implement. Now, at this point, you may be thinking to yourself "don't digital filters like the DF1704 use FIR filters?, and they don't seem like very powerful or expensive chips.". Well, suffice it to say that a dedicated hardware architecture can do a whole lot more with a whole lot less than a programmable processor. The DF1704 and similar digital audio processors are only capable of doing one, fixed task.
So, on to FIR filters. If we take the inverse Fourier transform of the ideal brick wall lowpass filter, we get something called the sinc function, or sin(x)/x. Umm, I'd like to draw a picture here, but uh... ok i'm sure if you're that curious, you can browse around the net until you find a picture of what I'm referring to. OK, so this thing (the sinc function) is what the output from a perfect lowpass filter would look like if we put a very short pulse into it's input... the key point here is that the sinc function goes from t = -infinity to +infinity... eg, it is a non-causal impulse response. Thus, it cannot be implemented with IIR algorithms, but it can be done with FIR algorithms. Now, if we implement an FIR filter based on the sinc function, we'll have a perfect brickwall lowpass filter. The kicker is that if we then look at the phase response of this thing, we find that it has zero degrees phase shift at ALL frequencies (aka linear phase)! Truly beautiful, isn't it??? *sigh*... So this is how interpolation is performed inside chips like the DF1704, and a variation of this type of calculation allows the AD189x devices to acheive asynchronous sample rate conversion, all with completely flat frequency response, and PERFECT phase response.
Now, FIR filters are not strictly limited to lowpass filters, nosirree! In fact, we can implement absolutely any desired impulse response we like (provided we have enough computational power to do this). Now, the reason the aforementioned filter is linear phase has to do with the fact that the impulse response function (sinc) is symmetric about t=0. By using an asymmetric impulse response, we can tailor the phase response to be anything we desire, independent of the frequency response chosen. Now, we have a REALLY POWERFUL tool!!! ...something only dreamt about by the likes of Blumlein and our other audio forefathers. To sweeten the pie even more, it just so happens that FIR filters are not susceptible to the same quantization sensetivity problems of IIR filters, and an FIR filter is guaranteed to be stable, unconditionally. But, this all comes at a price: it can take many hundreds or even thousands of calculations *per audio sample* to do FIR filtering.
With FIR capability, we can remove acoustic echos in the listening room, or correct the frequency and phase response of a loudspeaker, or implement a speaker crossover which is near-perfect!
For the sake of completeness, I should mention that IIR and FIR filters are not the only classes of algorithms we can use... but it is generally accepted that for high-performance audio, these are the algorithms of choice. Other classes of algorithm can make use of the FFT or DCT to break down a waveform in the manner used to prepare data for MP3 compression. The data can then be manipulated in the frequency domain and translated backusing the inverse transform. This process generally causes a loss of resolution which may or may not be acceptable to the audiophile. There are also wavelet techniques, which are emerging as a very powerful and useful class of algorithms.
Anyway, as you can see, these DSP processors such as the Cirrus parts and Yamaha boards most probably use strictly IIR filters, and so they don't do anything particularly interesting as far as I'm concerned - and it is a misconception to believe that these algorithms are "perfect" because they take place in the digital domain... IIR filters still suffer from the phase response problems of analog filters.
Now, imagine a SHARC ADSP-21065L sitting quietly on your shelf, providing a genuine zero-phase, 60Hz crossover for your subwoofer... suddenly, the bass is all in perfect phase, right in the region where even small phase shifts can cause perceptible time-delays in the bass output. Personally, I can't wait to hear how it will sound!
Here's to the advent of high-powered DSP! The holy grail may be upon us...
Cheers,
[Edited by hifiZen on 09-10-2001 at 04:51 AM]
So you seem to be saying that the small cost of a good system is that it has to have delay for a read ahead buffer? No big deal to me. All of the good signal process gear I know of right now has this. In fact, the broadcast world has just about accepted this - it stops you from using your air signal as monitor which bothers some DJ types but the engineering folks have accepted this. In fact, almost all digital transmission systems have this delay due to forward error correction / time diversity. 4 to 5 seconds worth of buffer seems to be the amount generally done. It lets you do your math, save up for errors, but does not delay the signal so long that waiting for a channel selection is painfull.
One issue of the debate is hardware vs. software. How do you implement your device? Smart hardware is faster, generally is not as fragil. But it limits your ability to improve the firm ware as it is either burned in or built in. (sorta the CISC type of computing) On the other side, software dependent implementaion allows for you to use new code as it improves. I think that given the increased speed vs cost nowdays, software becomes a more acceptable solution if not as elegant.
In my own case, I have no problem developing the software required to select and play the tunes. Building the database and interface is doable using code parts from both stuff that exists and new code to put it all together. I can program that. Where I am going to need help is the hard core development of the signal processing. I would love to be part of a team to develop an open source solution using some "SOTA" equipment - say a fast PC running Linux with the right audio chips. Let the PC play router / controller for the signals with the audio chips / boards doing the work on the sound.
The key for me is the development philosophy - do it as an audiophile project as opposed to mass market. Spend the few extra bucks for that 5th 9 as it were. I have no interest in building a system that sounds worse than straight playout from a good CD player just for the ease of operation of a computer based playout system. I want the sonic improvements that are possible once I go this route. That probably means that sound cards as we know them are not acceptable - no $250 card is going to work.
One issue of the debate is hardware vs. software. How do you implement your device? Smart hardware is faster, generally is not as fragil. But it limits your ability to improve the firm ware as it is either burned in or built in. (sorta the CISC type of computing) On the other side, software dependent implementaion allows for you to use new code as it improves. I think that given the increased speed vs cost nowdays, software becomes a more acceptable solution if not as elegant.
In my own case, I have no problem developing the software required to select and play the tunes. Building the database and interface is doable using code parts from both stuff that exists and new code to put it all together. I can program that. Where I am going to need help is the hard core development of the signal processing. I would love to be part of a team to develop an open source solution using some "SOTA" equipment - say a fast PC running Linux with the right audio chips. Let the PC play router / controller for the signals with the audio chips / boards doing the work on the sound.
The key for me is the development philosophy - do it as an audiophile project as opposed to mass market. Spend the few extra bucks for that 5th 9 as it were. I have no interest in building a system that sounds worse than straight playout from a good CD player just for the ease of operation of a computer based playout system. I want the sonic improvements that are possible once I go this route. That probably means that sound cards as we know them are not acceptable - no $250 card is going to work.
Well, in the case of digital audio, the delay may only be in the range of a few hundred milliseconds, depending on the algorithm used.
Now, if you're going to use a computer for this, then you may as well use the computer's processor for all the math, which means that the computer would have to be pretty much dedicated to audio processing only. If you're going to go to the trouble of using a separate DSP processor chip to tackle the math, you might as well make it a stand-alone unit.
I chose the SHARC processor because of the ability to reprogram it fairly quickly and painlessly. The board has a separate host processor (Atmel microcontroller actually) to handle user interface and code downloads. The one problem with using the SHARC is that the software dev tools are not easily available... they're very expensive and so not really suited to an individual hobbyist. Fortunately, Analog Devices makes available a free, fully functional evaluation version of it's software (good for 30 days).
A big FPGA could potentially be faster than a DSP processor, but they are much harder to program and debug (now you're writing code in a hardware description language).
Now, the easiest solution from a software dev point of view is definitely a PC running linux. I've thought about this, and the best I could come up with was this: build a stand-alone box with digital audio receivers, ASRCs and spdif transmitters/DACs... the stuff you need to be close to your transport and preamp. Give it an ethernet port, and run cat-5 to a computer in the next room where you don't have to listen to it's fans. Voila! Pipe the data to your computer, do the math, and send it back. There are problems with this approach, and cost is certainly one of them (if you include the dedicated pc), processing power is the other...
[Edited by hifiZen on 09-16-2001 at 06:44 PM]
Now, if you're going to use a computer for this, then you may as well use the computer's processor for all the math, which means that the computer would have to be pretty much dedicated to audio processing only. If you're going to go to the trouble of using a separate DSP processor chip to tackle the math, you might as well make it a stand-alone unit.
I chose the SHARC processor because of the ability to reprogram it fairly quickly and painlessly. The board has a separate host processor (Atmel microcontroller actually) to handle user interface and code downloads. The one problem with using the SHARC is that the software dev tools are not easily available... they're very expensive and so not really suited to an individual hobbyist. Fortunately, Analog Devices makes available a free, fully functional evaluation version of it's software (good for 30 days).
A big FPGA could potentially be faster than a DSP processor, but they are much harder to program and debug (now you're writing code in a hardware description language).
Now, the easiest solution from a software dev point of view is definitely a PC running linux. I've thought about this, and the best I could come up with was this: build a stand-alone box with digital audio receivers, ASRCs and spdif transmitters/DACs... the stuff you need to be close to your transport and preamp. Give it an ethernet port, and run cat-5 to a computer in the next room where you don't have to listen to it's fans. Voila! Pipe the data to your computer, do the math, and send it back. There are problems with this approach, and cost is certainly one of them (if you include the dedicated pc), processing power is the other...
[Edited by hifiZen on 09-16-2001 at 06:44 PM]
PC solution
seems to be the best one to me - it offers a fairly open upgrade path. Need more, buy more. Cost is much less of an issue than one might think. Big, power hungry and fast is not that expensive, it is just when try to make it smaller or less watt intensive that there is a real cost jump. If you leave the machine out of the room, those are not a problem. Secondly, it offers you the ability to store and that is just getting cheaper. Playback without changing disks is a real win.
Digital audio receivers for your PC are out, at least of the near future. (see rants) So CD based source material is going to be it for at least 10 years.
Finally, PC based solutions are going to be the most assessable by large groups. That platform is everywhere and there are tools available for less cost. Seems to me it is the hobby's future since we are going to be cut off unless chip makers can obtain the rights to use the codecs burned into their chips.
seems to be the best one to me - it offers a fairly open upgrade path. Need more, buy more. Cost is much less of an issue than one might think. Big, power hungry and fast is not that expensive, it is just when try to make it smaller or less watt intensive that there is a real cost jump. If you leave the machine out of the room, those are not a problem. Secondly, it offers you the ability to store and that is just getting cheaper. Playback without changing disks is a real win.
Digital audio receivers for your PC are out, at least of the near future. (see rants) So CD based source material is going to be it for at least 10 years.
Finally, PC based solutions are going to be the most assessable by large groups. That platform is everywhere and there are tools available for less cost. Seems to me it is the hobby's future since we are going to be cut off unless chip makers can obtain the rights to use the codecs burned into their chips.
Why Linux?
What is it that fundamentally makes Linux more appropriate for such duty than other operating systems? If the CPU as per your suggestions is incapable of doing the required calculations, Linux will not save you.
Either way, if you have a PC, why not use it as the source as well. On Windows, most of the plumbing is already in place -- with Linux, it depends on your hardware and whether you have drivers and also required software. Software such as Nuendo and VST24 are probably able to do required filtering in real-time with our without hardware support. Indeed, Windows media player incluldes SRS WOW effects and a rough equalizer, both of these algorithms that most CPU's can execute without trouble -- even my laptom can do this without a hitch (at the same time it decoded DVD, Dolby Digital 5.1 and I am surfing websites with streaming video ...
Also, a DSP running at 60MHz is unlikely to be more powerful than a P4 2Gig or a dual Celeron 1000 which I will have soon. One of the main reasons for implementing MMX and subsequent refinements of same was to provide the processor with DSP like qualities to enable software speech processing, software modems, software graphics etc.
Watch this space.
Petter
What is it that fundamentally makes Linux more appropriate for such duty than other operating systems? If the CPU as per your suggestions is incapable of doing the required calculations, Linux will not save you.
Either way, if you have a PC, why not use it as the source as well. On Windows, most of the plumbing is already in place -- with Linux, it depends on your hardware and whether you have drivers and also required software. Software such as Nuendo and VST24 are probably able to do required filtering in real-time with our without hardware support. Indeed, Windows media player incluldes SRS WOW effects and a rough equalizer, both of these algorithms that most CPU's can execute without trouble -- even my laptom can do this without a hitch (at the same time it decoded DVD, Dolby Digital 5.1 and I am surfing websites with streaming video ...
Also, a DSP running at 60MHz is unlikely to be more powerful than a P4 2Gig or a dual Celeron 1000 which I will have soon. One of the main reasons for implementing MMX and subsequent refinements of same was to provide the processor with DSP like qualities to enable software speech processing, software modems, software graphics etc.
Watch this space.
Petter
Well, the important thing about linux, for those who have the pleasure of using it, is the free dev. tools (C++ compilers and so forth), and the excellent community support. This is a very significant economization. Perhaps another significant advantage is the much easier API, which would greatly simplify a custom application like this where you may want to diddle around at a very low level to optimize the system. One final advantage is that linux is easy to strip down to a very small system without any of the bloat that comes along with windoze. It would not be too difficult for a knowledgable linux user to stip the kernel down to a very small size which would boot rapidly and use very little memory and system resources. If you plan on using up the bulk of the processor's power, these kinds of optimizations are important. The final nail in the coffin is that Linux has superb support for almost all commercial devices.. *open source* drivers for a vast array of devices which you can modify to suit your particular application. What you need to understand about linux is that it was specifically developed by tinkerers for tinkerers... the whole structure is in place for the easiest and most flexible development environment possible... the fact that linux has been ported to run on almost anything from an embedded microcontroller to a supercomputer, and that it is the leading OS for internet servers is a testament to it's versatility and robustness.. plus, i like the fact that you can run linux literally for months, even years on end without any crashes...
[end windows trashing]
ok, perhaps I was a bit harsh. I'm actually a regular windows user, but it's mainly because all of my engineering type software is available only this os... I do know what the limitations of windows are, and I'm open minded about the advantages and disadvantages of other OSs. One of linux's weak points is the learning curve...
As far as PC processing power is concerned, before you read the next bit, perhaps you should review my previous long post where I describe why the algorithms I want to implement are so much more processing-intensive than the WOW effects and EQ you mentioned. Try a 1500-tap FIR filter, for instance...
Now, regarding clock speed... this has absolutely *nothing* to do with *anything*!!! It's such an annoying and useless statistic... it's like comparing car engine RPMs without knowing the gear ratios, torque, horsepower or vehicle weight. "Hey man, my 250cc motorbike does 14,000 RPMs! How does your supercharged Pontiac GTO 454 with nitrous look now, huh buddy?"
A DSP is by definition NOT a general purpose computer... it is a highly efficient math machine with special hardware provisions for DSP operations. Without getting into the specifics, let me just say that the hardware underlying GPPs (general purpose processors) is not in any way comparable to the innards of a DSP, and so it is a completely unfair comparison to look at clock speeds. For a better comparison, may I direct you to some independent benchmarks, which show the real-world DSP performance of the processors in question... Bear in mind that these benchmarks are not infalliable... and I'll get to that in a moment:
http://www.bdti.com/bdtimark/BDTImark2000.htm
Be sure to read both the floating-point test results and the explaination of the BDTImark.
Now, you may be thinking that I just proved you right, because the PIII 1GHz comes out about 10x faster than the SHARC 2106x. Now here's where we start talking about how we need to normalize these benchmarks for the specific application we're talking about. If you read the BDTImark test details, you'll notice starting on page 3 an explaination of the limitations of the BDTImark tests.
For the PIII vs. ADSP-2106x:
1. PIII uses 32-bit precision, if we go to 48 bit precision like the ADSP, the performance is halved.
2. A PIII in a PC is on a general purpose motherboard not optimized for DSP applications. Most significantly the memory interface isn't nearly as well integrated, and consequently there is a bottleneck in memory access speed which does not exist in an ADSP system with dedicated zero-wait-state SRAM memory using the ADSPs integrated background DMA controllers and sophisticated Harvard memory architecture.
3. SDRAM used in PCs needs to periodically refresh, which takes some time and happens at intervals which are non-deterministically related to what's happening in the processor. In a real-time applications which push the limits of the processor, these refreshes can cause (relatively) long interruptions in memory access, and this may be unacceptable, causing an interruption in the output data stream.
4. a PC will inevitably run an OS, which will have some overhead (maybe 1-5%). Again, OS tasks are spurious interruptions in the real-time tasks. A DSP needn't run any OS at all... just pure continuous math instructions read straight from it's dedicated memory... janitorial tasks are handled by a separate host processor (which could be as simple as a PIC micro)
There are other factors which I'm just too tired to think about and list right now, but basically if you add them up, the PIII really comes out maybe only 2 or 3 times as fast as a SHARC processor, and I believe a P4 does not have much edge on the PIII for DSP stuff. So, we're not talking about a large difference in speed here. As it is, by my preliminary estimates, I will be making nearly full use of the SHARCs power, so the same tasks on a PC would continuously consume about 50%. What this implies is that if you use a PC for algorithms like this, you'd better make that PC a dedicated audio-processing-only machine, otherwise you'll have interruptions in your music. Furthermore, you really couldn't risk pushing the PC beyond about 70% or 80% of it's capability without risking a loss of continuous real-time data delivery.
So, I think I've shown that although a PC appears like a nice solution, it is in practice a much more expensive and clumsy option for only a modest improvement in capability (not to mention a noisy power hog by comparison!).
One final anecdote to sink home my perspective: at work I deal with the DoMiNo digital video processor, which can handle real-time video transcoding with aplomb, and does a significantly more sophisticated job of it than PC software. This chip runs at oh, 100ish MHz. Ever try transcoding video on your PC? I have... I grabbed one of my DVDs for fun, and pulled the video across into Divx format. My 900 MHz Athlon Thunderbird took all night long to recode the video... On a benchmark, I doubt the DoMiNo would score too well against an Athlon.
[Edited by hifiZen on 09-12-2001 at 06:18 PM]
[end windows trashing]
ok, perhaps I was a bit harsh. I'm actually a regular windows user, but it's mainly because all of my engineering type software is available only this os... I do know what the limitations of windows are, and I'm open minded about the advantages and disadvantages of other OSs. One of linux's weak points is the learning curve...
As far as PC processing power is concerned, before you read the next bit, perhaps you should review my previous long post where I describe why the algorithms I want to implement are so much more processing-intensive than the WOW effects and EQ you mentioned. Try a 1500-tap FIR filter, for instance...
Now, regarding clock speed... this has absolutely *nothing* to do with *anything*!!! It's such an annoying and useless statistic... it's like comparing car engine RPMs without knowing the gear ratios, torque, horsepower or vehicle weight. "Hey man, my 250cc motorbike does 14,000 RPMs! How does your supercharged Pontiac GTO 454 with nitrous look now, huh buddy?"
A DSP is by definition NOT a general purpose computer... it is a highly efficient math machine with special hardware provisions for DSP operations. Without getting into the specifics, let me just say that the hardware underlying GPPs (general purpose processors) is not in any way comparable to the innards of a DSP, and so it is a completely unfair comparison to look at clock speeds. For a better comparison, may I direct you to some independent benchmarks, which show the real-world DSP performance of the processors in question... Bear in mind that these benchmarks are not infalliable... and I'll get to that in a moment:
http://www.bdti.com/bdtimark/BDTImark2000.htm
Be sure to read both the floating-point test results and the explaination of the BDTImark.
Now, you may be thinking that I just proved you right, because the PIII 1GHz comes out about 10x faster than the SHARC 2106x. Now here's where we start talking about how we need to normalize these benchmarks for the specific application we're talking about. If you read the BDTImark test details, you'll notice starting on page 3 an explaination of the limitations of the BDTImark tests.
For the PIII vs. ADSP-2106x:
1. PIII uses 32-bit precision, if we go to 48 bit precision like the ADSP, the performance is halved.
2. A PIII in a PC is on a general purpose motherboard not optimized for DSP applications. Most significantly the memory interface isn't nearly as well integrated, and consequently there is a bottleneck in memory access speed which does not exist in an ADSP system with dedicated zero-wait-state SRAM memory using the ADSPs integrated background DMA controllers and sophisticated Harvard memory architecture.
3. SDRAM used in PCs needs to periodically refresh, which takes some time and happens at intervals which are non-deterministically related to what's happening in the processor. In a real-time applications which push the limits of the processor, these refreshes can cause (relatively) long interruptions in memory access, and this may be unacceptable, causing an interruption in the output data stream.
4. a PC will inevitably run an OS, which will have some overhead (maybe 1-5%). Again, OS tasks are spurious interruptions in the real-time tasks. A DSP needn't run any OS at all... just pure continuous math instructions read straight from it's dedicated memory... janitorial tasks are handled by a separate host processor (which could be as simple as a PIC micro)
There are other factors which I'm just too tired to think about and list right now, but basically if you add them up, the PIII really comes out maybe only 2 or 3 times as fast as a SHARC processor, and I believe a P4 does not have much edge on the PIII for DSP stuff. So, we're not talking about a large difference in speed here. As it is, by my preliminary estimates, I will be making nearly full use of the SHARCs power, so the same tasks on a PC would continuously consume about 50%. What this implies is that if you use a PC for algorithms like this, you'd better make that PC a dedicated audio-processing-only machine, otherwise you'll have interruptions in your music. Furthermore, you really couldn't risk pushing the PC beyond about 70% or 80% of it's capability without risking a loss of continuous real-time data delivery.
So, I think I've shown that although a PC appears like a nice solution, it is in practice a much more expensive and clumsy option for only a modest improvement in capability (not to mention a noisy power hog by comparison!).
One final anecdote to sink home my perspective: at work I deal with the DoMiNo digital video processor, which can handle real-time video transcoding with aplomb, and does a significantly more sophisticated job of it than PC software. This chip runs at oh, 100ish MHz. Ever try transcoding video on your PC? I have... I grabbed one of my DVDs for fun, and pulled the video across into Divx format. My 900 MHz Athlon Thunderbird took all night long to recode the video... On a benchmark, I doubt the DoMiNo would score too well against an Athlon.
[Edited by hifiZen on 09-12-2001 at 06:18 PM]
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.