That seems to be a 16-bit measurement. Choose ASIO or WASAPI exclusive drivers for more than 16 bits.
BINGO!
Not sure how I knocked it to JAVA but switched back to ASIO and I get the following both channels .747Vrms input
That seems to be much better aligned with results I have seen on this thread with the 2i2. Thanks for the feedback, I knew it should be able to do better. Now to test it on an amp later today after I get some calibration data collected.
AkitikA which came in mail today. 5.6 ppm THD mostly 2nd. Hoping it would be a bit better. Almost like the REW+2I2 better with exceptions of higher orders
My Motu M4 loopback measurement with inbuild DAC output looks like this, so I do not see a reason to buy a low THD-sine wave generator. This is the THD sweetspot, the THD+N sweet spot is found at higher signal levels around -106dBFS THD+N
Attachments
Last edited:
With Focusrite, usual loopback distortion is about 0.0003% or -110 dB, on condition of not using too much line-input gain and maximum generator output level.
There is a sweet spot with < 0.0001% or -120 dB, using settings from the picture below. ‘Lock frequency to RTA FFT’ signal generator setting is important. Position of gain and monitor knobs should be about 11 o’clock for line-in gain and 1 o’clock for monitor. At those settings, measured signal generator output was 0.775 V or 0 dBU. Changing gain or monitor levels, brings distortion to usual 0.0003% or worse.
There is a sweet spot with < 0.0001% or -120 dB, using settings from the picture below. ‘Lock frequency to RTA FFT’ signal generator setting is important. Position of gain and monitor knobs should be about 11 o’clock for line-in gain and 1 o’clock for monitor. At those settings, measured signal generator output was 0.775 V or 0 dBU. Changing gain or monitor levels, brings distortion to usual 0.0003% or worse.
Last edited:
Tombo56 I can confirm similar results with a focusrite solo, although with lower generator levels. A calibration thing no doubt. I do find tho an external osc. such as Victors makes the results are little more stable / repeatable. I like having a known ultra low distortion source to eliminate one variable!
Attachments
Your thoughts on this odd thing I found today with my laptop, an HP Pavilion with dual Graphics cards (AMD + NVIDIA). I expected the opposite and I get this:
Doing some measurements with REW: disconnect the Laptop PSU and I get more distortions in RTA, not less.
I checked my Power Savings Options, and I was on Performance Mode for both battery and Powered. I tested some more with AMD Ryzen Balanced, same thing.
Went into More Advanced Options and changed some of the detailed settings there for Battery vs Powered because then my thinking is that one of the options that gets set when on Battery mode is interfering with the internal analogue output somehow. Still, same effects and thus nothing found that could explain it.
The output used in the internal 'Headphones' out and what I noticed is that it takes around 6s for the distortions to appear in my setup on unplugging the charging cable. In addition, if I plug the cable in again, RTA doesn't remove the distortions although I have no averaging, until I stop the playback on the Generator and start it again.
I did disconnect the PSU AC-side as well, and that does no change.
Doing some measurements with REW: disconnect the Laptop PSU and I get more distortions in RTA, not less.
I checked my Power Savings Options, and I was on Performance Mode for both battery and Powered. I tested some more with AMD Ryzen Balanced, same thing.
Went into More Advanced Options and changed some of the detailed settings there for Battery vs Powered because then my thinking is that one of the options that gets set when on Battery mode is interfering with the internal analogue output somehow. Still, same effects and thus nothing found that could explain it.
The output used in the internal 'Headphones' out and what I noticed is that it takes around 6s for the distortions to appear in my setup on unplugging the charging cable. In addition, if I plug the cable in again, RTA doesn't remove the distortions although I have no averaging, until I stop the playback on the Generator and start it again.
I did disconnect the PSU AC-side as well, and that does no change.
Is anyone here using REW with Linux AND an E-MU 1010/1212m/1616/1616m/1820/1820m?
Perhaps Linux Mint or Ubuntu Studio?
I ask since my E-MU 0404 USB works much better on an ancient laptop using Linux Mint (Cinnamon) and REW V5.20.13. (Compared with Windows 11 22H2.)
On a much faster quad core Windows 11 desktop I have constant REW glitches with my 1616m so I am thinking of trying the 1616m with Linux. But first I would like to know if anyone is using the REW, Linux and 1616m (or similar) E-MU combination successfully before I go down that rabbit hole.
I don't understand the endless glitches with Windows 11 on the Dell 3670 quad core with DDR4 and NVME. Maybe it is something with Windows 11. My fastest machine does not have PCI for the E-MU PCI card so I thought I would next try Linux on the Dell 3670.
The glitches with locked REW Generator to REW RTA (loopback) looks like the (attached) image from the REW help regarding non-periodic signals. But I am using the REW generator locked to the FFT. So I think some sort of software/hardware issue is causing the glitches. (Nothing else is running and I have tried running real time, all updates, latest firmware, etc.) I am using Creative ASIO. (And maximum buffer size.)
Perhaps Linux Mint or Ubuntu Studio?
I ask since my E-MU 0404 USB works much better on an ancient laptop using Linux Mint (Cinnamon) and REW V5.20.13. (Compared with Windows 11 22H2.)
On a much faster quad core Windows 11 desktop I have constant REW glitches with my 1616m so I am thinking of trying the 1616m with Linux. But first I would like to know if anyone is using the REW, Linux and 1616m (or similar) E-MU combination successfully before I go down that rabbit hole.
I don't understand the endless glitches with Windows 11 on the Dell 3670 quad core with DDR4 and NVME. Maybe it is something with Windows 11. My fastest machine does not have PCI for the E-MU PCI card so I thought I would next try Linux on the Dell 3670.
The glitches with locked REW Generator to REW RTA (loopback) looks like the (attached) image from the REW help regarding non-periodic signals. But I am using the REW generator locked to the FFT. So I think some sort of software/hardware issue is causing the glitches. (Nothing else is running and I have tried running real time, all updates, latest firmware, etc.) I am using Creative ASIO. (And maximum buffer size.)
Attachments
Dropouts seem the likely cause, worth trying the WASAPI exclusive option in the REW Java drivers (device names starting EXCL).
About a year ago I briefly tried to setup 1616m in Ubuntu but failed. IIRC there was not even a driver for 1616m. But admittedly I did not spend much time on it.
When using the EXCL devices names I can get an output to the E-MU 1616m but no input. See attached screenshot. The output (and loopback input) are visible on the peak meters in E-MU PatchMix but REW does not see the input. Not sure what I am doing wrong or perhaps WASAPI just doesn't work with the old E-MU 1616m. (I can get output but so far no input.)
Attachments
Last edited:
Which version of Ubuntu did you try?
This is very old but gave me the idea to try Linux, but it might be broken now:
https://askubuntu.com/questions/264...12m-emu-1616m-or-emu-1010-to-work-with-ubuntu
I would really hate to give up on my 1616m (and all the repairs/upgrades) but eventually it will be less painful to buy something new. However the AKM ADC and CS4398 DAC in the 1616m implementation are still pretty impressive. It is expensive to match the performance and number of inputs/outputs even today.
No EMU here, but I got Win glitches especially when I tried several ASIO drivers. I find it to be more stable when using a single ASIO driver installed. Ubuntu REW is way more stable in my experience.
I often get frustrating glitches with Win10 and USB EMU0404. Sometimes it seems to relate to input socket/plug connectivity on my EMU, as the internal socket switches control the input circuit configuration. I recall I shorted out those switches on the pcb to just configure the input for 1Megohm inputs as that is what I 99.9% do for bench testing - that was on my first 0404 as the sockets got worse and worse and noticeably more sloppy when fitting a plug. I now have another 0404 which didn't initially exhibit glitching I recall, but I'll have to review that again. I also just changed PC's so had to eek out all the sound control settings to turn off any sound notifications, and I also turn off my PC external powered speakers whenever using REW as a way to only have Win recognise the EMU being connected.
I experienced such glitches with my EMU-tracker. After a long and frustrating period of research I found the elephant in the room: These were corroded contacts of rear insert jacks that disrupt the signal path! Plug in/remove several times some TRS-plug - and it works again. As these are totally useless to me, I bridged them with some patchware - problem solved.
One possible clue might be here?
https://wiki.linuxaudio.org/wiki/hardware_matrix?s[]=mu
Not sure if that is part of it. It might explain why the much faster newer computer has many more dropouts when compared with my old HP Z400 clunker.
The HP Z400 uses the X58 chipset and that is one of the last with PCI:
https://en.wikipedia.org/wiki/List_of_Intel_chipsets
A bit of a guess at this point. Perhaps I stick with the HP Z400 for the 1616m & REW.
https://wiki.linuxaudio.org/wiki/hardware_matrix?s[]=mu
Not sure if that is part of it. It might explain why the much faster newer computer has many more dropouts when compared with my old HP Z400 clunker.
The HP Z400 uses the X58 chipset and that is one of the last with PCI:
https://en.wikipedia.org/wiki/List_of_Intel_chipsets
A bit of a guess at this point. Perhaps I stick with the HP Z400 for the 1616m & REW.
I set the buffer size to maximum (100ms) for REW.
I just booted up the old HP Z400 (with the X58 chipset with the real PCI slot not PCIe to PCI bridge chip) and I am currently testing it will 4M length FFT. (I was getting glitches at 256k, 512k and 1M on the much faster 8th generation computer but that uses a PCIe to PCI bridge chip on the motherboard.)
I just booted up the old HP Z400 (with the X58 chipset with the real PCI slot not PCIe to PCI bridge chip) and I am currently testing it will 4M length FFT. (I was getting glitches at 256k, 512k and 1M on the much faster 8th generation computer but that uses a PCIe to PCI bridge chip on the motherboard.)