QuantAsylum QA400 Audio analyser

Advertise with us
Shop deals on ebay
shop deals on amazon
GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
abbey road d enfer said:
"What the test shows below is the range of times needed to read a register in the QA400 box a few thousand times. This shows that on average is takes 538 uS, but it can take as much as 2.25 mS. This number is important because the QA400 hardware buffers 2Kbytes of captured audio, or roughly 340 audio samples. At 192Ksps, this is 1.8 mS of audio. So, if you don't pull the data over in 1.8 mS, then there's no place for it to go, and the hardware notes the buffer overflow and lights the drop light.

At 48Ksps, the problem is easier, and you get about 7.2mS before overflow occurs.

Now, the actual number achieved in practice is much better because we used overlapped IO. One thing interesting is that each USB port on your machine is often a different controller. This means you can see variation between ports on machines. Is it possible that one of the ports on your machine can deliver a reduced maximum time?"
Click to expand...
Damn!  This is seriously limiting for any acoustic work.  It represents 7.2 feet of acoustic path length at 48kHz

My firewire MOTU Traveler with appropriate software can do several 10s of seconds of duplex signal capture.  ie it can play eg 30 seconds of test signal and record it at the same time in synch.

You may need something like the special ASIO version of Audacity to be used with Prof Angelo Farina's Aurora plugins.  Look on his website.

Surely Windoze can do this with USB.  Duu.uh!  Then again there doesn't seem to be ANY sound software that worked properly with Vista, the Windoze version supposedly optimised for multi-media.  :p
 
ricardo said:
abbey road d enfer said:
"What the test shows below is the range of times needed to read a register in the QA400 box a few thousand times. This shows that on average is takes 538 uS, but it can take as much as 2.25 mS. This number is important because the QA400 hardware buffers 2Kbytes of captured audio, or roughly 340 audio samples. At 192Ksps, this is 1.8 mS of audio. So, if you don't pull the data over in 1.8 mS, then there's no place for it to go, and the hardware notes the buffer overflow and lights the drop light.

At 48Ksps, the problem is easier, and you get about 7.2mS before overflow occurs.

Now, the actual number achieved in practice is much better because we used overlapped IO. One thing interesting is that each USB port on your machine is often a different controller. This means you can see variation between ports on machines. Is it possible that one of the ports on your machine can deliver a reduced maximum time?"
Click to expand...
Damn!  This is seriously limiting for any acoustic work.  It represents 7.2 feet of acoustic path length at 48kHz
Click to expand...
I don't really understand your comment. You seem to understand much better than me the implications of this parameter.
My view on it is that it's just latency applied on gathered data, and if the machine doesn't empty the pipe-line in time, data are lost. You seem to imply that if latency higher than 2.25ms (e.g. due to distance between source and pick-up) data would be lost. I don't think so. Loss of data seems to be just when the "time to read register" is larger than the duration of 340 samples. Ther would just be a string of invalid data at the beginning. And 2.25ms is a peak value, the average being 5about 5x faster.
My firewire MOTU Traveler with appropriate software can do several 10s of seconds of duplex signal capture.  ie it can play eg 30 seconds of test signal and record it at the same time in synch.
Click to expand...
Well, almost any decent soundcard can do hours of duplex recording (maybe not at 192k). The problem is a software to do the analysis.
Personally, I would have liked a DSP embarked in their box, doing the number-crunching, and spitting it out at USB1.0 speed, and the PC doing the menial tasks, displaying and printing.
You may need something like the special ASIO version of Audacity to be used with Prof Angelo Farina's Aurora plugins.  Look on his website.
Click to expand...
I will.
However, it seems the market is crowded with acoustic software (not implying they're all good) and deserted of electronic software.
I guess that's because people having set-up their HiFi speakers endows them legitimity to embark in a carreer in acoustics.  ;)
 
Thanks for your help abbey road d enfer.
I already sent them some email, but no answer yet. Maybe I will call QA.
I checked the Help/About and got the following:

Copyright (C) 2011, 2012, 2013 QuantAsylum. All rights reserved
---
Product: QAAnalyzer
Culture: en-US
OS: Windows XP [32 bit]
Version: 1.060
Assembly Version: 1.0.5.7
RAM Used: 33.32 Mbytes
BITfile Checksum: ad969550 [Match]
Hexfile Checksum: b735b74e [Match]
SW Version: 1.060
Connected: True
Test Connection: True
USB Reg Read Average Time (mS): 0.674  StdDev (mS): 1.075    Min (mS): 0.370  Max (mS): 17.353

Looks like my computer's USB is to slow. I will try the rest of the available connectors(2), maybe one of them works better. Where can you select or set 32k sampling? I only see 48 and 192.
Thanks, Miklos



 
I believe I've finally got my front-end for this monster working.  I'll post more details in a while.

I've been getting more and more frustrated at this box.  Some of the bugs in the software are totally bizarre, like it wasn't tested before the release.  The company does seem to be good at responding to bug reports, though, so hopefully it's just a matter of time until the software is ironed out.

Since the QA400 has unbalanced ins & outs, the length of the bnc cable seems to make a pretty big difference in terms of noise pickup.  The 3' cables that came with the unit seem to pick up a good amount of 60Hz - with the QA400 looped back into itself, I can move the noise floor around by 6dB or so just by holding the cable in different positions.  I guess this isn't the company's fault - maybe it's inevitable with the unbalanced connections - but it's obnoxious nonetheless.
 
ricardo said:
Damn!  This is seriously limiting for any acoustic work.  It represents 7.2 feet of acoustic path length at 48kHz
Click to expand...
abbey road d enfer said:
I don't really understand your comment. You seem to understand much better than me the implications of this parameter.
Click to expand...
Lets take the simplest acoustic measurement.  A speaker measured at 1m (about 3') from a mike.

It takes 3ms (about 1' per ms) for signal from speaker to mike.  You really want to be recording while the signal is in flight.  You need to continue measuring for AT LEAST another 5ms until the 1st reflection (from floor or ceiling if you've set stuff up right) reaches the mike and if you want to look at stuff down to 20Hz for another 50ms.  This only gives you 20Hz resolution at LF so not very useful for Room EQ for which you want ALOT more.

If the device stops recording (eg to send stuff to the PC) in this time, you have a wonky measurement.

There's ways to get around this for purely electrical stuff but not for acoustics.

My main focus is on acoustics (mikes & speakers).  It may be the QA400 is OK for electrical stuff but with this size buffer/dump speed, it will never be able to incorporate Prof Farina's Log sweep as in the latest AP.  This is by far the best way to do an acoustic measurement today.

I do this with Audacity and process it with my own DOS software.  But keeping a DOS capable machine is becoming seriously difficult today and may be impossible soon if Redmond has its way.
 
ricardo said:
If the device stops recording (eg to send stuff to the PC) in this time, you have a wonky measurement.
Click to expand...
I understand that. So you assume that when the box dumps data to the PC, it stops gathering new data.
Interesting. I'll ask QA directly if it's the case.
I know they are working on including a calibration process for measurement mics, so they are clearly targetting their product to this side of the market.
 
abbey road d enfer said:
I understand that. So you assume that when the box dumps data to the PC, it stops gathering new data.

I know they are working on including a calibration process for measurement mics, so they are clearly targetting their product to this side of the market.
Click to expand...
I don't know that for sure but 'what you reported they said about buffering' sure sounds like that.

If the QA400 is able to do a measurement with eg 15s of Angelo Farina's log sweep, that would make it very attractive.  The problem is likely to be Windoze.  That's why any sensible sound software/hardware needs ASIO if running Windoze.

There was some hope Windoze 7 would improve things but the Windoze Mixer is EVEN more obfuscating and impenetrable.  In a sensible OS, it should be easy to replace the Windoze Mixer with your own programme but this is nearly impossible.
 
ricardo said:
abbey road d enfer said:
I understand that. So you assume that when the box dumps data to the PC, it stops gathering new data.

I know they are working on including a calibration process for measurement mics, so they are clearly targetting their product to this side of the market.
Click to expand...
I don't know that for sure but 'what you reported they said about buffering' sure sounds like that.
Click to expand...
Well I don't have enough elements to make up my mind about it.
If the QA400 is able to do a measurement with eg 15s of Angelo Farina's log sweep, that would make it very attractive.  The problem is likely to be Windoze.
Click to expand...
That would be undisputable if they used the DirectSound protocol. But I understand that they have developed their own protocol in order to overcome the DirectSound limitations. I think they mention on their website that ASIO was not convenient for them either, but it may be something my deranged mind made up.
That's why any sensible sound software/hardware needs ASIO if running Windoze.
Click to expand...
Or an alternative suitable protocol.
In a sensible OS, it should be easy to replace the Windoze Mixer with your own programme but this is nearly impossible.
Click to expand...
You just can't put "sensible" and "Microsoft" in the same sentence.

Anyway I have asked them directly their comments on this issue.
 
ricardo said:
abbey road d enfer said:
I understand that. So you assume that when the box dumps data to the PC, it stops gathering new data.

I know they are working on including a calibration process for measurement mics, so they are clearly targetting their product to this side of the market.
Click to expand...
I don't know that for sure but 'what you reported they said about buffering' sure sounds like that.

If the QA400 is able to do a measurement with eg 15s of Angelo Farina's log sweep, that would make it very attractive.  The problem is likely to be Windoze.  That's why any sensible sound software/hardware needs ASIO if running Windoze.
Click to expand...
Here is QA's answer:
"We're familiar with Farina's seminal work with the swept sine, and it's not a problem to do that on the QA400.

There are two types of latency to consider: Audio latency and USB latency. Audio latency could be characterized as the delay from when an impulse function is sent to the DAC via I2S, and the time it is detected in the ADC via I2S. I suspect the audio latency is dominated by the group delay of the hardware codec anti-alias filters. Plus a sample or two for whatever pipeline might exist in the codec. In summary, the audio latency is probably on the order of 10's of microseconds.

USB latency is the amount of time the host program must wait once it tells the USB subsystem to grab a particular piece of data. Since the QA400 has a limited buffer of about 300 samples, this means that if the PC tries to grab samples over USB, and for some reason the OS + Drivers cannot service that request in a certain time, then the QA400 buffers become full after a few milliseconds, and there's no place to stuff the arriving data from the ADC. And in that case, the drop LED lights to indicate there's been a problem. So, the latency of the USB overall must consistently be better than 5 mS or so depending on sample rate. Generally, this isn't a problem at all for modern computers to deliver 400-500 uS response time. Yes, out of 50K reads all PCs might have a bad response or two, but the system just discards those occasional hiccups. The drop LED comes on, and the waveform is ignored, and the system tries again.

PS. I don't want to give the impression we can do swept sine measurements today. Instead, it's something we're looking at for a future SW release. The hardware, however, is capable. "
 
abbey road d enfer said:
ricardo said:
abbey road d enfer said:
I understand that. So you assume that when the box dumps data to the PC, it stops gathering new data.

I know they are working on including a calibration process for measurement mics, so they are clearly targetting their product to this side of the market.
Click to expand...
I don't know that for sure but 'what you reported they said about buffering' sure sounds like that.

If the QA400 is able to do a measurement with eg 15s of Angelo Farina's log sweep, that would make it very attractive.  The problem is likely to be Windoze.  That's why any sensible sound software/hardware needs ASIO if running Windoze.
Click to expand...
Here is QA's answer:
"We're familiar with Farina's seminal work with the swept sine, and it's not a problem to do that on the QA400.

There are two types of latency to consider: Audio latency and USB latency. Audio latency could be characterized as the delay from when an impulse function is sent to the DAC via I2S, and the time it is detected in the ADC via I2S. I suspect the audio latency is dominated by the group delay of the hardware codec anti-alias filters. Plus a sample or two for whatever pipeline might exist in the codec. In summary, the audio latency is probably on the order of 10's of microseconds.

USB latency is the amount of time the host program must wait once it tells the USB subsystem to grab a particular piece of data. Since the QA400 has a limited buffer of about 300 samples, this means that if the PC tries to grab samples over USB, and for some reason the OS + Drivers cannot service that request in a certain time, then the QA400 buffers become full after a few milliseconds, and there's no place to stuff the arriving data from the ADC. And in that case, the drop LED lights to indicate there's been a problem. So, the latency of the USB overall must consistently be better than 5 mS or so depending on sample rate. Generally, this isn't a problem at all for modern computers to deliver 400-500 uS response time. Yes, out of 50K reads all PCs might have a bad response or two, but the system just discards those occasional hiccups. The drop LED comes on, and the waveform is ignored, and the system tries again.
Click to expand...


I think all of that might be exposing a limitation of using bulk transfers for their data. At least, that is my inference from looking at all of the descriptor dumps provided earlier in the thread and then the description of what the box does (buffers measurement data then sends it along).

The problem with bulk transfers is that there's no guarantee of delivery time. They are literally the lowest on the priority totem pole, and are serviced whenever nothing else is occupying the bus.

The isochronous transfer used by standard USB audio devices guarantees bandwidth because the device tells the host what bandwidth it requires, and when the application attempts to initialize an interface the drivers check against available bandwidth and if not enough is available, the device won't start.

Now we know we shouldn't confuse bandwidth and latency, but latency across the bus from the device out to the root hub in the computer and then over the PCIe bus or through the CPU bridge is identical regardless of transfer type.

That's a separate issue from the "latency" that results from the host making an IN request to the device and the device then sending the data back. In the isochronous case, those IN requests occur regularly. In the bulk transfer case, those IN requests occur ... whenever. Remember that a USB device is always a slave, and will not send data to the host without the host requesting it first.

So in the case of this device, if it is sampling and filling a buffer and waiting for bus transfer time, then if those requests don't come fast enough, for whatever reason, your data get overwritten.

Suffice it to say, I don't understand the choice of using the bulk transfer over the isochronous mode at all.

-a
 
yes, that's what i ended up with.  final schematic is attached to this post.  i've been using it for the last couple months and it does what it should.  my pcb layout is more cramped than it should be for optimal usability.

rotary switches are from grayhill & toggles from e-switch.  xlrs are neutrik d series, and bnc connectors are from molex.

the limits are set by the qa400's unbalanced connections;  it wouldn't hurt if the interface had a balanced input from the qa400, and maybe some sort of ground-canceling output.  for now, this works ok.  eventually i might have another go at it.
 

Attachments

  • qa400_front_end_public.jpg
    qa400_front_end_public.jpg
    860.7 KB · Views: 134
After having used the QA400 for a good while, I've still got very mixed feelings.  The interface is flaky and quirky, and the whole thing feels very fragile - for the price, I still think it's hard to beat, but I don't imagine this is a serious competitor to higher-end systems (never had the opportunity to use an AP, but it can't possibly be this weird and unstable).
 
Found on page Chinese QuantAsylum the DataSheet and Manual QA400.
In Chinese of course!

http://www.quantasylum.net/fp8400-p-30.html?cPath=4
http://www.quantasylum.net/download/FP8400%E5%BD%A9%E9%A1%B5.pdf
http://www.quantasylum.net/download/FP8400_Users_Manual.pdf

Will we have this literature translated into English language?

Another interesting fact is that in China, the QA400 is presented with another model and another brand.

http://www.fpinstrument.com/Product/
 
Quantasylum US has a different website, quantasylum.com.

The interface feels clunky (take a look at the manual), and they still haven't worked out all the bugs - with each release it gets better, but it seems like they should have spent a little more time testing.  There have been some big ones.

The measurements are also jittery.  Not sure if this is because I'm using an older computer, but it's not uncommon every few measurements to get one that's total garbage.

I don't regret getting the device at all, though.  What else competes for close to the price?
 
dfuruta said:
The measurements are also jittery.  Not sure if this is because I'm using an older computer, but it's not uncommon every few measurements to get one that's total garbage.
Click to expand...
Very likely to be caused by the USB link failing to send the acknowledgement to the QA400. It's one serious limitation of the QA400. It is glorified soundcard with all the processing done by the computer. Most other (much more expensive) systems embark some DSP in the box. The USB link transmits only data resulting from the processing, which can be done at a relatively slow pace.
 

Similar threads

B
Design of a sound card "Front end" for audio test set
2 3
Replies
56
Views
3K
MidnightArrakis
MidnightArrakis
rock soderstrom
The Lost 200. Maihak V72 for 100€? Read this article from the german news magazine "DER SPIEGELL"
Replies
8
Views
623
Brian Roth
B
G
Trying to decide on tube mic preamps
2
Replies
34
Views
5K
SIXTYNINER
S
G
Differential Input Module For My Analog Audio Test Gear
Replies
3
Views
721
fazer
F
F
Opamp Labs transformers opinions?
Replies
3
Views
998
CJ
CJ

Latest posts

Back
Top