The errors are messages from the previous attempt to start the engine. Some devices are troublesome, as you also can see earlier in this thread, but so far they also were without SXQ, and used in the same mode. I suspect that in the case of your M-Audio device there may be an issue with the WASAPI-ASIO bridge. Normally WASAPI or ASIO is the lowest level interface, and you may have used the ASIO interface before. Actually I am considering to add a native ASIO interface to SXQ. I have no interests in the Creative enterprise, but their adapters always work so far, sound great and have good PnP drivers, so I tend to endorse them.
The idea was always to once set up the desired configuration and then play with the filters to get the best results. If you want to experiment a lot with different setups that will be less convenient than simply changing a filter.
Unfortunately I am not about to invest in a huge number of different OS versions and sound adapters, so your feedback is valuable. SXQ uses one 3rd party product which is used only to attain device abstraction.
Getting the SXQ PLL to work reliably and within spec took the greater bit of the entire effort, but it now gives an uninterrupted stream of audio data to the driver. If you want to know what the PLL failing sounds like you could check the synchronization box and wait for an hour or so until underruns/overruns occur. I suppose now that if there are problems with only SXQ and some driver it may well be due to buffer sizes. The buffers are not particularly small, but if problems ensue I may opt for configurable buffer sizes. But hopefully not.
The idea was always to once set up the desired configuration and then play with the filters to get the best results. If you want to experiment a lot with different setups that will be less convenient than simply changing a filter.
Unfortunately I am not about to invest in a huge number of different OS versions and sound adapters, so your feedback is valuable. SXQ uses one 3rd party product which is used only to attain device abstraction.
Getting the SXQ PLL to work reliably and within spec took the greater bit of the entire effort, but it now gives an uninterrupted stream of audio data to the driver. If you want to know what the PLL failing sounds like you could check the synchronization box and wait for an hour or so until underruns/overruns occur. I suppose now that if there are problems with only SXQ and some driver it may well be due to buffer sizes. The buffers are not particularly small, but if problems ensue I may opt for configurable buffer sizes. But hopefully not.
Thanks for the clarification on the errors I was seeing during testing when I was switching the platform configuration around quite a bit. I was trying to explore what was possible (what setting gave clean audio) and what did not do that.
I'm not trying to lend support or endorse any manufacturer's products, but I think people will want to see what has worked for other. If you included native ASIO support that would be great.
Now that I know what I can do with SXQ and my onboard audio I am planning to use SXQ to implement the crossover for a small 3-way system that I built a couple years back and have not used for awhile. I'm just waiting until some new mini-plug to RCA cables arrive. I'm very much looking forward to some extended listening.
SXQ on Windows 10, Linux?
Could someone pls confirm if SXQ runs well on Windows 10?
Have been porting to Linux lately, but its not yet stable.
I have some issues configuring and adapting all the ALSA/Pulseaudio buggeration.
Very hard to figure out what state the audio system is in, what gets changed automatically when, by what..
Module snd-aloop seems to be the way, but there are synchronization issues.
Looks like I may have to create my own version of snd-aloop.
Dont want LADSPA, as it seems to confine to a single player, anyway not usable as a default device.
Still investigating.. more later..
Could someone pls confirm if SXQ runs well on Windows 10?
Have been porting to Linux lately, but its not yet stable.
I have some issues configuring and adapting all the ALSA/Pulseaudio buggeration.
Very hard to figure out what state the audio system is in, what gets changed automatically when, by what..
Module snd-aloop seems to be the way, but there are synchronization issues.
Looks like I may have to create my own version of snd-aloop.
Dont want LADSPA, as it seems to confine to a single player, anyway not usable as a default device.
Still investigating.. more later..
Hello Deodato,
I didn't test Win 10 but on the same machine and same USB soundcard, Win7 vs Ubuntu, the sound is much much more stable under Ubuntu. In fact, i did not heard a single pop/crack sound under Ubuntu.
Also under Win7, SXQ had a harsch sound, i think it has something to do with Windows audio drivers. The problem was more audible between mids and tweeter. Changing soundcard from Asus to an older Creative helped but the harsch effect was still present in a small quantity.
I use VLC for audio playback and Kodi for movies. Sound device is set to Loopback device and all is OK.
I miss the SXQ graphs showing response of applied filters.
I didn't test Win 10 but on the same machine and same USB soundcard, Win7 vs Ubuntu, the sound is much much more stable under Ubuntu. In fact, i did not heard a single pop/crack sound under Ubuntu.
Also under Win7, SXQ had a harsch sound, i think it has something to do with Windows audio drivers. The problem was more audible between mids and tweeter. Changing soundcard from Asus to an older Creative helped but the harsch effect was still present in a small quantity.
I use VLC for audio playback and Kodi for movies. Sound device is set to Loopback device and all is OK.
I miss the SXQ graphs showing response of applied filters.
I've developed some LADSPA plugins recently and have been invoking them from ecasound. IMO ecasound is great - the routing capabilities are excellent and the user interface is simple for crossover work. The one problem is that it must be given the sample rate of the audio stream as part of the configuration files. If you port SXQ top Linux or are in the process of building something like that and can make the sample rate auto-sync to the data stream, I think you will have something that people are very interested in.
Here is a link to my LADSPA thread, and where the plugins can be downloaded:
http://www.diyaudio.com/forums/pc-based/274331-ladspa-plugin-programming-linux-audio-crossovers.html
Download in my signature, or here:
ACD-plugins
It's all open source, so you are welcome to use/adapt the code if you would like as long as you reference the original work by me.
I'd be happy to chat with you about it if you want to drop me a line. I also have some experience with ALSA loopback (snd-aloop) if you have questions about that. IMO trying to implement LADSPA via ALSA is only possible for laughably simplistic crossovers (just one HP and one LP requires many, many lines of ALSA config code!) but if you want to take a look at that, there is a thread in the Twisted Pear forum where people are trying it:
http://www.diyaudio.com/forums/twisted-pear/277564-ladspa-filters-digital-crossovers-bbb.html
Last edited:
Charlie, I would like to do it with snd-aloop, but I need more understanding of its clocking mechanism. On Windows, a VAC is much like any other audio device, it has its own clock that is used to push the capture data and to pull the render data. That has its drawbacks, when interconnecting two devices you have to sync the streams, but you know what you have.
snd-aloop apparently adapts the clock rate to a real device, which is great, but it seems the rate is not stable ie changing abruptly. I wonder if I can get it to behave like an ordinary device too.
snd-aloop apparently adapts the clock rate to a real device, which is great, but it seems the rate is not stable ie changing abruptly. I wonder if I can get it to behave like an ordinary device too.
First my compliments for all your effort!
Also big big compliments that you're starting to port the whole thing to Linux.
For some bizarre reason the amount of decent DSP programs is very slim or people pay a ridiculous amount of $$$.
I have years of experience in electronics/physics and acoustics, but unfortunately I'm not a programmer (except for some ucontroller stuff).
At this moment I do use 'Equaliser APO' for windows, but I really like the idea of a cross-platform solution.
Especially because with Linux it's not to difficult to (finally) build a Kodi media center with decent active filtering. (Yes, I know, there is a Kodi add-on on its way, but the development is going slow and completely backwards).
Best would be even that it would work on a RaspPi off course.
My online 2 cents are to make the user interface just a little bit more user friendly (fancy if you will).
I was first a bit skeptical about running it via a web browser. On the other hand, I can imagine that it saves a lot of time building specifics programs ('apps') for each OS.
Maybe it would be handy to let the user change the port if needed or make an auto select option or something?
Keep the good work up!
(ps, yes i completely agree you with the IIR/FIR debate, but it's best not to go into that again
)
Also big big compliments that you're starting to port the whole thing to Linux.
For some bizarre reason the amount of decent DSP programs is very slim or people pay a ridiculous amount of $$$.
I have years of experience in electronics/physics and acoustics, but unfortunately I'm not a programmer (except for some ucontroller stuff).
At this moment I do use 'Equaliser APO' for windows, but I really like the idea of a cross-platform solution.
Especially because with Linux it's not to difficult to (finally) build a Kodi media center with decent active filtering. (Yes, I know, there is a Kodi add-on on its way, but the development is going slow and completely backwards).
Best would be even that it would work on a RaspPi off course.
My online 2 cents are to make the user interface just a little bit more user friendly (fancy if you will).
I was first a bit skeptical about running it via a web browser. On the other hand, I can imagine that it saves a lot of time building specifics programs ('apps') for each OS.
Maybe it would be handy to let the user change the port if needed or make an auto select option or something?
Keep the good work up!
(ps, yes i completely agree you with the IIR/FIR debate, but it's best not to go into that again
)
Last edited:
This looks clean, and refreshing. The web-based GUI opens the door to future portability to some extend (Windows -> Linux -> Android TV-box -> Kodi).
I read the comments about FIR filters. Most people don't know about FIR filters. They fear that FIR filters always generate pre-ringing and ringing in time domain. That's not true.
One can design a 4410-tap FIR filter, lowpass, -6 dB at 1 kHz, featuring a -18 dB/oct slope (pseudo 3rd-order) exhibiting almost no pre-ringing and ringing, that's phase linear (equivalent to a delay of 100 ms).
Once this is done, one can design a 4410-tap FIR filter, highpass, -6 dB at 1 kHz, featuring a +18 dB/oct slope (pseudo 3rd-order) that's also phase linear, and fully complementary to the above lowpass, hence also equivalent to a delay of 100 ms.
If you want even less ringing, you can design FIR filters emulating fractional orders, like a pseudo 2.5 order instead of the pseudo 3.0 order that's above.
Relying on low pseudo-orders FIR filters is the key.
Consider a 3 inch medium driver in a small closed enclosure, say 1 liter. In the low frequencies, this is a natural 2nd order highpass, with a Fc (say 150 Hz) and a Q (say 1.2).
For the bass, say you rely on a 12 inch woofer, that you want to cut above 600 Hz, for avoiding trouble like needing to deal with sharp uncontrolled resonances above 2 kHz and possibly, a narrow and uncontrolled directivity above 2 kHz.
Let's design a woofer / medium crossover operating at 600 Hz. You want to avoid massive bass content rushing into your fragile medium driver. Therefore you want your medium driver, to become highpass filtered below 600 Hz.
In the 600 Hz to 150 Hz region, you can op for a pseudo 2.5-order highpass filtering. Below 150 Hz, due to the fact that the natural response of the medium driver is already a 2nd-order highpass, you can ask the FIR filter to emulate a 0.5-order highpass.
That's all you require.
What FIR filter length should you opt for ?
Above, I suggested a 4410-tap filter. Why ?
Because such FIR filter will exhibit a quite narrow and advantageous frequency resolution of 10 Hz. Which means that such FIR filter, if you ask him properly, is able to tailor the amplitude and phase response, in 10 Hz increments. Thanks to such precision, the amplitude and phase of the filter at 400 Hz, can be significantly different from the amplitude and phase of the filter at 390 Hz, or 410 Hz.
Now you realize the precision that can be attained, what's regard the filtering.
Such high degree of precision doesn't come at the expense of pre-ringing or ringing.
Most people appear to ignore this. Most people think that a 4410-tap FIR filter "must" be designed for emulating a very high-order filter, very selective filter, causing pre-ringing and ringing.
While here, our preoccupation is to generate a pseudo 2.5-order highpass acoustic transfer function, -6 dB at 600 Hz and low Q for the medium driver, and symmetrically, a complementary lowpass acoustic transfer function, - 6dB at 600 Hz and low Q for the bass driver, not far away from a Bessel 2nd-order, and perfectly phase linear (better than Bessel, thus).
Okay, if you need to straighten the deep bass response from 20 Hz to 200 Hz, addressing the deep bass cutoff of the woofer (aka Linkwitz Transform), and addressing room resonances, you shall add a few IIR Biquad filters, say 4 of them, in a 32-bit or possibly in 64-bit resolution.
So, how do you calculate the FIR filters ?
Actually, this is easy, fast, and less prone to trial-and-error than IIR filters.
1. You measure and store the bare amplitude and phase responses of your drivers, using a FFT-4096. Please note, the value of 4096 is not far away from the FIR-filter length of 4410 we've been talking above. For grabbing the phase, you need a dual-channel FFT analyzer : channel#1 is the reference (pink noise voltage feeding the speaker driver) and channel#2 is the measure (voltage coming from the mike that's facing the speaker driver).
2. You define your acoustic target curve, same format as above (amplitude and phase). If you are dealing with a medium driver, you will specify a highpass -6 dB at 600 Hz, pseudo 2.5 order, low Q, and phase linear (equal to a 100 ms delay). If you are dealing with a woofer, you will specify a lowpass -6 dB at 600 Hz, pseudo 2.5 order, low Q, and phase linear (equal to a 100 ms delay). In doing so, you need to satisfy one criterion : the highpass acoustic target must complement the lowpass acoustic target. In other words, their sum need to equal unity, in amplitude and in phase. Addressing this, you will discover that you don't have many choices what's regarding the "Q" factor. Actually, the "Q" factor is not a good paradigm here. You better take a piece of paper, and sketch the symmetry that's required, which in turn defines the lowpass amplitude diagram that you require, for ensuring that there exists a corresponding highpass diagram complementing it. You don't find this in textbooks.
3. You compare the bare curves with the target curves, in amplitude and in phase, same format as above. This is indeed the equalization you require.
4. But wait a minute, such required equalization appears in the form of a 4096-FFT. Thus, applying an inverse FFT to it, will show the convolver implementing it. And here, look, such convolution is the 4096-tap FIR filter that you require. It is that easy !
Job done. Agree ?
In the web-based GUI, it would be very helpful to :
1. Implement a dual-channel 4096-FFT analyzer exploiting the two line inputs of the 5.1 or 7.1 audio card, for displaying and storing the amplitude and the phase of the bare speaker drivers.
2. For the sake of reliability, apply some solid averaging inside the above 4096-FFT analyzer.
2. Allow the user to specify complementary target filters (highpass and lowpass pairs) having a Fc (-6 dB) between 120 Hz and 12 kHz, and pseudo orders between 2.5 to 8.5.
3. Allow the user to load and run the 4096-tap FIR filters (choosing between the lowpass and the highpass).
4. For the sake of universality, like in case of specifying a medium driver target filter, allow the target filter to consist on a low frequency highpass (to be enabled or disabled), followed by a high frequency lowpass (to be enabled or disabled).
I can deliver code snippets to help you, just in case.
Attached is a piece of paper showing the symmetry that's required for ensuring that there exist a highpass, complementary to the lowpass being specified.
By the way, I'm a bit lost when you describe the high quality PLL that's implemented using software. Can't you persuade the 5.1 or 7.1 audio DACs to be driven as a high quality async audio sink, possibly over USB ?
Regards,
Steph
Attachments
NOTCH filter is always infinitely deep, it's made to remove a given frequency, the Q parameter modifies the width.
To remove frequency by a given level, you may use the PEAK EQ, by -5dB and adjust the Q parameter to get the wanted width.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.