Hello Bob
Nice to see you here
I don't know if that would be easy to operate an Intel-based CPU without a full-blown (ie bloated) OS, but the hardware sure looks sexy: the Intel nuke plateform can run passive, especially with the new ultra low Wattage CPU coming this year, and SSD disks are now a commodity as well.
That said, even the current crop of SHARC DSP could run much longer FIRs if downsampling (decimation) and/or FFT convolution was to be used (the later requires more memory, and also implies more delay, which is a huge drawback in my opinion).
I know more10 (a member here as well) has been playing with downsampling with a SHARC DSP board with great results : JBL Master Reference Monitor - Page 36
Nice to see you here
I don't know if that would be easy to operate an Intel-based CPU without a full-blown (ie bloated) OS, but the hardware sure looks sexy: the Intel nuke plateform can run passive, especially with the new ultra low Wattage CPU coming this year, and SSD disks are now a commodity as well.
That said, even the current crop of SHARC DSP could run much longer FIRs if downsampling (decimation) and/or FFT convolution was to be used (the later requires more memory, and also implies more delay, which is a huge drawback in my opinion).
I know more10 (a member here as well) has been playing with downsampling with a SHARC DSP board with great results : JBL Master Reference Monitor - Page 36
The trick is the embedded operating system. And good FIR libraries.
Intel's Wind River tweaks embedded OS for Core i7
There is no information on the cost for a development environment. Most probably you will have to write the FIR functions yourself.
The i7 processor is not a DSP. So everything will have to be brute force (multiply accumulate). Implementing my filter on this architecture would require the same resources as three 192 kHz 2048 filter taps per side.
This means 2048*6*192k = 2,4 gig multiply and accumulate per second, should require about 5 GFLOPS
Accoring to Intel® Core i7-3900 Desktop Processor Series it performs 154 GFLOPS.
It is about 30 times as powerful as needed. It will shurely produce about 30 times the heat as well.
This means 2048*6*192k = 2,4 gig multiply and accumulate per second, should require about 5 GFLOPS
Accoring to Intel® Core i7-3900 Desktop Processor Series it performs 154 GFLOPS.
It is about 30 times as powerful as needed. It will shurely produce about 30 times the heat as well.
A dedicated MiniSHARC will have far better latency than an OS based solution.
Observe that without downsampling the required dsp power will be about 4 + 16 + 64 = 84 times larger for a four way filter. Cannot be done even on an i7. Using pure FIR that is, no frequency domain mumbo jumbo
Of course, but if you only need the FIR for phase correction and use IIR for frequency response changes then the MiniSHARC running the OpenDRC plugin is enough to phsae correct even LR4 @ 25 hz which as long as you use it for a speaker should be good enough.
If you are using it for reverb and such then of course it is probably not enough.
Check voxengo pristine space, it runs 32 ZERO latency firs of 6 seconds on my i7...
It does this by doing the first 64 samples brute force, the rest throug fft. Run this on Ubuntu with wine and you have everything you can dream of.
And no., there is not a difference between fft convolution or brute force, the mathematically result is EXACTLY the same (I have measured it and the results null)
Kees
It does this by doing the first 64 samples brute force, the rest throug fft. Run this on Ubuntu with wine and you have everything you can dream of.
And no., there is not a difference between fft convolution or brute force, the mathematically result is EXACTLY the same (I have measured it and the results null)
Kees
Nice to see you, Tom! Bonjour(soir). As a purist I'm concerned about the decimation steps you describe. It remains to be heard. What I do to avoid the question with Acourate is run a long filter when I don't care about latency, 65536 sample IR length. I think that means the same as "taps" (crazy long, huh, but that's what Uli believes in and it sure sounds pure and accurate!
When I care about latency, only for editing, PQ coding and cleanup tasks in mastering, I push one button on a remote that Uli and I have devised, and it switches to a short minimum phase filter and minimum phase crossover. So I can have the best of both worlds and not question anything.
So, until I can do a shootout of a tricked-out decimated sharc versus my Acourate system I prefer to stick with what I know to sound absolutely transparent, and stunningly musical. I also run the same Acourate-generated filters in Jriver so I can have perfect audio-video sync with these enormous FIR filters.
So for me, conquering the stability issues of Windows would be nice. An embedded system that just boots to the software of interest in less than a minute would be my goal. My Shuttle Computer that runs Acourate Convolver has a main and a backup SSD, but it's always asking for Windows updates (even for Windows 8) and it runs antivirus and other stuff that bother me. And it takes about 3-5 minutes to get everything up and running from a cold or warm boot. That's not an appliance, that's a home computer. I want an appliance. An appliance would solve the day-to-day issues of occasional reboots, etc. But it would not solve the issue of total breakdown.
So instead I'm building two Open-DRC boxes as soon as they arrive from Mini-DSP and I'll do something like my Acourate filters dumbed down to 6144 taps or a combination of IIR and Rephase and that will be my backup for the stereo portion of my system which I need daily for my mastering work. The surround portion, bass-managed and DRC'ed by Acourate, can live with being down if the Shuttle computer dies as I don't do surround mastering that often.
To answer the other poster's question, why do I need an i7 to run convolution? I'm not sure, I just wanted to have the most memory and speed possible. For 5.1, bass management, DRC and LFE, I have 12 or 13 individual 65536-long FIR filters that can run 192 kHz material direct to the DAC at 192 kHz with no decimation or ASRC in the path or necessary. I don't know if something less than my six-core i7 with 16 Gigs of RAM is suitable but I didn't want to take a chance so I did some overkill. The system is stable and reliable and that's what I need.
Latency? When in the high resolution mode... Oh, about a second.
Best wishes,
Bob
When I care about latency, only for editing, PQ coding and cleanup tasks in mastering, I push one button on a remote that Uli and I have devised, and it switches to a short minimum phase filter and minimum phase crossover. So I can have the best of both worlds and not question anything.
So, until I can do a shootout of a tricked-out decimated sharc versus my Acourate system I prefer to stick with what I know to sound absolutely transparent, and stunningly musical. I also run the same Acourate-generated filters in Jriver so I can have perfect audio-video sync with these enormous FIR filters.
So for me, conquering the stability issues of Windows would be nice. An embedded system that just boots to the software of interest in less than a minute would be my goal. My Shuttle Computer that runs Acourate Convolver has a main and a backup SSD, but it's always asking for Windows updates (even for Windows 8) and it runs antivirus and other stuff that bother me. And it takes about 3-5 minutes to get everything up and running from a cold or warm boot. That's not an appliance, that's a home computer. I want an appliance
. An appliance would solve the day-to-day issues of occasional reboots, etc. But it would not solve the issue of total breakdown. So instead I'm building two Open-DRC boxes as soon as they arrive from Mini-DSP and I'll do something like my Acourate filters dumbed down to 6144 taps or a combination of IIR and Rephase and that will be my backup for the stereo portion of my system which I need daily for my mastering work. The surround portion, bass-managed and DRC'ed by Acourate, can live with being down if the Shuttle computer dies as I don't do surround mastering that often.
To answer the other poster's question, why do I need an i7 to run convolution? I'm not sure, I just wanted to have the most memory and speed possible. For 5.1, bass management, DRC and LFE, I have 12 or 13 individual 65536-long FIR filters that can run 192 kHz material direct to the DAC at 192 kHz with no decimation or ASRC in the path or necessary. I don't know if something less than my six-core i7 with 16 Gigs of RAM is suitable but I didn't want to take a chance so I did some overkill. The system is stable and reliable and that's what I need.
Latency? When in the high resolution mode... Oh, about a second
.Best wishes,
Bob
Hello Bob
Nice to see you here
I don't know if that would be easy to operate an Intel-based CPU without a full-blown (ie bloated) OS, but the hardware sure looks sexy: the Intel nuke plateform can run passive, especially with the new ultra low Wattage CPU coming this year, and SSD disks are now a commodity as well.
That said, even the current crop of SHARC DSP could run much longer FIRs if downsampling (decimation) and/or FFT convolution was to be used (the later requires more memory, and also implies more delay, which is a huge drawback in my opinion).
I know more10 (a member here as well) has been playing with downsampling with a SHARC DSP board with great results : JBL Master Reference Monitor - Page 36
Why would you run or need updates on a dedicated PC for media/audio?
Cut off the internet and other file transfers and there's no need for updates and virus scans.
If you only run audio trough the dedicated machine it should be stable for a long time.
Look at it as an industrial PC. You can enhance performance by shutting down all unneeded services. Run two SSD's in raid mirror for safety.
Cut off the internet and other file transfers and there's no need for updates and virus scans.
If you only run audio trough the dedicated machine it should be stable for a long time.
Look at it as an industrial PC. You can enhance performance by shutting down all unneeded services. Run two SSD's in raid mirror for safety.
Hi Pos, I have a question about delay generated by the convolution file. I'm using the USBStreamer from miniDSP for a three-way crossover implemented through JRiver. Details here:
http://www.diyaudio.com/forums/pc-based/256809-setting-up-pc-based-multichannel-dsp-system.html
The speaker is a corner-loaded expanding array:
http://www.diyaudio.com/forums/multi-way/258246-corner-expanding-line-array-kef-q100.html
I'm getting a 20ms delay between the center element and the mid and outer drivers. Now, I know this cannot be due to the physical separation. Other likely explanations:
1. The measurement in Holm using convolution through JRiver is fairly complicated involving three USB soundcards. There could be latency but you would expect it to be the same for all three drivers.
2. There is a delay generated due to the FIR filters that needs to be accounted for.
See the attached picture from RePhase. Is this the delay I need to account for due to the filter for each driver? Is there a way to precisely measure it? Time lock in Holm is giving wonky results.
Thanks for your wonderful software, btw.
http://www.diyaudio.com/forums/pc-based/256809-setting-up-pc-based-multichannel-dsp-system.html
The speaker is a corner-loaded expanding array:
http://www.diyaudio.com/forums/multi-way/258246-corner-expanding-line-array-kef-q100.html
I'm getting a 20ms delay between the center element and the mid and outer drivers. Now, I know this cannot be due to the physical separation. Other likely explanations:
1. The measurement in Holm using convolution through JRiver is fairly complicated involving three USB soundcards. There could be latency but you would expect it to be the same for all three drivers.
2. There is a delay generated due to the FIR filters that needs to be accounted for.
See the attached picture from RePhase. Is this the delay I need to account for due to the filter for each driver? Is there a way to precisely measure it? Time lock in Holm is giving wonky results.
Thanks for your wonderful software, btw.
Attachments
Hello ra7
Nice system!
The delay you need to account for is the one from the impulse itself (the one shown by rePhase, 90.2ms in your case) + the delay of the convolution engine (none if direct convolution is used, and the size of the buffer for FFT convolution, potentially reduced via portioning) + the delay of your soundcard I/O buffers (the same for all your channels I suppose).
Then if you measure with through software that might add some additional delays...
As a side note, Holm will try to adjust the impulse with t=0 on the biggest positive peak, which is not always correct (especially when polarity is reversed of course). You must alter the time offset of your measurement in Holm until you get the phase response you are looking for.
Nice system!
The delay you need to account for is the one from the impulse itself (the one shown by rePhase, 90.2ms in your case) + the delay of the convolution engine (none if direct convolution is used, and the size of the buffer for FFT convolution, potentially reduced via portioning) + the delay of your soundcard I/O buffers (the same for all your channels I suppose).
Then if you measure with through software that might add some additional delays...
As a side note, Holm will try to adjust the impulse with t=0 on the biggest positive peak, which is not always correct (especially when polarity is reversed of course). You must alter the time offset of your measurement in Holm until you get the phase response you are looking for.
Thanks for the reply, Pos!
I'm only concerned about the delay between drivers. As long as the relative phase between drivers is correct, I'm good. I assume that the delay due to the convolution engine and the delay of soundcard I/O buffers is the same.
So, after the impulse is generated, the info box I pasted in the earlier post is the one to pay attention to, right? Is the delay between two drivers due to the filters simply the difference between the values indicated in that box in RePhase?
I understand the time offset in Holm. I usually set it to largest peak (neg or pos). I'll play with it. The problem I'm having is that two consecutive measurements result in different phase sometimes. Other times they are ok. This may be due to the long circuitous path of the signal output during measurement. As a result, there is no way to tell whether the time lock in Holm has worked or not.
I'm only concerned about the delay between drivers. As long as the relative phase between drivers is correct, I'm good. I assume that the delay due to the convolution engine and the delay of soundcard I/O buffers is the same.
So, after the impulse is generated, the info box I pasted in the earlier post is the one to pay attention to, right? Is the delay between two drivers due to the filters simply the difference between the values indicated in that box in RePhase?
I understand the time offset in Holm. I usually set it to largest peak (neg or pos). I'll play with it. The problem I'm having is that two consecutive measurements result in different phase sometimes. Other times they are ok. This may be due to the long circuitous path of the signal output during measurement. As a result, there is no way to tell whether the time lock in Holm has worked or not.
Yes you are correct about the relative delay between drivers.
If the hardware is the same, as well as the impulse length (FFT convolution will imply a different delay for different impulse lengths, even if the peak is at the same distance from the start of the impulse), then the only thing that counts is the delay given by rePhase.
But then, the measurements you have used to generate the rePhase correction also come with their own hidden delay (auto centering in HOLM)...
Normally if all your drivers are phase coherent the delay between drivers should be exactly the distance difference of the emitting surfaces at the listening position.
If you get that right then the sum of the drivers should follow the phase of each driver (ie linear phase if that was your target), and a reversed polarity of one driver should get you a deep null.
I have never used the time lock functionality in HOLM. Dual channel measurement is a better option for this I think (more solid), but even that is not necessary with a little bit of trial and error and the "reverse=null" method.
If the hardware is the same, as well as the impulse length (FFT convolution will imply a different delay for different impulse lengths, even if the peak is at the same distance from the start of the impulse), then the only thing that counts is the delay given by rePhase.
But then, the measurements you have used to generate the rePhase correction also come with their own hidden delay (auto centering in HOLM)...
Normally if all your drivers are phase coherent the delay between drivers should be exactly the distance difference of the emitting surfaces at the listening position.
If you get that right then the sum of the drivers should follow the phase of each driver (ie linear phase if that was your target), and a reversed polarity of one driver should get you a deep null.
I have never used the time lock functionality in HOLM. Dual channel measurement is a better option for this I think (more solid), but even that is not necessary with a little bit of trial and error and the "reverse=null" method.
Hello, I hope this is a simple question that can be answered easily.
Is there a convolution engine that can run as some kind of driver or virtual device or whatever, so that every sound that windows plays (e.g. Firefox, windows media player, foobar, REW, etc) can connect to it? I think Jriver can do something like that, but it seems fairly convoluted (lol pun).
I dunno if that VST or Virtual audio cable is the way to go, since I couldn't tell from their description what they did.
If possible, a (link to a) setup guide would be helpful.
Thanks
Is there a convolution engine that can run as some kind of driver or virtual device or whatever, so that every sound that windows plays (e.g. Firefox, windows media player, foobar, REW, etc) can connect to it? I think Jriver can do something like that, but it seems fairly convoluted (lol pun).
I dunno if that VST or Virtual audio cable is the way to go, since I couldn't tell from their description what they did.
If possible, a (link to a) setup guide would be helpful.
Thanks
Hello,a more and efficient software,freeware.(virtual audio cable is a little capricious and not freeware)
VBcable,just choose the correct sampling frequency.(for me 48KHz)
need to reboot the computer.
VB-Audio Virtual Apps
once installed,select by default the output device.
then,you can play every shoutcast radio or you tube video.,or any sound played in windows.(via VSThost,and VSTconvolver,this is the same Jriver config file )
http://convolver.sourceforge.net/vst.html(for any crossover).
or SIR V1.011 ( for a single stereo impulse)
http://www.knufinke.de/sir/sir1.php
BR.
Last edited: