About 7 years ago I coded this exe that allows you to DSP speakers, subs, and rooms via ASIO.
(To this day it's still in beta.)
It's written in C# .Net 7 (.Net 4.8 originally.)
https://www.avsforum.com/threads/diying-a-dsp-processor-engine-solution.2626985/post-62400470
I called it "BassThatHz_ASIO_DSP_Processor" for lack of a better name.
Version 1.0.20 download link:
https://drive.google.com/file/d/1VHAYKhUI-yyDgx-Hx8wo1T9i_g7tIE7z/view?usp=share_link
Source Code download link:
https://drive.google.com/file/d/1fcDHaBRTaE4T9-ov3yo5Tpb4277lm87e/view?usp=share_link
Anyway, it has a number of features that I can "try" to briefly summarize here:
-The foundation of it is a highly tweaked and enhanced version of NAudio.
-Designed specifically for Motu AVB hardware interfaces (because that's all I own for testing/use.)
-Uses up to 64 threads (or more), had threading from the ground up (one thread per stream, unlimited streams, or at least 256 or whatever ASIO's limit is).
-Full 64bit floating point DSP, vanishingly low noise (something like -200db snr or whatnot).
-No added processing latency design (stays within the ASIO buffer at least.)
-FFT FIR (currently limited to FFT sized taps, of a power of 2, and uses overlap-save algorithm.)
-Biquad IIR with 0.01hz (or lower) to nyquist (only tested up to 192khz). Processing is a fraction of 1 ms typically.
-PEQ/HS/LS/LR, Hz/Q/Gain/Slope adjustments with advanced biquad overrides.
-Global Master Volume Input and Output; plus created each Stream has its own.
-Polarity flip and nearly unlimited delay.
-Mixer/Channel summation (input only), for those that need to mix inputs or create matrixed outs.
-Smart gain that reduces the gain to zero to avoid clipping when boosting (unlike dumb static gain).
-The limiter is a instant no-delay added brickwall type, which has it's own problems but exceeding the limiter is not one of them, the softness is, it clamps aggressively (instant brickwall within a given frame).
-All of the filters are zero added delay. except for FIR and the delay filter, obviously.
-Up to 256 channels in and another 256 channels out, 512 channels combined. (Motu is limited to 128 though, so I have no way to verify higher.)
-Each can have 100 or so filters each, there is no engine limit, but the stock windows GDI gui might have a pixel scroll limitation.
-A dedicated PC is not required, but strongly recommended for the best experience. It can run on a HTPC if necessary.
-Has a config save/load, optional startup delay, and an app shortcut can be set to auto-lunch on auto-logon. For those that want to make it an appliance. (Google auto-logon and auto-app start.)
-Currently uses .Net 7 but 8 will be out this November and that will be adopted pretty much right away, assuming it's better than 7, which it probably will be. (Faster etc.)
-Windows-based, which everyone already knows how to use / already has.
-No installer or setup msi or LSB is required for the exe. Only system requirement is .Net 7 Runtime for Windows Desktop. (and ASIO drivers with the devices fully powered on before opening the app.)
Typically uses <1% cpu and <100mb of ram.
Unlimited instances are supported.
Unrestricted use for personal-use/scientific or educational purposes. (There is no warranty and not to be used in a commercial setting, and none planned).
New versions are on a hobbyist best-efforts basis. (DSP is not my profession and I have no formal education on the topic, everything is done/learned the hard-way.)
The app is ugly and barebones, and that's intentional. Pretty pixels takes up precious CPU cycles and ram away from the DSP.
It's designed to run as fast as .Net core can (real-time DSP); and the only real bottleneck is the GC/managed-memory subsystem.
The only major things it doesn't have (yet) is DEQ, GEQ, auto-RoomEQ and auto-BEQ, and arbitrary length FIR.
GEQ I'm already working on, and DEQ I'd like to attempt in the upcoming builds... It will probably be my own variant of those as I don't like the historical parameters design constrains of conventional DSP implementations.
For some history/background as to "why":
The reason I created it back in 2016 was because I have a large HT and didn't like the limitations existing HW based solution, such as Behringer DCX and miniDSP, I needed a lot of channels. I didn't want to link a bunch of them together nor pay 5 figure Trinnov amounts to get something comparable.
Prior I was using Adobe Audition but it was too slow, too buggy and eats up too much ram, and it's bloatware and subscription based.
I wanted something free, faster and more reliable, so I made my own. (i.e. You want it custom, you gotta Do It Yourself!)
A lot of channels.
The Marantz is basically just an expensive licensed HDMI switch and DTSX/Atmos to analog XLR decoder for movie-mode.
For serious 2ch music-mode I'm bitperfect ASIO to the Sabre Ref chips in the Motu's.
All speakers and subs are all fully active: 7.29.4 (Fronts are 4-ways, 108db/w/m, 2hz to 40khz +-3db, 14kW x 3. The ULF the subs are 4kW each, the PA subs are another 16kW.)
About ~100kW total burst potential, most of it bass.
That's just the front of the room (there's more...)
Anyhow: ridiculously amounts of power\loudness\overkill is my general-theme.
-I have over 23 years of experience with HT systems.
In 2016 I needed a DSP that could keep up with my addiction! Adobe\miniDSP\Behringer DCX just wasn't cutting it!
That and... I'm a just control freak... I wanted complete control of the DSP! (The rest is history.)
Anyway, maybe you find my Windows/ASIO-based DSP app useful for something too. Have fun!
-BTH out
(To this day it's still in beta.)
It's written in C# .Net 7 (.Net 4.8 originally.)
https://www.avsforum.com/threads/diying-a-dsp-processor-engine-solution.2626985/post-62400470
I called it "BassThatHz_ASIO_DSP_Processor" for lack of a better name.
Version 1.0.20 download link:
https://drive.google.com/file/d/1VHAYKhUI-yyDgx-Hx8wo1T9i_g7tIE7z/view?usp=share_link
Source Code download link:
https://drive.google.com/file/d/1fcDHaBRTaE4T9-ov3yo5Tpb4277lm87e/view?usp=share_link
Anyway, it has a number of features that I can "try" to briefly summarize here:
-The foundation of it is a highly tweaked and enhanced version of NAudio.
-Designed specifically for Motu AVB hardware interfaces (because that's all I own for testing/use.)
-Uses up to 64 threads (or more), had threading from the ground up (one thread per stream, unlimited streams, or at least 256 or whatever ASIO's limit is).
-Full 64bit floating point DSP, vanishingly low noise (something like -200db snr or whatnot).
-No added processing latency design (stays within the ASIO buffer at least.)
-FFT FIR (currently limited to FFT sized taps, of a power of 2, and uses overlap-save algorithm.)
-Biquad IIR with 0.01hz (or lower) to nyquist (only tested up to 192khz). Processing is a fraction of 1 ms typically.
-PEQ/HS/LS/LR, Hz/Q/Gain/Slope adjustments with advanced biquad overrides.
-Global Master Volume Input and Output; plus created each Stream has its own.
-Polarity flip and nearly unlimited delay.
-Mixer/Channel summation (input only), for those that need to mix inputs or create matrixed outs.
-Smart gain that reduces the gain to zero to avoid clipping when boosting (unlike dumb static gain).
-The limiter is a instant no-delay added brickwall type, which has it's own problems but exceeding the limiter is not one of them, the softness is, it clamps aggressively (instant brickwall within a given frame).
-All of the filters are zero added delay. except for FIR and the delay filter, obviously.
-Up to 256 channels in and another 256 channels out, 512 channels combined. (Motu is limited to 128 though, so I have no way to verify higher.)
-Each can have 100 or so filters each, there is no engine limit, but the stock windows GDI gui might have a pixel scroll limitation.
-A dedicated PC is not required, but strongly recommended for the best experience. It can run on a HTPC if necessary.
-Has a config save/load, optional startup delay, and an app shortcut can be set to auto-lunch on auto-logon. For those that want to make it an appliance. (Google auto-logon and auto-app start.)
-Currently uses .Net 7 but 8 will be out this November and that will be adopted pretty much right away, assuming it's better than 7, which it probably will be. (Faster etc.)
-Windows-based, which everyone already knows how to use / already has.
-No installer or setup msi or LSB is required for the exe. Only system requirement is .Net 7 Runtime for Windows Desktop. (and ASIO drivers with the devices fully powered on before opening the app.)
Typically uses <1% cpu and <100mb of ram.
Unlimited instances are supported.
Unrestricted use for personal-use/scientific or educational purposes. (There is no warranty and not to be used in a commercial setting, and none planned).
New versions are on a hobbyist best-efforts basis. (DSP is not my profession and I have no formal education on the topic, everything is done/learned the hard-way.)
The app is ugly and barebones, and that's intentional. Pretty pixels takes up precious CPU cycles and ram away from the DSP.
It's designed to run as fast as .Net core can (real-time DSP); and the only real bottleneck is the GC/managed-memory subsystem.
The only major things it doesn't have (yet) is DEQ, GEQ, auto-RoomEQ and auto-BEQ, and arbitrary length FIR.
GEQ I'm already working on, and DEQ I'd like to attempt in the upcoming builds... It will probably be my own variant of those as I don't like the historical parameters design constrains of conventional DSP implementations.
For some history/background as to "why":
The reason I created it back in 2016 was because I have a large HT and didn't like the limitations existing HW based solution, such as Behringer DCX and miniDSP, I needed a lot of channels. I didn't want to link a bunch of them together nor pay 5 figure Trinnov amounts to get something comparable.
Prior I was using Adobe Audition but it was too slow, too buggy and eats up too much ram, and it's bloatware and subscription based.
I wanted something free, faster and more reliable, so I made my own. (i.e. You want it custom, you gotta Do It Yourself!)
A lot of channels.
The Marantz is basically just an expensive licensed HDMI switch and DTSX/Atmos to analog XLR decoder for movie-mode.
For serious 2ch music-mode I'm bitperfect ASIO to the Sabre Ref chips in the Motu's.
All speakers and subs are all fully active: 7.29.4 (Fronts are 4-ways, 108db/w/m, 2hz to 40khz +-3db, 14kW x 3. The ULF the subs are 4kW each, the PA subs are another 16kW.)
About ~100kW total burst potential, most of it bass.
That's just the front of the room (there's more...)
Anyhow: ridiculously amounts of power\loudness\overkill is my general-theme.
-I have over 23 years of experience with HT systems.
In 2016 I needed a DSP that could keep up with my addiction! Adobe\miniDSP\Behringer DCX just wasn't cutting it!
That and... I'm a just control freak... I wanted complete control of the DSP! (The rest is history.)
Anyway, maybe you find my Windows/ASIO-based DSP app useful for something too. Have fun!
-BTH out
So for example: if you wanted to apply a phase-linear FIR, you could use these RePhase settings comparable to this:
Since FIR is full bandwidth, there is no advantage to cascading multiples, everything can be processed in a single pass. Unlike IIR biquads. (More on that below.)
Or if you only want to adjust only the phase and not touch the amplitude (you get the idea!)
Or say if you wanted to setup a 4-way speaker:
A super-tweeter might look like this
Into a Regular tweeter:
Into a mid-woofer:
Into a sealed bass woofer with a infrasonic natural roll of compensation:
(and a dedicated subwoofer would be similar. etc) You get the idea!
I tried to make the GUI as simple as possible.
Of course you can time-align them and apply EQ as well. It has sample-level precision across any/all threads/streams, ASIO always has that level of precision for a singular device session. (App doesn't support multiple now, or possibly ever. As a result it avoids resampling and multi-device timing related issues.)
I didn't code it because I didn't need the feature, as Motu AVB already synchronizes and sends a large number of channels to multiple avb equipped devices, all under a single ASIO context.
Maxing out my Motu USB 3.0 ASIO driver with 128x128 channels at 96khz it renders 46 filters across 31 discrete channels (which would be a large HT system) in less than 1/10th of 1ms with 52mb of ram (using IIR biquads at least.)
At higher or lower sample rates the performance in C# .Net 7 is about the same.
I optimized the app for mega-core CPU performance for large channel count systems.
An 8 channel system will use 9 cores, a 64 channel system will use 65 cores. (Technically LPU's or threads or .Net Tasks, but let's not nerd-out here. LOL!)
Windows will time-slice the threads across all available cores automatically, you don't have to worry about it if you have more or less cores. The CPU usage will vary according to what you have and how many other apps you have open doing other things.
Obviously a dedicated DSP-PC will only be doing this one thing, where as a HTPC might also be serving videos, which is ungood in regards to real-time responsiveness. ASIO has a fixed time-window in which all channels must be processed fully, the app either renders in time, or the audio is dropped for that audio frame. (Which will be clearly audible hiccups.)
FIR will have a fixed delay inherit in the design, so it's not really great for AV systems, but music-only systems the timing is relativistic so lip synching video pixels isn't a thing. IIR is much closer to real-time but it has phase. Is what it is. Physics is Physics!
With IIR @ 192khz you are talking like a few megaflops of processing per stream per second per thread.
With FIR @ 192khz you are talking like a few gigaflops. It's about 1000x more CPU intensive. (The wattage and cpu heat will go up.)
But I'm not a DSP guru so don't quote me on that. It is substantially more. A biquad is a dozen or so multiplies per sample, and FIR is closer to +1000!
A 64bit DSP isn't twice as good as a 32bit DSP, it's closer to 1 billion times more precise. Each bit is like 2x compounded.
Motu uses 32bit Integers, at least according to NAudio, and nobody who has used those in concert tours or DAWs have complained,
so 64bit is beyond overkill for just about everyone!
Now if you had a 512bit CPU with 512bits of fully populated ram, you could track every atom's vector in the visible-universe. The best computer is whatever runs this reality. (Now that's some precision! 😅)
Since FIR is full bandwidth, there is no advantage to cascading multiples, everything can be processed in a single pass. Unlike IIR biquads. (More on that below.)
Or if you only want to adjust only the phase and not touch the amplitude (you get the idea!)
Or say if you wanted to setup a 4-way speaker:
A super-tweeter might look like this
Into a Regular tweeter:
Into a mid-woofer:
Into a sealed bass woofer with a infrasonic natural roll of compensation:
(and a dedicated subwoofer would be similar. etc) You get the idea!
I tried to make the GUI as simple as possible.
Of course you can time-align them and apply EQ as well. It has sample-level precision across any/all threads/streams, ASIO always has that level of precision for a singular device session. (App doesn't support multiple now, or possibly ever. As a result it avoids resampling and multi-device timing related issues.)
I didn't code it because I didn't need the feature, as Motu AVB already synchronizes and sends a large number of channels to multiple avb equipped devices, all under a single ASIO context.
Maxing out my Motu USB 3.0 ASIO driver with 128x128 channels at 96khz it renders 46 filters across 31 discrete channels (which would be a large HT system) in less than 1/10th of 1ms with 52mb of ram (using IIR biquads at least.)
At higher or lower sample rates the performance in C# .Net 7 is about the same.
I optimized the app for mega-core CPU performance for large channel count systems.
An 8 channel system will use 9 cores, a 64 channel system will use 65 cores. (Technically LPU's or threads or .Net Tasks, but let's not nerd-out here. LOL!)
Windows will time-slice the threads across all available cores automatically, you don't have to worry about it if you have more or less cores. The CPU usage will vary according to what you have and how many other apps you have open doing other things.
Obviously a dedicated DSP-PC will only be doing this one thing, where as a HTPC might also be serving videos, which is ungood in regards to real-time responsiveness. ASIO has a fixed time-window in which all channels must be processed fully, the app either renders in time, or the audio is dropped for that audio frame. (Which will be clearly audible hiccups.)
FIR will have a fixed delay inherit in the design, so it's not really great for AV systems, but music-only systems the timing is relativistic so lip synching video pixels isn't a thing. IIR is much closer to real-time but it has phase. Is what it is. Physics is Physics!
With IIR @ 192khz you are talking like a few megaflops of processing per stream per second per thread.
With FIR @ 192khz you are talking like a few gigaflops. It's about 1000x more CPU intensive. (The wattage and cpu heat will go up.)
But I'm not a DSP guru so don't quote me on that. It is substantially more. A biquad is a dozen or so multiplies per sample, and FIR is closer to +1000!
A 64bit DSP isn't twice as good as a 32bit DSP, it's closer to 1 billion times more precise. Each bit is like 2x compounded.
Motu uses 32bit Integers, at least according to NAudio, and nobody who has used those in concert tours or DAWs have complained,
so 64bit is beyond overkill for just about everyone!
Now if you had a 512bit CPU with 512bits of fully populated ram, you could track every atom's vector in the visible-universe. The best computer is whatever runs this reality. (Now that's some precision! 😅)
Last edited by a moderator:
For my clarification. this will work with a Motu UltraLite mk5 and a three way speaker(?). I understand that the Motu UltraLite mk5 needs to be connected via USB to my PC for the configuration. But once configured, can the Motu be disconnected from my PC and connected via toslink?
Thanks, Mike
Thanks, Mike
It can use any ASIO device (at least in-theory / untested).
That should include ASIO4ALL virtual-adaptations.
Specifically the UltraLite? I'm not entirely sure. However that "likely" has a better chance of working than say: other devices, as "I would hope" it would use the same or a comparable ASIO driver, at least as far as stability / reliability / functionally goes.
So far I've heard reports of the: 8A, 16A, 624, and 24's working properly. All of those are the AVB series. Beyond that I couldn't tell you.
If you already have the HW (or know someone who does), just give it a try. I'd be curious to know...
My understanding is that ASIO is mostly "driver/HW agnostic", however it's entirely possible that some are better written\designed than others, or have edge-case incompatibilities with the typical ASIO standards specification.
As far as disconnecting it? NO!
The Motu onboard DSP doesn't have LPF's, as such it can't to speaker management by itself. (I'm puzzled as to why they'd exclude it in firmware, makes life hard.)
My app doesn't use the Motu WebAPI either, just pure-generic-ASIO.
The working topology is: ASIO Input -> real-time DSP -> ASIO output. (All from a singular generic ASIO device.)
So for example:
Say you have a 16A or 8A or pair of 24's. You'd have either unbalanced or balanced TRS or XLR from an AVR or Pre or Mic going into the HW, it would send that via TB or USB to the DSP-PC / app, and sent to the outs via ASIO on the same connection, and those directly connected to your amplifiers.
In my case for movie-mode:
I have a BD player -> HDMI - Marantz (Atmos decode to XLR) -> Motu 24Ai -> AVB -> 624 -> USB 3 ASIO -> DSP-PC / App -> USB 3 ASIO -> 624 -> AVB -> 24AO -> amps.
Music mode:
HTPC -> ASIO USB 2.0 -> 24Ai -> AVB -> the same
or the shortened version:
HTPC -> ASIO USB 2.0 -> 24Ao -> ASIO Loopback -> DSP app -> ASIO -> balanced headphones etc
Motu has a universal audio driver that can do Windows Audio and ASIO, and loopbacks, from any number of apps (multi-tenant), all channels driven concurrently. So it's really powerful, hence why I ran with that, instead of something else.
Any more simplified/direct than that and you are better off with JRiver which is an audio player / DSP / ASIO all-in-one solution.
My app is more designed for a dedicated external software-based DSP computer (or at the very least a HTPC of the same with ASIO loopback.)
Think of it like a miniDSP, but as an outboard ASIO DSP for the digital connections to it, with far more channels.
Unlike JRiver my app can do 256 channels though, for free. It doesn't have VST though nor a player. It's a pure PCM ASIO-based DSP limited to Windows-only.
Since it is .Net 7 it might be possible to cross-platform it, but not with the existing GUI and NAudio ASIO module without extensive overhauls.
Currently it uses baseline NT WinForms, WinReg ASIO directories and OLE32 WinAPI ASIO driver hooks, adapting that to Apple or Linux is beyond-me!
That should include ASIO4ALL virtual-adaptations.
Specifically the UltraLite? I'm not entirely sure. However that "likely" has a better chance of working than say: other devices, as "I would hope" it would use the same or a comparable ASIO driver, at least as far as stability / reliability / functionally goes.
So far I've heard reports of the: 8A, 16A, 624, and 24's working properly. All of those are the AVB series. Beyond that I couldn't tell you.
If you already have the HW (or know someone who does), just give it a try. I'd be curious to know...
My understanding is that ASIO is mostly "driver/HW agnostic", however it's entirely possible that some are better written\designed than others, or have edge-case incompatibilities with the typical ASIO standards specification.
As far as disconnecting it? NO!
The Motu onboard DSP doesn't have LPF's, as such it can't to speaker management by itself. (I'm puzzled as to why they'd exclude it in firmware, makes life hard.)
My app doesn't use the Motu WebAPI either, just pure-generic-ASIO.
The working topology is: ASIO Input -> real-time DSP -> ASIO output. (All from a singular generic ASIO device.)
So for example:
Say you have a 16A or 8A or pair of 24's. You'd have either unbalanced or balanced TRS or XLR from an AVR or Pre or Mic going into the HW, it would send that via TB or USB to the DSP-PC / app, and sent to the outs via ASIO on the same connection, and those directly connected to your amplifiers.
In my case for movie-mode:
I have a BD player -> HDMI - Marantz (Atmos decode to XLR) -> Motu 24Ai -> AVB -> 624 -> USB 3 ASIO -> DSP-PC / App -> USB 3 ASIO -> 624 -> AVB -> 24AO -> amps.
Music mode:
HTPC -> ASIO USB 2.0 -> 24Ai -> AVB -> the same
or the shortened version:
HTPC -> ASIO USB 2.0 -> 24Ao -> ASIO Loopback -> DSP app -> ASIO -> balanced headphones etc
Motu has a universal audio driver that can do Windows Audio and ASIO, and loopbacks, from any number of apps (multi-tenant), all channels driven concurrently. So it's really powerful, hence why I ran with that, instead of something else.
Any more simplified/direct than that and you are better off with JRiver which is an audio player / DSP / ASIO all-in-one solution.
My app is more designed for a dedicated external software-based DSP computer (or at the very least a HTPC of the same with ASIO loopback.)
Think of it like a miniDSP, but as an outboard ASIO DSP for the digital connections to it, with far more channels.
Unlike JRiver my app can do 256 channels though, for free. It doesn't have VST though nor a player. It's a pure PCM ASIO-based DSP limited to Windows-only.
Since it is .Net 7 it might be possible to cross-platform it, but not with the existing GUI and NAudio ASIO module without extensive overhauls.
Currently it uses baseline NT WinForms, WinReg ASIO directories and OLE32 WinAPI ASIO driver hooks, adapting that to Apple or Linux is beyond-me!
You have to be very careful with that. Each I/O device has a unique ASIO driver, and each ASIO driver assigns unique channel names and channel order. The ASIO SDK provides functions to determine what those names and order are, but only if the programmer utilizes them.
Not quite. For example, some ASIO drivers use 24-bit samples packed as 3 bytes, while some use 24-bit samples within 32-bit words. Some even use floats. Then there is the issue of big-endian/little-endian. The ASIO SDK provides functions to determine sample format, but only if the programmer utilizes them. And it's up to the programmer to handle the samples correctly, according to their format.
Similarly, clock sources are HW-dependent. Any given HW device may have several potential clock sources, and the order in which they appear to the program is not standardized. The ASIO SDK provides functions to find them, of course.
I think that some manufacturers offer Linux ASIO drivers for their products, but I have never used them. I have successfully adapted Windows ASIO programs to MacOS throught Portaudio, but it's not for the faint-of-heart.
I could be wrong but I believe NAudio handles the ASIO drivers part correctly (I hope).
It also handles a number of different bit types, but definitely not all of them.
I don't think DSD is one of them, so that is likely a no-go.
It only has support for these:
Int32LSB
Int16LSB
Int24LSB
Float32LSB
https://github.com/naudio/NAudio/blob/master/NAudio.Asio/AsioAudioAvailableEventArgs.cs
If you have a device that does something else, it won't work without adjustments to that cs file and a recompile of the exe.
Motu uses: Int32LSB, so that one for-sure works. (I haven't tried/tested any of the others as I have no ability to.)
Also the stock NAudio biquad dsp and asio code only uses 32bit floats internally, but I adapted it to do 64bit floats for extra precision. That was one of the enhancements I made, the other major change I made was deinterlacing the ASIO data to a block-style jagged-array for ease of use. NAudio also had a bug with the offsets buffer, which I disabled since my app doesn't depend on that (it has its own), and a few other performance tweaks.
It also handles a number of different bit types, but definitely not all of them.
I don't think DSD is one of them, so that is likely a no-go.
It only has support for these:
Int32LSB
Int16LSB
Int24LSB
Float32LSB
https://github.com/naudio/NAudio/blob/master/NAudio.Asio/AsioAudioAvailableEventArgs.cs
If you have a device that does something else, it won't work without adjustments to that cs file and a recompile of the exe.
Motu uses: Int32LSB, so that one for-sure works. (I haven't tried/tested any of the others as I have no ability to.)
Also the stock NAudio biquad dsp and asio code only uses 32bit floats internally, but I adapted it to do 64bit floats for extra precision. That was one of the enhancements I made, the other major change I made was deinterlacing the ASIO data to a block-style jagged-array for ease of use. NAudio also had a bug with the offsets buffer, which I disabled since my app doesn't depend on that (it has its own), and a few other performance tweaks.
Very, very interesting software.
I will bookmark and test it when time allow for it.
Thank you sharing it. 👍
I will bookmark and test it when time allow for it.
Thank you sharing it. 👍
Not at this time.
All there is is the development notes in the origin thread. I did document every feature added in that regard at least.
That said, the app is fairly simple to use:
1) Set the sample rate and buffer size in the ASIO control panel / HW.
2) Select the input and output devices (has to be the same one).
3) Add streams, selecting the source and destination channel.
4) Add filters to each stream. (All the usual DSP stuff: Levels, Polarity, Delay, XO's, PEQ etc.)
5) Optionally: saving the DSP settings to a file. (If the DSP file is saved in the same path as the exe and auto-load is enabled, it will attempt to find/load it.)
6) Click Start \ Stop DSP
That said, it's still in Beta...
It has only been tested on Motu AVB interfaces, and it's entirely possible there are ASIO devices/modes that won't jive with it, and other generic bugs.
All there is is the development notes in the origin thread. I did document every feature added in that regard at least.
That said, the app is fairly simple to use:
1) Set the sample rate and buffer size in the ASIO control panel / HW.
2) Select the input and output devices (has to be the same one).
3) Add streams, selecting the source and destination channel.
4) Add filters to each stream. (All the usual DSP stuff: Levels, Polarity, Delay, XO's, PEQ etc.)
5) Optionally: saving the DSP settings to a file. (If the DSP file is saved in the same path as the exe and auto-load is enabled, it will attempt to find/load it.)
6) Click Start \ Stop DSP
That said, it's still in Beta...
It has only been tested on Motu AVB interfaces, and it's entirely possible there are ASIO devices/modes that won't jive with it, and other generic bugs.
Have you perhaps tested this with the MOTU Ultralite AVB?
I have one and tested it with other dsp crossover software but it runs out of sync very often, it is very picky about the USB cable used, any standrad printer cable leads to dropouts. So I wonder if your crossover might work with it. Can try it myself offcoarse.
I have one and tested it with other dsp crossover software but it runs out of sync very often, it is very picky about the USB cable used, any standrad printer cable leads to dropouts. So I wonder if your crossover might work with it. Can try it myself offcoarse.
Tried it for a couplke of days but gave up on it due to many fatal error messages and the software crashing.
Other than that, it looks like a flexible solution that lacks only a few minor things.
First a copy/past or ganging option so you don't have to go through the whole crossover/eq/delay setup twice for stereo speakers.
Second, a graphical filter transfer function. But what's to complain at free give away software. Too bad about the crashes though.
Other than that, it looks like a flexible solution that lacks only a few minor things.
First a copy/past or ganging option so you don't have to go through the whole crossover/eq/delay setup twice for stereo speakers.
Second, a graphical filter transfer function. But what's to complain at free give away software. Too bad about the crashes though.
Weird haven't had a single crash with motu 8a and a 24ao. If you look over on avsforum he has updated the dsp a bit since he made this post.