On Windows setting 24 bits returned garbage (+- full scale transitions) which reminded me of the classic reading data on the wrong word boundaries. Lots of folks don't want to bother with packed 24 bit data and expect 24 bits in the lower (upper?) 3 bytes of a 32 bit integer or converted to 32 bit FP. I have no idea of the actual problem just I've seen these issues before. Honestly I would prefer a warning dialog that said, "Warning, your device and current settings don't support the bit depth and/or sample rate you have selected".
Also everything was 44.1 no matter what setting was used. The authors used 44.1/16 exclusively, mentioning that sorting out all other possibilities under Windows was difficult. Actually as a DIY measurement system this does not matter much.
Last edited:
The API's for the QA400/401 were on the web site. They may not have moved yet with the move of the site. Send me a PM and I'll try to connect you with the dev.
Its possible to get bit perfect through Windows but it "doesn't come naturally". With Win 10 you need to manually set the driver (if an option), the sound engine interface for the driver and the application. Otherwise Windows will fix your oversight with a sample rate converter or two in sequence.
Its cleaner in XP but that's history. Some apps and ASIO interfaces work but with hassle. The RMAA ASIO interface usually collides with the EMU/creative ASIO and it gets messy when they don't agree on sample rates. I'm not sure what happens with bit depth on Win 10 if there is 24 at one point and 32 at another.
Its possible to get bit perfect through Windows but it "doesn't come naturally". With Win 10 you need to manually set the driver (if an option), the sound engine interface for the driver and the application. Otherwise Windows will fix your oversight with a sample rate converter or two in sequence.
Its cleaner in XP but that's history. Some apps and ASIO interfaces work but with hassle. The RMAA ASIO interface usually collides with the EMU/creative ASIO and it gets messy when they don't agree on sample rates. I'm not sure what happens with bit depth on Win 10 if there is 24 at one point and 32 at another.
QA401 API's: I found this on Github: https://github.com/QuantAsylum/QA401-Remoting-Test Its from the dev at Quantasylum.
Strange. I don't see how choosing sample rates would be difficult. Bit depths may be hit and miss. I'll have to read that paper carefully, but if the used PlayRec/portaudio, it should be easy to choose different sample rates.
That reminds me that I should change MATAA to use PlayRec instead of my own crummy programs for audio in/out to/from Matlab or Octave.
It is except that the result is brickwalled at 22.05KHz without warning. I have never seen a hardware/software combo that actually warns you that you are not getting what you think.
Sorry if I wasn't clear, they were using IIRC just the built-in audio support nothing added. The below is what I am talking about, it runs with no errors, 24 returns garbage, 16 returns the correct noise floor but at 44.1kHz.
recorder = audiorecorder(96000,24,2)
record(recorder,.01)
data = getaudiodata(recorder)
plot(data)
exit
Last edited:
Praxis is great but has several limitations which explain why Bill orphaned it. Biggest one is the the dev environment (Borland) was "retired" as in no longer supported. That plus working with newer windows. I have it working OK in Win 10 but you need to check the Windows sound settings and the driver settings or Windows will crush it all with sample rate conversions.
The other limitation is the Audpod. The Audpod handles level settings and input selections for the different test sources and has an internal calibration function to correct for soundcard failings that works really well. However its scaled for more modest sound interfaces. You can see the size in the attached photo sitting on top of an RTX6001. I'll be making cables to interface them but the cables will dwarf the Audpod.
I would be really grateful if there is a path to the future for Praxis but I have not seen it yet.
Attachments
I just quickly went through the article. I really like the article, because it contains a wealth of useful information that is not easily found elsewhere.
However, I am flabbergasted by the fact they did not mention MATAA (see post 52), which seems to fit their development goal very nicely (a free and open-source audio analysis tool, made using GNU Octave).
In addition, I couldn't figure out how they implemented the audio in/out in their software. As far as I can tell, they do not describe this in the article. Also, I couldn't figure out where to download their software (maybe I am blind or stupid, or both). Anybody help me out?
the octave code is hidden here:
https://linearaudio.net/downloads
The audio in/out is conducted via:
https://www.gnu.org/software/octave/doc/interpreter/Audio-Processing.html
https://linearaudio.net/downloads
The audio in/out is conducted via:
https://www.gnu.org/software/octave/doc/interpreter/Audio-Processing.html
Ah, thanks!
Urgh... that is probably not the best choice in terms of audio performance. And I don't think it works equally well on all major operting systems. Playrec would've been a better choice, for example.
I can not tell if the the audio quality is good or bad... but the playback and record of a very short .wav-file apparently consumes a lot of time and computational resources since my i5-laptop seems to be very busy during the playback/record.
Just to document this: I tried matlab, did not work.
In this concern I like your TestTone interface since it is very verbose and works on matlab too (for me this is not really necessary, but it emphasis the fact that the code does not rely on a third party package or costly proprietary toolbox).
Just to document this: I tried matlab, did not work.
In this concern I like your TestTone interface since it is very verbose and works on matlab too (for me this is not really necessary, but it emphasis the fact that the code does not rely on a third party package or costly proprietary toolbox).
Would that be hard or easy to fix? I was thinking of installing playrec into Anaconda Python, from what I read that would fix a few things.
The Audpod is a software key that enables a lot of capabilities. Plus the optimizations for measuring speakers require signal routing etc that the Audpod manages. The RTX doesn't have the input switching or the software controlled input gains that the Audpod provides. I can make it work without for FFT's but not for speaker measurements.
I truth a $25 USB audio stick is adequate for most speaker testing.
I truth a $25 USB audio stick is adequate for most speaker testing.
That's why I said if the scripts in the LA artice work at 16/44.1 it probably does not matter either.
For speaker and all audio testing, I like sample rates 96KHz and above. This this gives you the cutoff slopes which influence the phase when you do DSP compensation. The best I could find that does 192KHz full duplex was the Babyface. Not too long after I got one, then this project drew my attention.
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.