Thank's, God bless the lurkers. If you go Linux/Unix things work, I have been trying to get transparent hardware support for the Win community. First try this morning with Octave 16 bits worked 24 bits returned garbage. I need to explore more, but thanks for the input. I know the Python community seems to have little interest in audio.
EDIT - this text is totally x'ed out on the MATAA site.
Last edited:
Currently i am using the 4.03. Windows-built on win7 and win10 and it seems to work quite as expected with MATAA. Til now I have not used the system for productive work, though.
Next step will be to complete a Linux-based setup, but i need to buy a linux/unix-supported audio interface for that.
I guess it wouldnt be too complicated to access the TestTone stuff directly from python, but to be honest I am not a software engineer.
Next step will be to complete a Linux-based setup, but i need to buy a linux/unix-supported audio interface for that.
I guess it wouldnt be too complicated to access the TestTone stuff directly from python, but to be honest I am not a software engineer.
Don't sweat over it, I've never seen or heard of a DSO with more than 12bit of ENOB. And a low end Keysight of such, from the DSO9000 series, costs 25k of your green stuff.
The problem is you don't know if you are getting what you expect. IME everything fails silently you ask for 24/96 audio and you get 16/44.1 simply made into 24/96 by resampling. You have to actually examine the binary data to see, for instance, the 8 LSB's (or MSB's) are all 0. In the end the head developer for Audacity, for one, when questioned just said why do you need anything over CD quality for recording.
Just google Audacity and 24 bit recording, it's actually hilarious the clueless running back and forth.
Last edited:
When going through the 725D manual, for the calibration parameters they specify
using an oscilloscope, since I only have a Tek 2246Mod A scope at 100kHz....
and I also have a HP34401A. Thinking for the offset measurments that
are to be in Vrms the HP34401A would be a better choice.
What think y'all.
using an oscilloscope, since I only have a Tek 2246Mod A scope at 100kHz....
and I also have a HP34401A. Thinking for the offset measurments that
are to be in Vrms the HP34401A would be a better choice.
What think y'all.
It seems that if you use the WASAPI interface with Audacity it should be possible to record 24 bit. Provided the soundcard supports it.
See:
Features | Audacity®
See:
Features | Audacity®
Just tried it with the Scarlett 2i2 garbage, the record window froze at the origin, WME worked fine but 16 bits. I'm not saying that maybe there is some secret incantation that gets some setup to work but in this day and age this behavior PiP is ridiculous.
Last edited:
At the bottom of the page here: Windows 7 OS - Audacity Wiki
It says, "Exclusive Mode under WASAPI does in principle allow bit-perfect audio transfer without emulation, but this is not yet possible in Audacity. The Windows WASAPI "Host" choice introduced in Audacity 2.0.4 only allows emulated output." It says Shared Mode is still actually used, which results in automatic sample rate conversion by Windows, if the Windows default sample rate differs from what is selected in Audacity.
Elsewhere, it says Direct Sound Exclusive Mode is supported. For sound cards with Direct Sound drivers supporting Windows Exclusive Mode, that seems like it probably ought to work.
16 bit DSO: https://www.picotech.com/oscilloscope/4262/picoscope-4262-overview Only $1300 and 5 MHz BW. Their software is good as well plus all the API etc. to do your own interface.
Nice but I don't expect the average DIY'er to spend that kind of money to measure THD. That's just me and my personal hobby horse. Looks good though.
Last edited:
WASAPI and/or Direct Sound aren't what matter, in this case. Only Exclusive Mode vs. Shared Mode matters. Exclusive Mode is Microsoft's answer to ASIO, and is available with either Direct Sound or WASAPI drivers (assuming the sound card manufacturer writes the drivers with Exclusive Mode support). Shared Mode is not supposed to be equivalent to ASIO, and will perform SCR on playback (at least), if the Windows default sample rate differs from what is selected in Audacity.
If stuck with Shared Mode drivers (either Direct Sound or WASAPI), one obvious thing to try is to set Windows default sample rate to 24/96 and set Audacity the same. Since no SRC or bit depth change would be needed, Windows should not perform any. It worked for me when I tried it.
Last edited:
It takes some effort to call these expensive toys "DSOs". In particular after trying to get some triggering beyond the very basic. Oh, and sampling rates are (for the Cleverscope) "100 MSamples/s to 1500 MSamples/s" guess the sample rate of the 14bit version and the single shot capability.
On the same note, ARTA plus a decent sound card can be viewed as a 24bit almost 100KHz bandwidth DSO. Not bad for 50 quid.
Tried that numerous times, always set exclusive mode. You need to actually examine the data SY did to his surprise no errors or warnings are ever issued by any of the hardware/software.
Audition and CoolEdit do the same thing ARTA works, you just have to check. Octave, Python, and SoX also don't work under Windows they all return 16 bit data no matter what the settings. Ocenaudio (thanks Demian, appears to work) and is a free update/clone of CoolEdit.
EDIT - This is all silly, if you are serious on the technical side just go to Linux.
Last edited:
Some or all of that is likely due to the applications rather than Windows. Audacity fakes (eumulates) WASAPI Exclusive mode support. SoX can apparently do auto SRC without telling you, just like Windows, if it deems it to be necessary. Python has only basic support for Windows devices, according to what I could find here: https://wiki.python.org/moin/Audio/ Although maybe there are Python extensions that support more features. Don't know about the other apps.
Regarding Linux, it's fine if you can find all the features you need on that platform. For some things you can.