"Actually, TD convolution can be used for analyzing acoustic properties of a concert hall."
Strictly speaking, yes, but not mentioned in the article.
"Also, when the FA says 'without converting to the frequency domain', why do you go on to talk about FFTs? "
Bah. I knew someone would pull me up on that.
Because they provide a fast way of doing convolution, even for quite long impulse responses. I wanted to point out that you don't have to use time domain convolution on a DSP just to use long impulse samples. (It's how everyone else does it.)
While direct convolution is roughly (n^2) operations, doing the same using FFT/DFT as part of the process can make it as small as (n log n). (Assuming a fairly big n, for small values direct is faster, also n must be a multiple of 2, sampled impulse observe nyquist limits etc, but with audio all these can be assumed.)
Within those limitations, the result is *exactly* the same as doing a direct convolution, which is why I mentioned it.
"the cost of professional studio DSP solutions which can run into the high five-figure range
How is that less than a consumer 3d card???"
*Can* run into the high five figure range... Most of the time they don't. You should compare consumer 3d cards to consumer audio DSP cards, which cost a lot less. (Check out Uaudio etc, or indeed the humble SBLive)
I'm sure really high end graphics cards run into the high five figure range.
"And no, this isn't for gamers. RTFA. It's about doing audio stuff like measuring and analyzing the acoustic properties of concert halls, etc."
The FA makes no mention of doing spectral analysis. They talk about time domain convolution which is used to do reverbs or simulation of eqs (same thing if you thing about it from an impulse response viewpoint..). You just take an impulse response of the location you wish to simulate and convolve your audio with it.
By the way, in the FA it says...
"We are currently working on a time-domain convolution that will perform this processing without converting to the frequency domain. This is absolutely impossible in real time using the CPU of the PC, because the calculations required for even short samples are so high, but it is within the realm of possibility on your GPU."
Which is rubbish, as you don't get truncation effects when using FFTs for convolution as the window size is irrelevent. This has been solved a long time ago, and is the reason that any convolving reverb sounds the same as any other given the same internal precision and sampled impulse response.
If your main concern is games, then you don't need real time high end convolution audio processing anyway.
For those of us that do, it's going to be cheaper to buy quality DSPs with plugins that sound good.
The alternative is to buy a graphics card not designed for the job and then buy software plugins for it to do the job that a dedicated DSP card could do much better.
If you just want a cheap DSP reverb, buy a soundblaster Live, there is even an open source compiler (as10k1) for it so you can write your own DSP code. Perhaps someone will write a 3d graphics engine.:)
Really, compiling a program is not a big deal.
I have heard many engineers saying "So, I need to terminate the SCSI at the sampler rather than at the external HD?", "So moving the card to another slot and dowloading new chipset drivers may fix the interrupt problem?","So the pops and clicks are caused by windows update starting while I'm recording?", "So by reverting to MacOS 9 and using OPCODE drivers my midi might work?".
Most of us studio engineers are fairly technical bears, and have dealt with much worse than compiling software. There are already unofficial rpms too, if you want to go that way.
I don't think I will be replacing my main rig with Ardour for a long time, but using it on the location rig works OK, and is a hell of a lot cheaper than buying OS+Software again.
I think what was irritating was your statement that their are no audio apps for Linux, when it turns out that there are just none that meet your specific need.
Not everyone wants a softsynth-tracker like Reason, some prefer synths like JMax, PD, etc.
Not everyone wants a sequencer like Cubase, many are looking for a SADiE or audio PT solution, which is filled nicely by Ardour.
Audigy is useless for musicians.
on
Testing the Audigy
·
· Score: 2, Informative
There are a few problems with the Audigy that prevent it from being a good card to record with.
Firstly, it still works for recording internally at 48k only, so if you are working at 44.1, every recording you make will be upsampled to 48k, then back to 44k. This causes pass band ripple and can be seen clearly on a spectrogram when the Audigy is fed with white noise. If you work at 48k, you will still need to sample rate convert before cutting a CD.
Secondly, the Audigy will not sync to an external digital clock, meaning that it cannot do sample accurate digital transfers. You will have to sync external gear to the dubious quality of the Audigy's clock, causing jitter.
The digital outs are only at 48k as well, so forget about clocking a DAT to the Audigy for digital transfers, even if it *could* pass a digital signal unchanged.
Thirdly, ASIO is only at 48k. This is because it has to avoid the internal SRC, working at 44k would cause an ASIO host to slowly lose samples, putting tracks out of time and causing MIDI to play late. Again, you would have to SRC before cutting a CD from your ASIO recordings.
Fourthly, the claimed 24/96 is playback only. You cannot record at 24bit or 96k with this card, and the DAs are fairly low quality, negating the point of 24/96 playback anyway.
Slashdot Mirror
"Actually, TD convolution can be used for analyzing acoustic properties of a concert hall."
Strictly speaking, yes, but not mentioned in the article.
"Also, when the FA says 'without converting to the frequency domain', why do you go on to talk about FFTs? "
Bah. I knew someone would pull me up on that.
Because they provide a fast way of doing convolution, even for quite long impulse responses. I wanted to point out that you don't have to use time domain convolution on a DSP just to use long impulse samples. (It's how everyone else does it.)
While direct convolution is roughly (n^2) operations, doing the same using FFT/DFT as part of the process can make it as small as (n log n). (Assuming a fairly big n, for small values direct is faster, also n must be a multiple of 2, sampled impulse observe nyquist limits etc, but with audio all these can be assumed.)
Within those limitations, the result is *exactly* the same as doing a direct convolution, which is why I mentioned it.
"the cost of professional studio DSP solutions which can run into the high five-figure range How is that less than a consumer 3d card???" *Can* run into the high five figure range... Most of the time they don't. You should compare consumer 3d cards to consumer audio DSP cards, which cost a lot less. (Check out Uaudio etc, or indeed the humble SBLive) I'm sure really high end graphics cards run into the high five figure range. "And no, this isn't for gamers. RTFA. It's about doing audio stuff like measuring and analyzing the acoustic properties of concert halls, etc." The FA makes no mention of doing spectral analysis. They talk about time domain convolution which is used to do reverbs or simulation of eqs (same thing if you thing about it from an impulse response viewpoint..). You just take an impulse response of the location you wish to simulate and convolve your audio with it. By the way, in the FA it says... "We are currently working on a time-domain convolution that will perform this processing without converting to the frequency domain. This is absolutely impossible in real time using the CPU of the PC, because the calculations required for even short samples are so high, but it is within the realm of possibility on your GPU." Which is rubbish, as you don't get truncation effects when using FFTs for convolution as the window size is irrelevent. This has been solved a long time ago, and is the reason that any convolving reverb sounds the same as any other given the same internal precision and sampled impulse response.
Well, then how did you afford the graphics card?
:)
If your main concern is games, then you don't need real time high end convolution audio processing anyway.
For those of us that do, it's going to be cheaper to buy quality DSPs with plugins that sound good.
The alternative is to buy a graphics card not designed for the job and then buy software plugins for it to do the job that a dedicated DSP card could do much better.
If you just want a cheap DSP reverb, buy a soundblaster Live, there is even an open source compiler (as10k1) for it so you can write your own DSP code. Perhaps someone will write a 3d graphics engine.
Really, compiling a program is not a big deal. I have heard many engineers saying "So, I need to terminate the SCSI at the sampler rather than at the external HD?", "So moving the card to another slot and dowloading new chipset drivers may fix the interrupt problem?","So the pops and clicks are caused by windows update starting while I'm recording?", "So by reverting to MacOS 9 and using OPCODE drivers my midi might work?". Most of us studio engineers are fairly technical bears, and have dealt with much worse than compiling software. There are already unofficial rpms too, if you want to go that way. I don't think I will be replacing my main rig with Ardour for a long time, but using it on the location rig works OK, and is a hell of a lot cheaper than buying OS+Software again.
I think what was irritating was your statement that their are no audio apps for Linux, when it turns out that there are just none that meet your specific need. Not everyone wants a softsynth-tracker like Reason, some prefer synths like JMax, PD, etc. Not everyone wants a sequencer like Cubase, many are looking for a SADiE or audio PT solution, which is filled nicely by Ardour.
Isn't this what SSE, MMX, Altivex etc do already?
There are a few problems with the Audigy that prevent it from being a good card to record with.
Firstly, it still works for recording internally at 48k only, so if you are working at 44.1, every recording you make will be upsampled to 48k, then back to 44k. This causes pass band ripple and can be seen clearly on a spectrogram when the Audigy is fed with white noise. If you work at 48k, you will still need to sample rate convert before cutting a CD.
Secondly, the Audigy will not sync to an external digital clock, meaning that it cannot do sample accurate digital transfers. You will have to sync external gear to the dubious quality of the Audigy's clock, causing jitter.
The digital outs are only at 48k as well, so forget about clocking a DAT to the Audigy for digital transfers, even if it *could* pass a digital signal unchanged.
Thirdly, ASIO is only at 48k. This is because it has to avoid the internal SRC, working at 44k would cause an ASIO host to slowly lose samples, putting tracks out of time and causing MIDI to play late. Again, you would have to SRC before cutting a CD from your ASIO recordings.
Fourthly, the claimed 24/96 is playback only. You cannot record at 24bit or 96k with this card, and the DAs are fairly low quality, negating the point of 24/96 playback anyway.