Perhaps the next model will use standard USB audio class protocol for even more flexible useThat would allow the advanced software accompanying the device to be used (i.e. sold) separately for any USB-audio device.
Hi phofman,
I don't think a standard audio class is the panacea you think it is. The custom bit-exact interface of the QA401 means we control the bit stream precisely. No unexpected sample rate conversions, no unexpected volume changes by 3rd party apps, no worries that a 3rd party app won't turn on "bass boost" without you knowing. Measuring audio while listening to music or watching a video is glitchless because Windows doesn't know anything about the QA401 audio stream. And that's good.
I measure a lot of DACs and it's not uncommon at all to plug in a "driverless" DAC and measure performance far below what is claimed. And then you go digging around for 20 minutes and get all the Windows settings just so right and and THEN you can measure spec'd performance. But that also means that 99% of users aren't seeing spec'd performance of the DAC they bought because they aren't taking the time to correctly set everything. And I suspect they aren't double checking those settings before each session either.
What do you think Windows Audio does when the DAC is set to 48K and you play a file that was recorded at 192K? Or vice versa? Answer: Nobody knows with certainty. It depends on a lot of settings, and each of those settings can be tweaked by any app or an OS update.
I think USB audio is great for consumer quality. But for pro audio, where you need to know with 100% certainty that the streams are bit-exact, it's too dicey IMO. ASIO, however, gets you a lot of the way there. But it's simply a wrapper around a manufacturer's proprietary interface.
The compatibility issue was really important to MSFT 15 years ago (I worked there for 9 years), but it has waned as VMs have emerged. I have to run Xilinx ISE tools in a VM, because their tools no longer run on Win10. It's a reasonable way to bring old hardware and software into modern times. Not perfect, of course. The QA400 started shipping in late 2012 and a bulk of the development occurred in 2011 and 2012. The effort to pull that entire code base up to 2020 would be enormous--almost a complete re-write since none of the tools used to create the product are supported any longer. The good news is that a VM gives you decades of guaranteed compatibility. And they are free. And they work really, really well. Using a VM, you can be sure you can run a QA400 in 2050 if needed.
Matt, I am sorry for not realizing that such obvious functionality as a bit-perfect access to a soundcard is not readily available to windows users. In linux any audio app using the alsa subsystem can write either directly to the soundcard DMA buffer (PCI/PCIe), or to an extra buffer in between for USB-audio (because the final DMA buffer includes data related to all devices hooked to the USB controller, double buffering is used).
On the other hand, USB-audio is a bit-perfect USB protocol, between the driver and the USB device. Technically nothing prevents from using ASIO instead of the windows sound subsystem for connecting the applications. And the device will work right away in any other OS, no extra work for the vendor and the user.
On the other hand, USB-audio is a bit-perfect USB protocol, between the driver and the USB device. Technically nothing prevents from using ASIO instead of the windows sound subsystem for connecting the applications. And the device will work right away in any other OS, no extra work for the vendor and the user.
What happens on Linux when you are watching a movie with 44.1K audio track, the DAC is running at 44.1, and the system needs to play a mail arrival notification that was recorded at 48K? My guess is the driver re-samples the 48K down to 44.1k and mixes it with the 44.1k stream. And with that action, it's no longer bit-exact, right?
What happens on linux if the driver is expecting 32-bit floats and an app submits 24-bit fixed? No longer bit exact, right?
It's the same problem on windows.
The USB can only be opened at a single rate. If Skype opens it at 48K, and keeps it open to play ring tones, and then you open a 192K audio player, what will happen? Right now I see my DAC is set to 44.1K (front panel indicator). I didn't do anything to select that, it's just what the system picked. I play a 192K wav file, and it switches to 48K and then re-samples 192 down to 48. Ugh. But I went deep enough in the menus and forced 192, then it would respect that for the 192K playback. But then 44.1 would be upsampled. And since I'd guess most everyone has a music library or 44.1, 48 and 192, they are listening to non-bit exact audio all the time, they just don't know it.
These are not easy problems to solve unless you are constantly asking the user if they want to change sample rates. From a usability perspective, the best thing to do is re-sample in the background always.
On Windows you can force "exclusive" mode and effectively lock a sample rate (which is what you need to do to measure a DAC). But if you do that, then you won't hear "new mail" sound while watching a movie.
Oh I see. So that I should make a bootable USB stick of WIN7.
Then from my Dell LapTop (DLT) which runs WIN10, stick the
WIN7 USBStick into it, reboot the DLT and use QA400,
or at least see if it works.
The issue I had with Win10 and creating the VM interface was that
inspite of running in the VM, it still had to interface through Win10
which didn't work.
I'll try.
Cheers,
Uhm, this is why there "exclusive access". If a program connects to a device with exclusive access, no other access is possible. Easy peasy way to avoid the mixing issues you mentioned.
BOOTable WIN7 USB Stick
So now I have my bootable USB stick in NTFS format.
I also have a copy of the ISO WIN7 image, not yet installed
on USB Stick.
Question, from the information I've viewed after Googling,
it seems most of these enable you to boot from the USB,
however, they all seem to want you to install the WIN7
application to the harddrive on the new computer. ETC, etc.
But from what you mention, shouldn't it boot the WIN7 on
the USB drive into the memory on the computer and run that way?
Also, any one know if 2GB (1.8GB) I assume will run WIN7?
NO 2 GB IS NOT ENOUGH
That means more moving around of files.
WhoopTiDo.
Maybe 16 GB is enough?
Cheers,
So now I have my bootable USB stick in NTFS format.
I also have a copy of the ISO WIN7 image, not yet installed
on USB Stick.
Question, from the information I've viewed after Googling,
it seems most of these enable you to boot from the USB,
however, they all seem to want you to install the WIN7
application to the harddrive on the new computer. ETC, etc.
But from what you mention, shouldn't it boot the WIN7 on
the USB drive into the memory on the computer and run that way?
Also, any one know if 2GB (1.8GB) I assume will run WIN7?
NO 2 GB IS NOT ENOUGH
That means more moving around of files.
WhoopTiDo.
Maybe 16 GB is enough?
Cheers,
Last edited:
Yes, I mentioned exclusive mode in the last paragraph. But again, it's not guarantee. I just enabled exclusive mode on my DAC. The DAC is sitting at 48K sample rate. I asked Foobar, Groove and Audigy to play a 192K track. The DAC stayed at 48. Windows transcoded rather than change the sample rate. Go figure. I set the sample rate to 192K manually, it still doesn't change. Then I close all the audio apps and change it and then ask Windows to play a test tone--then it takes. And then with the DAC at 192, I play a 48K on Foobar and it plays at...192.
If you think Windows isn't transcoding your DAC listening sessions, you are probably wrong.
As I said at the beginning, it's not impossible to solve. Cakewalk Sonar aggressively manages sample rates when you ask it too. So it can be done. But it's a lot of hoops. And you are never too sure. Definitely not suitable for a factory environment.
I will describe the linux ecosystem. Windows uses hardware in exactly same way, just the terminology may be different.
Let's assume a USB-audio soundcard is connected to the PC. The USB-core driver (the driver talking to the USB controller) enumerates the device, which reports itself as USB-audio. The kernel loads device- (or protocol-) specific USB driver, snd-usb-audio in this case. This USB-protocol-specific driver creates an audio device for userspace on one side, and uses USB-core driver API to communicate with the device on the other side.
Now a simplex (DAC)/duplex (DAC/ADC) audio device (in linux a special type of file) is ready for userspace to use. Capabilities of this device are exactly those of the actual hardware. Data written by userspace are directly copied to the USB-core driver buffer which is the DMA area of the USB controller. Of course the audio samples are wrapped with USB-frame encapsulation. In case of non-USB soundcard this buffer is directly the DMA area in RAM serviced by the soundcard.
Clearly there is no resampling/mixing streams/changing sample formats at this stage. Whatever you copy to the buffer will be delivered to the hardware, as it should be for direct access. This device is named hw:ID in the linux sound layer called alsa, where ID is numerical ID or string name of the soundcard. Any application which opens this device talks to the soundcard directly and has exclusive access to it. Some soundcards (legacy soundblasters) were capable of receiving multiple streams and mixing/resampling in their internal DSP chip, but they have been a history for over a decade. All other soundcards I know of can process only one stream, containing any supported number of channels, of course.
As you mention, a standard desktop requires mixing streams from multiple applications, often at various samplerates. In linux this functionality is provided by a user-space audio daemon called pulseaudio. From the alsa sound layer POW it is a standard audio application, using the alsa API (hw:X devices) to communicate with the actual hardware. Audio applications (called clients) talk to pulseaudio using its API. Apart of mixing and resampling, pulseaudio provides standard desktop functionalities - on-the-fly switching audio devices for each client, client-specific volume, routing between applications, loopbacks, recording the streams etc. Of course it has a plugin API, with many plugins (called pulseaudio modules) available - audio over network, simultaneous input/output to multiple soundcards (with adaptive resampling between the master and slave soundcards). An example of such module would be this advanced xover project Pulseaudio Crossover Rack - multi-way crossover design & implementation with linux . Pulseaudio is a command-line daemon, fully controlled headlessly, with GUI control applications for every linux desktop environment (KDE, Gnome, Mate, etc.).
All general linux desktop distributions have pulseaudio configured by default, therefore every connected soundcard (from boot or hot-plugged USB/bluetooth) is immediately available to all applications with mixing, resampling, individual sound redirection etc. An advanced user who requires direct exclusive access to some device (good-quality soundcard for bitperfect playback, measurement audio device) can tell pulseaudio to ignore this device (clicking in GUI, params of a command-line control tool). From then on PA (being an alsa client itself) will not access the alsa device for this hardware and leave it available for any other alsa client=application. The REW in java, Arta in wine, native jaaa can bit-perfectly access the measurement USB-audio device, while e.g. the integrated soundcard connected to speakers is playing youtube musical video mixed with system sounds and skype, all mixed/resampled by pulseaudio (again) exclusively using the alsa device of the integrated soundcard (and BT-connected device at the same time).
Very similar infrastructure is in windows, if I understand correctly. The exclusive mode would be talking to the soundcard driver directly, bypassing the out-of-kernel windows sound subsystem which does the mixing and resampling - pulseaudio in linux. But historically windows did not offer direct access to audio devices (I have no idea why, it would have been trivial), therefore the proprietary ASIO layer was developed by a third party. Unfortunately this layer had to be completely outside of the windows audio subsystem, and therefore has to go all the way down to the hardware, including its own kernel drivers for the device. That is why vendors have to supply two sets of drivers, totally inconvenient, expensive, maintenance nightmare, and a good reason to abandon legacy hardware with new version of windows. The Asio4All shim tries to fix this dual-drivers nonsense, with varying results.
Last edited:
16GB should work. There are tools out there for installing windows to a USB stick. Just Google.
I designed a commercial music player (Auraliti) with the focus on simplifying hi-res audio playback. There was no way to make that in Windows but we could use Linux and ensure bit perfect playback of any playable files. (I did not know beforehand how many obscure dead end file formats were used for music.) If you talk to ALSA directly its pretty easy to handle the different sample rates and bit depth bit perfect. Alsa can switch sample rates and bit depth across USB with no problems, if you know where to add some pauses for the different DAC's to recover from switching. However its a headless Linux PC that does nothing else.
Windows (and Linux desktop implementation and Mac) all make an effort to have sound "just work". If that means engage the mediocre sample rate converter that doesn't use much power then fine. In fact it will use two sample rate converters in series if you aren't careful- one in and one out. In most corporate environments a huge effort is made to ensure no customer calls come in for things like no sound or picture. That would be no compromise, therefor everything else needs to bend for that requirement. And getting sound working on older platforms can be quite challenging. I watched Apple struggle with that back in the late 1980's even internally.
I understand the pain of having your tools discontinued leaving you stranded. The QA400 isn't the only time it's happened. Looking around my shop I have Praxis (a great acoustic analyzer), HP network analyzers, impedance analyzers and even a recent Tek DSA consigned to the dustbin by the manufacturer because they built it around Win XP. Its the way of the world but they still work if you can work around those constraints. Some newer approaches where the smarts are hosted on a cloud will not work when the vendor loses interest (Sonos for example).
A USB 3 32 GB Samsung flash drive is $10. Load a bootable Win 7 and the QA400 drivers and you are on the air. Don't spend a lot of time surfing the web however, since the malware protection won't be anywhere near current.
Windows (and Linux desktop implementation and Mac) all make an effort to have sound "just work". If that means engage the mediocre sample rate converter that doesn't use much power then fine. In fact it will use two sample rate converters in series if you aren't careful- one in and one out. In most corporate environments a huge effort is made to ensure no customer calls come in for things like no sound or picture. That would be no compromise, therefor everything else needs to bend for that requirement. And getting sound working on older platforms can be quite challenging. I watched Apple struggle with that back in the late 1980's even internally.
I understand the pain of having your tools discontinued leaving you stranded. The QA400 isn't the only time it's happened. Looking around my shop I have Praxis (a great acoustic analyzer), HP network analyzers, impedance analyzers and even a recent Tek DSA consigned to the dustbin by the manufacturer because they built it around Win XP. Its the way of the world but they still work if you can work around those constraints. Some newer approaches where the smarts are hosted on a cloud will not work when the vendor loses interest (Sonos for example).
A USB 3 32 GB Samsung flash drive is $10. Load a bootable Win 7 and the QA400 drivers and you are on the air. Don't spend a lot of time surfing the web however, since the malware protection won't be anywhere near current.
The problem with Windows audio is that there are many APIs available to user-mode applications, and more than one driver model as well. In order to solve a lot of the problems this presented, they came up with the current architecture that is used in Windows 10. It works great in cases where previous versions gave issues for end users. The compromise is that in making it so transparent to the end user, it is "harder" to get exclusive access to the hardware in ways that used to do it in Windows XP. It's still doable, but requires care and I can completely understand why Matt does not want to play IT for every user across every version of Windows 10 with who knows what audio drivers.
Windows Audio Architecture - Windows drivers | Microsoft Docs
Now, I will say that I don't have a lot of experience with audio in Linux as I don't use it as a desktop OS but for development and embedded. A lot of the issues Matt talked about with mixing different sample rate sources will also present themselves in Linux because it's a generic issue. The difference, in my experience, is that you just don't get audio instead of magically having a sample rate converter engaged without your knowledge. Maybe that behavior is different with more recent distributions.
Exclusive modes do exist in Windows if the correct APIs are used.
I agree for the most part, but Xilinx ISE is really old software and it's totally Xilinx's fault it doesn't work on Windows 10. They should have put 6 series FPGA support into Vivado, but they really want you to buy the new stuff.
It's a virtual machine image. The software doesn't actually work on Windows 10 itself.
Sounds like in the end Windows and Linux have the same levers and knobs to adjust. But therein lies challenge: there are a lot of levers and knobs on all platforms. When troubleshooting a customer support case, I can ask a customer to make a measurement in loopback and very quickly get to a common reference point. Not possible if a standard audio device--that would be the beginning of a long checklist related to audio settings.
ASIO (by Steinberg) emerged primarily to address audio latency. For simultaneous recording of playback of music, you need less than ~5 mS of latency otherwise you cannot run software-based effects (eg distortion on a guitar) because the delay between plucking a string and hearing the distorted guitar sound becomes unbearable. ASIO was very needed at the time, but architecturally it's old. It relies on magic settings in the registry for apps to discover it, it's a COM interface. Yuck.
Yes, very true. We've moved some recent project to Spartan 7, in spite of not needing the space or performance, because ISE is so brittle and painful anymore. Vivado is worth the per-device premium you must pay over a Spartan 6 part. But man, it would have been awesome if Xilinx supported Spartan 6 on Vivado.
1Audio (Demian)
Thanks for the hint, but too late. I already cleared out a 16GB USB Stick.
Spent the day jumping through installation hoops. Product Registrations,
Dealing with Microsoft which black balled me for some supposed rule violation
which I'm not aware of. All my .zipers want money because my free time wore out,
and the beat goes on.
For some reason the R2 Fast Installer says its working and sadly I plugged the USB into
a USB1 socket on the front of my desktop 'puter. I've only got a few hours remaining,
and the time is increasing all the time.
The glorious days of 300 Baud modem are gone.
Short snappy CISC, BW Photos, ASCI Characters.
Pressing A,B,C,1,2,3 for menus.
Even though I have fiber to inside the home,
you wouldn't know it on the desktop here.
And then there is that deep seeded fear, which we all know,
that which after waiting, hours and days it says,
"your a dumb ***, reload using 'setup.exe' from
the original source CD."
Kind of like telling Sonny Bono to watch out for that tree
after his burial.
Or Telling that football player turned soldier to
not stand up in the middle of a hot fire fight.
Oh Da Joy - Ludwig Von
Cheers,
Thanks for the hint, but too late. I already cleared out a 16GB USB Stick.
Spent the day jumping through installation hoops. Product Registrations,
Dealing with Microsoft which black balled me for some supposed rule violation
which I'm not aware of. All my .zipers want money because my free time wore out,
and the beat goes on.
For some reason the R2 Fast Installer says its working and sadly I plugged the USB into
a USB1 socket on the front of my desktop 'puter. I've only got a few hours remaining,
and the time is increasing all the time.
The glorious days of 300 Baud modem are gone.
Short snappy CISC, BW Photos, ASCI Characters.
Pressing A,B,C,1,2,3 for menus.
Even though I have fiber to inside the home,
you wouldn't know it on the desktop here.
And then there is that deep seeded fear, which we all know,
that which after waiting, hours and days it says,
"your a dumb ***, reload using 'setup.exe' from
the original source CD."
Kind of like telling Sonny Bono to watch out for that tree
after his burial.
Or Telling that football player turned soldier to
not stand up in the middle of a hot fire fight.
Oh Da Joy - Ludwig Von
Cheers,
Last edited:
MarkS,
Thanks. That would be too easy. Plus I have 2 laptops why buy another one.
I just have to get the laptop number 2 working. It has the strange Dell Squeeze
power inlet. I've found it and lost it 3 times, recently.
I need to just buy another cord and power it up.
BUT
Booting from a USB Stick sounds like a nice idea.
So I rebooted 'puter, to complete the install, but I don't think it did.
Bummer, this shouldn't be like brain surgery, doing this stuff.
So back to square 1 and figure how to reinstall it all over again.
So do I copy everything into the USB and Install into the USB?
Which is what I tried the first time.
Or do I down load everything on the desktop 'puter, then
install it into the USB ?
When I read various instructions from the web, it sounded like
install everything in the USB first, then set it up on the USB Stick
from there. Only problem when I rebooted to finish the install,
I didn't see anything that showed it was finished etc.
Though from the NT6 Fast Installer I do see a SetupComplete.cmd
Isn't that special.
That would be nice if it worked Matt, but it doesn't. at least on my Dell with win10.
Even with the VM and running win7 from within that, and having installed
some of the earlier QA400 versions of the software. Now it used to work on
the Dell with WIN8 for some reason, then upgrading to win10 it stopped working.
The only thing I can think of is the WIN10 stuff is now embedded in that laptop.
Even running win7 within VM it must still be making calls through WIN10 software
which doesn't run the QA400.
Anyone care to donate a laptop with win7 for the cause...if you've upgraded,
bought a newer better super lap top etc., and really don't need it? Please PM me
and I'll send a prepaid shipping label.
DELL PA-6 adapter. Needed.
Cheers
Thanks. That would be too easy. Plus I have 2 laptops why buy another one.
I just have to get the laptop number 2 working. It has the strange Dell Squeeze
power inlet. I've found it and lost it 3 times, recently.
I need to just buy another cord and power it up.
BUT
Booting from a USB Stick sounds like a nice idea.
So I rebooted 'puter, to complete the install, but I don't think it did.
Bummer, this shouldn't be like brain surgery, doing this stuff.
So back to square 1 and figure how to reinstall it all over again.
So do I copy everything into the USB and Install into the USB?
Which is what I tried the first time.
Or do I down load everything on the desktop 'puter, then
install it into the USB ?
When I read various instructions from the web, it sounded like
install everything in the USB first, then set it up on the USB Stick
from there. Only problem when I rebooted to finish the install,
I didn't see anything that showed it was finished etc.
Though from the NT6 Fast Installer I do see a SetupComplete.cmd
Isn't that special.
How does that work if it doesn't even run a QA400 in 2020 it's needed.
That would be nice if it worked Matt, but it doesn't. at least on my Dell with win10.
Even with the VM and running win7 from within that, and having installed
some of the earlier QA400 versions of the software. Now it used to work on
the Dell with WIN8 for some reason, then upgrading to win10 it stopped working.
The only thing I can think of is the WIN10 stuff is now embedded in that laptop.
Even running win7 within VM it must still be making calls through WIN10 software
which doesn't run the QA400.
Anyone care to donate a laptop with win7 for the cause...if you've upgraded,
bought a newer better super lap top etc., and really don't need it? Please PM me
and I'll send a prepaid shipping label.
DELL PA-6 adapter. Needed.
Cheers
Last edited: