The APIs are fantastic, and very extensive. And we all know how powerful is REW.
So this is my plead: please support ASIO or UAC 2.0 on the QA403.
I WILL BUY ONE OF EVERY SINGLE PRODUCT YOU MAKE (excluding transducer driver and microvoltmeter).
I WILL PAY DOUBLE FOR A QA403 that supports ASIO or UAC2.0
I’ll explain why: like a great deal of people, I work with devices across a broad range of interfaces: I2S, TDM, USB, Bluetooth, audio over network. From a standard audio API, I can connect to all of these. I can’t go to/from these with your software reliably.
I understand there’s an issue with the scaling, and that autoscaling functionality might be lost, but it is irrelevant. 99% of the time I pick the scale in advance. Anything from a simple GUI app to a USB CDC command line to a USB TMC or USB HID interface would be more than dandy to set out the range.
Really glad to hear this.
Hoping to update my '401 at some point but holding off for ASIO
Alas ARTA has announced EOL as he retires. I wonder if there is an IP in there he would be willing to sell or open source. I always wished there was tighter integration between ARTA and QA as I prefer the ARTA interface but the QA hardware.
You’ll be pleased to learn that I just released a new version of ASIO401 with support for the QA403 and QA402, in addition to the QA401. Enjoy! If you encounter any problems, feel free to file an issue.
Up to you. There are a few improvements here and there that benefit the QA401 as well. Most of these are reliability improvements though, so if you didn’t notice any issues with a previous version, it’s unlikely you’d be able to tell the difference.
If you want to help find bugs though, you can definitely do so by trying out the new version and reporting any issues you find!
I understand that the configuration file is not particularly user-friendly, but honestly it was either that or no driver at all - I just can’t afford to spend the time building a GUI, which I have very little experience with (and would be quite time-consuming regardless). That’s just how it is I’m afraid, at least for now. (Obviously, anyone should feel free to write a GUI themselves if they have the time and skills to do so.)
I understand. Thanx for all you have done. It works well, but of course it’s a bit of a pain to edit text files over hitting UI buttons. I’ve been using it fairly regularly with ARTA and want to try other programs as I have time.
Sounds like QA needs to hire, a JUCE person who can write some sort of cross platform driver with a control panel. That would open up the QA40x to a lot more devices, including mobile and tablets.
I’m assuming your current driver is not in JUCE and thus more challenging to write complete UI?
I’m not sure how JUCE would help - I’m not familiar with it, but it looks like an application framework, not a driver framework.
Honestly, if QA wanted to make their hardware compatible with any app, including mobile and tablets, by far the best way to do that would be to make the hardware appear as a standard USB Audio device. Then everything would just work everywhere out of the box, and ASIO401 would have no reason to exist. The main thing missing would be attenuator/scaling control, but I guess that could be worked around using some USB side channel (that a QA “side app” would use) or something, or perhaps even physical buttons on the device itself.
I’m not a software person either so limited real understanding. But those that use JUCE seem to love it and just think it makes everything easier when dealing with audio devices. I get it’s mostly not a driver framework but on the other hand a lot of drivers are written in it, especially those that have large routing or control panel options. I’ve also seen a lot of MIDI control written in it.
I just mention it as I have seen many people use it with great success to simplify cross platform coding for audio, MIDI and control applications.
I think a configuration panel would be convenient, but it’s not a show stopper. Maybe just reading the configuration file periodically would help, as one could easily write a simple de-coupled UI app.
The problem with being a standard USB audio device is that you are subject to the whims of the OS, and the OS will perform a sample rate conversion on you with you knowing, and the THD will suddenly degrade to something horrendous.
When I first started playing with the E70 Velvet DAC, I ran into that. Here’s a $500 DAC with amazing performance, and most users that are simply plugging it in and using it are getting streams transcoded by Windows, and in the process their $500 DAC is performing like a $70 soundblaster.
it was only when forced into ASIO mode does the DAC deliver its rated specs.
I think Windows Audio is a giant mess. The only way to get bit-exact linked to external hardware is over a custom USB protocol (like the QA40x does) or via ASIO. And as soon as you want something custom from the hardware (like absolute values–a 10V rms waveform reads with a 14.1V peak) ASIO runs out of steam there too. And it gets even messier for cross platform.
You can also use WASAPI Exclusive or WDM-KS. (For example, REW supports WASAPI Exclusive these days.) But yes, I agree it can be quite error-prone for users who may not familiar with these subtleties.
Ideally this is a problem that should be solved on the app side - measurement apps should not support audio APIs that are not designed for bit-perfect operation, or if they do, they should warn the user that unintended conversions may take place. But that’s not the world we live in, it seems.
