Size and latency
Mikko,
Don't forget that Brutefir needs all of the filters to be the same length and exactly a power of 2. That's why Mark put the t array loop in his code. But you are correct of course that the smaller the array, the lower the latency. Since I'm not interested in watching movies through my filters, I don't care about latency. If I were intending to watch movies, then I'd use smaller filters and I wouldn't care about the sonics quite as much.
-Robert
Mikko,
Don't forget that Brutefir needs all of the filters to be the same length and exactly a power of 2. That's why Mark put the t array loop in his code. But you are correct of course that the smaller the array, the lower the latency. Since I'm not interested in watching movies through my filters, I don't care about latency. If I were intending to watch movies, then I'd use smaller filters and I wouldn't care about the sonics quite as much.
-Robert
Ok,
It may be that I just could locate the data (there were so many pages, literally thousands), propably it was the case as the plots were OK.
I'm going to use the filters with a real DSP (Wavefront 1k) with just 1024 instructions / sample frame available (no DRC). It is possible that BruteFIR can't be used even for the development of the filters because of the IR length requirement (at least without zero padding). My application is nearfield monitors, so the DRC is out of question anyway (at least with FIR, maybe a 512 point nearfield EQ generated from nearfield measured response and inverted to make the frequency response straight, is all I can do, but it's useful only if it can be disabled when the delay can't be stand). On the other hand, the BruteFIR may be useful as the reference point for the quality, so I'm trying it anyway. Maybe it's not that difficult to write a direct form convolver for Linux (using Jack API for an instance), got to see.
-Mikko
It may be that I just could locate the data (there were so many pages, literally thousands), propably it was the case as the plots were OK.
I'm going to use the filters with a real DSP (Wavefront 1k) with just 1024 instructions / sample frame available (no DRC). It is possible that BruteFIR can't be used even for the development of the filters because of the IR length requirement (at least without zero padding). My application is nearfield monitors, so the DRC is out of question anyway (at least with FIR, maybe a 512 point nearfield EQ generated from nearfield measured response and inverted to make the frequency response straight, is all I can do, but it's useful only if it can be disabled when the delay can't be stand). On the other hand, the BruteFIR may be useful as the reference point for the quality, so I'm trying it anyway. Maybe it's not that difficult to write a direct form convolver for Linux (using Jack API for an instance), got to see.
-Mikko
Shorter filters
This morning I took a clue from Mark and created a set of 8192 tap filters but in my case for sample rate of 22050Hz. Listening to internet radio at that rate now sounds very good.
I'm pleased how easy and fast it is to create these filters and they work 1st time every time.
Mikko, both Mark and I are using near-field monitors. Why is drc not applicable there? I can't understand why you are avoiding using a linux/brutefir box for your player. Because of the flexibility and future improvements, this will be more rewarding than implementing specialized hardware dsp.
- Robert
This morning I took a clue from Mark and created a set of 8192 tap filters but in my case for sample rate of 22050Hz. Listening to internet radio at that rate now sounds very good.
I'm pleased how easy and fast it is to create these filters and they work 1st time every time.
Mikko, both Mark and I are using near-field monitors. Why is drc not applicable there? I can't understand why you are avoiding using a linux/brutefir box for your player. Because of the flexibility and future improvements, this will be more rewarding than implementing specialized hardware dsp.
- Robert
DRC now cooking !!!
OK, got some help from Denis Sbragion and I've just made the first 2 successful drc filters for left and right and am listening right now.
I'll be doing quite a few experiments and will spend a few days improving the results.
First results are not so good btw. Brings out the base nicely but veils the mid. But the expectations were low as I did nothing to optimize the settings of either the drc or original recording of the sweep response.
Stay tuned.
-Robert
OK, got some help from Denis Sbragion and I've just made the first 2 successful drc filters for left and right and am listening right now.
I'll be doing quite a few experiments and will spend a few days improving the results.
First results are not so good btw. Brings out the base nicely but veils the mid. But the expectations were low as I did nothing to optimize the settings of either the drc or original recording of the sweep response.
Stay tuned.
-Robert
Robert,
In English the word "monitor" means nothing theses days, I think it used to mean a speaker dedicated to used in music or radio studios to actually monitor the artist performing in the recording process. Anyway, my basic reason why not to use the BruteFIR is that in my system with the MIDI controller keyboard and software synthesizers there is already a minimum of ~5-10 ms Iatency (sound doesn't come from keyboard, it's just a mute controller, PC makes all of the sounds). Also when you record a guitar or vocals you can't actually play anything if the sound comes out too late. Only software alternative for me would (to write) a VST (www.steinberg.net) plugin which does direct convolving (works without FFT and has no limitations to the length of the IR except it's got to be odd). I can do that, no problems. In VST app (Cubase SX) I could enable monitoring for the S/PDIF input for listening to the music from CD or other digital sources. All other Windows sound would end up to woofers only (no problem, except with the TV card). So that's why a small DSP (like Wavefront) would be very handy, but not capable for DRC. If I need DRC I could just boot into Linux and run BruteFIR. Another PC in between the main PC and speakers would be possible if it were very small, fast and quiet.
In English the word "monitor" means nothing theses days, I think it used to mean a speaker dedicated to used in music or radio studios to actually monitor the artist performing in the recording process. Anyway, my basic reason why not to use the BruteFIR is that in my system with the MIDI controller keyboard and software synthesizers there is already a minimum of ~5-10 ms Iatency (sound doesn't come from keyboard, it's just a mute controller, PC makes all of the sounds). Also when you record a guitar or vocals you can't actually play anything if the sound comes out too late. Only software alternative for me would (to write) a VST (www.steinberg.net) plugin which does direct convolving (works without FFT and has no limitations to the length of the IR except it's got to be odd). I can do that, no problems. In VST app (Cubase SX) I could enable monitoring for the S/PDIF input for listening to the music from CD or other digital sources. All other Windows sound would end up to woofers only (no problem, except with the TV card). So that's why a small DSP (like Wavefront) would be very handy, but not capable for DRC. If I need DRC I could just boot into Linux and run BruteFIR. Another PC in between the main PC and speakers would be possible if it were very small, fast and quiet.
MWP said:
I'd say that's one of the big questions surrounding speakers in general, and there probably is no single/easy answer.
I've generally been in the 'shallower slope' camp, thinking that a more gradual transition between drivers would avoid discontinuities (both spatial and tonal) when bridging from one driver to the next. This was somewhat supported when I had a chance to tour the Dunlavy facility some time ago, and John D. indicated that they settled on 'about 3rd order slopes' for their digital prototype based solely on listening.
However, I'm beginning to question that position somewhat. Reducing the overlap bewteen drivers greatly reduces lobing, which generally is a good thing. Also, modern hard-cone drivers are more easily handled by steep slopes to keep all fundamentals out of the break-up region. The practical problem with steep slopes is that you get worse pre-echo if you go linear phase, and getting the right cancellation off-axis is difficult at best. In contrast to the Dunlavy anectode above, this viewpoint has been boosted by the preliminary reports of the new NHT digital active speaker that uses DEQX technology and appears to use brickwall filters, and is reported to sound excellent.
I've been wandering around quite a bit on my speaker plans recently mostly looking at high-efficiency coax arrangements as they sidestep much of the above questions by inherently eliminating lobing if done properly. I've realized that this is a longer-term project and am now moving forward with a 'conventional' 3.5 or 4 way using drivers I already have on hand. One of the main reasons is to finally have a 'testbed' to experiment with exactly some of these questions - given that we can DRC or otherwise EQ two systems to be basically 'the same' on axis, how does a LR4 setup differ from a brickwall or from a subtractive-delay?
If you use a properly dimensioned waveguide in front of the tweeter there shouldn't be problems with steep crossing. However, there are applications in which you cant stand any processing delay. Also you don't have to use FIR to get steep linear-phase response, you can also use IIR filters, but they are much more difficult to design. One example of phase-linear IIR filter is the processing method where you first reverse the data, process it, then reverse and process it again. If you find a way how to do this processing in short fragments of audio you've made a linear-phase IIR filter.
One problem with speakers is that in reality they themself aren't linear-phase. So you would rather try correcting the phase than keep it as it comes out.
One problem with speakers is that in reality they themself aren't linear-phase. So you would rather try correcting the phase than keep it as it comes out.
Phase correction
Does software exist to correct phase? My understanding (though I have no experience with BruteFIR and limited experience with DRC) is that the combination of DRC and BruteFIR can be used to create high-order, brick-wall type filters that are linear phase, and also to correct frequency response of system, driver, box and room (to some degree) at the listening position. I believe DRC also corrects the impulse response. But, if all of this is done in linear phase FIR filters, it can't correct phase, can it? Wouldn't phase-correcting software need to be minimum phase, rather than linear phase?
Thanks for enlightening the newbie.
brad
Does software exist to correct phase? My understanding (though I have no experience with BruteFIR and limited experience with DRC) is that the combination of DRC and BruteFIR can be used to create high-order, brick-wall type filters that are linear phase, and also to correct frequency response of system, driver, box and room (to some degree) at the listening position. I believe DRC also corrects the impulse response. But, if all of this is done in linear phase FIR filters, it can't correct phase, can it? Wouldn't phase-correcting software need to be minimum phase, rather than linear phase?
Thanks for enlightening the newbie.
brad
Also, what are people using for soundcards under Linux? I have an RME Hammerfall HDSP 9632 with an analog expansion card. I think it's only good for up to 10 analog outs (with an additional analog expansion card). Are people using RME's with ADAT outs? If so, what are you using for DACs? Is there some reasonably affordable (<$2k) way to get about 16 channels of high-quality digital out of a Linux box and through external DACs? I'd really like to use the Lynx AES 16, but, no ALSA drivers...
TIA.
brad
TIA.
brad
dc said:
FIR filters are directly analagous to an impulse response, and so can have arbitrary phase characteristics - you can pretty much make them have whatever phase behavior you want. I think the term 'linear phase' is often used as a generic term for 'filters that cause the overall system to have good phase behavior'. In truth you will probably rarely use a purely linear phase filter, but rather filters that have a minimum phase component and a linear phase component.
Put another way, the goal is to have the overall acoustic output of the system as close to linear phase as possible - the phase characteristics of the filter are chosen to meet this goal.
dc said:
I've started wondering this myself, as Mac OSX is looking increasingly attractive to me. I would say 'there is no reason it shouldn't work' provided you use Jack as the output layer as there is already a version that works on CoreAudio. Whether anyone has done it is another question.
BTW There are OSS drivers for the LynxTwo cards, but I'm not clear whether they will work with the AES-16 - 4Front said that nobody had tried it when I asked. Jack does have an OSS output driver, so that may actually be an option under Linux.
Nothing solid to report, but I have been looking into porting BruteFIR to OS X. I don't know the first thing about C programming, but I bought a couple of books and I've looked through some documentation on CoreAudio.
I've looked through the BruteFIR source code a bit, too. It looks like it's largely straightforward C code, as far as my untrained eye can tell. I think there's a small issue with the "endianness" of Linux vs. Mac OS X (I think PC's are Little Endian and Mac's are Big Endian). But it looks like BruteFIR provides for both. I tried compiling various of the BruteFIR source files with the Mac OS X Developer Tools and got very few errors. I'm quite sure that someone who knew even the first thing about C programming on the Mac could port it in a day or two. As it stands, it may take me a couple of months.
Another brilliant aspect of OS X is Audio Units. It's basically VST plug-ins built into the OS. You can chain together the Audio Units you want in any order. My aim would be to convert BruteFIR to one or more Audio Units and make GUIs.
The more I look at this, the more convinced I am that a G5 and OS X is the way to go for audio processing. The G5 is screamingly fast , processing 180 simultaneous reverbs, compared to 42 simultaneous reverbs for a 3.4Ghz P4 . On top of that, the OS is built from the ground up for audio -- low latency, Audio Units, N-channel support... The list goes on.
Also note that Lynx Studio has released a 16-channel DAC, the Aurora 16 , to mate with the AES-16 or LynxTwo. It's incredibly sexy, but not cheap (street price seems to be about $2995). 117 db dynamic range and THD+N of 0.00045%.
I've looked through the BruteFIR source code a bit, too. It looks like it's largely straightforward C code, as far as my untrained eye can tell. I think there's a small issue with the "endianness" of Linux vs. Mac OS X (I think PC's are Little Endian and Mac's are Big Endian). But it looks like BruteFIR provides for both. I tried compiling various of the BruteFIR source files with the Mac OS X Developer Tools and got very few errors. I'm quite sure that someone who knew even the first thing about C programming on the Mac could port it in a day or two. As it stands, it may take me a couple of months.
Another brilliant aspect of OS X is Audio Units. It's basically VST plug-ins built into the OS. You can chain together the Audio Units you want in any order. My aim would be to convert BruteFIR to one or more Audio Units and make GUIs.
The more I look at this, the more convinced I am that a G5 and OS X is the way to go for audio processing. The G5 is screamingly fast , processing 180 simultaneous reverbs, compared to 42 simultaneous reverbs for a 3.4Ghz P4 . On top of that, the OS is built from the ground up for audio -- low latency, Audio Units, N-channel support... The list goes on.
Also note that Lynx Studio has released a 16-channel DAC, the Aurora 16 , to mate with the AES-16 or LynxTwo. It's incredibly sexy, but not cheap (street price seems to be about $2995). 117 db dynamic range and THD+N of 0.00045%.
Windows folks might want to have a look at a new Foobar crossover plugin, hosted at
http://sourceforge.net/projects/xover
It's basically functionally equivalent to AsioXO, but works as a DSP plugin to Foobar rather than as a big monolithic player. It also does 4 way rather than just 3 way, and source is apparently checked into the sourceforge CVS repository. It uses an IIR filter package, so is constrained to the normal analog-style xovers.
I've done a quick trial using Asio to my Emu 1820M, and it seems to work pretty well. The ability to use it in conjunction with the other Foobar plugins is nice - you can use convolver for DRC, or the graphical eq, and it should work with SSRC as well.
I have a Unity horn prototype that I just got running, and with the xover and graphical eq I actually got it sounding pretty decent pretty quickly just tweaking by ear.
I did have a hard lockup when playing back from a CD (using cdda), but I don't yet know whether that was even related to foobar at all. Still, it might warrant some caution.
http://sourceforge.net/projects/xover
It's basically functionally equivalent to AsioXO, but works as a DSP plugin to Foobar rather than as a big monolithic player. It also does 4 way rather than just 3 way, and source is apparently checked into the sourceforge CVS repository. It uses an IIR filter package, so is constrained to the normal analog-style xovers.
I've done a quick trial using Asio to my Emu 1820M, and it seems to work pretty well. The ability to use it in conjunction with the other Foobar plugins is nice - you can use convolver for DRC, or the graphical eq, and it should work with SSRC as well.
I have a Unity horn prototype that I just got running, and with the xover and graphical eq I actually got it sounding pretty decent pretty quickly just tweaking by ear.
I did have a hard lockup when playing back from a CD (using cdda), but I don't yet know whether that was even related to foobar at all. Still, it might warrant some caution.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.