I believe the Juli windows app can be patched for a loopback.
The xp sound engine is much better for this. As is ASIO. For later versions you need to switch everything in the sound control to the target sample rate a at least the target bit depth.
Microsoft's first.audio priority is to have sound or they get calls which are expensive. . . The correct sound without distortion is a secondary issue.
I wonder how Linux for windows will handle this.
The xp sound engine is much better for this. As is ASIO. For later versions you need to switch everything in the sound control to the target sample rate a at least the target bit depth.
Microsoft's first.audio priority is to have sound or they get calls which are expensive. . . The correct sound without distortion is a secondary issue.
I wonder how Linux for windows will handle this.
Thanks to all. Both sides of the VC loopback were configured at exactly the same 192/24 (96/24 for the other spectrum), there is a screenshot of that. It was not a default device. IMO that spectrum looks like 16bit decimation somewhere along the path.
ASIO would likely work but a duplex independent ASIO bridge is required.
Yes but I doubt more than one application can open the same ASIO side of the soundcard. We need playback for octave (real soundcard), playback for arta (loopback to octave), capture for octave (real soundcard), capture for arta (loopback from octave to arta). Plus octave are two independent processes, each opening its own device.
Splitting a routed multichannel soundcard into independent multiple virtual devices (running all at the same samplerate) is trivial in linux.
ASIO would likely work but a duplex independent ASIO bridge is required.
Yes but I doubt more than one application can open the same ASIO side of the soundcard. We need playback for octave (real soundcard), playback for arta (loopback to octave), capture for octave (real soundcard), capture for arta (loopback from octave to arta). Plus octave are two independent processes, each opening its own device.
Splitting a routed multichannel soundcard into independent multiple virtual devices (running all at the same samplerate) is trivial in linux.
We will see. If it was proper virtualization with PCI passthrough for selected devices, it would be OK. But then it would require using linux apps for the measurement. I can imagine someone running Arta in wine windows emulation on ubuntu on WSL in windows. Not me, I do not see any need for the windows bottom layer, but it would work. But such setup can be already done, some virtual machines offer PCI/USB passthrough.
Quite possible, there are not many unique codes in a 1kHz tone at exactly 96k sampling maybe looking at couple of cycles would show something?
As always open source comes to the rescue of the dumb closed windows.
The wonderful Jackd (ported from linux to windows) offers multiple virtual ASIO devices with any number of channels JACK Audio Connection Kit|Using JACK on Windows. The patch configuration is easily scriptable (the GUI is just a layer on top of a command-line program, the whole chain can be started automatically with a script - BTW that is the way to code good software, not like GUI-only driver tools without any automation available that most HW manufacturers sell for windows/OSX).
The attached screenshot shows Arta -> ASIO JackRouter -> playback process in octave -> ASIO JackRouter -> capture process in octave -> ASIO JackRouter -> Arta FFT, 192/24 (jackd uses float32 internally). Again - this is how a bit-perfect chain should look like, but this time natively in Win10.
It will work.
The wonderful Jackd (ported from linux to windows) offers multiple virtual ASIO devices with any number of channels JACK Audio Connection Kit|Using JACK on Windows. The patch configuration is easily scriptable (the GUI is just a layer on top of a command-line program, the whole chain can be started automatically with a script - BTW that is the way to code good software, not like GUI-only driver tools without any automation available that most HW manufacturers sell for windows/OSX).
The attached screenshot shows Arta -> ASIO JackRouter -> playback process in octave -> ASIO JackRouter -> capture process in octave -> ASIO JackRouter -> Arta FFT, 192/24 (jackd uses float32 internally). Again - this is how a bit-perfect chain should look like, but this time natively in Win10.
It will work.
Attachments
Linux installation procedure gradually builds up Installation on Linux * pavhofman/nonlinear-compensation Wiki * GitHub. Not finished yet, the project is still for older octave 4.
Yeah, jackd has a fixed pre-configured frequency. WDM device -> wine - > alsa offers all samplerates/sample bits the hardware supports, direct access to the hardware without any resampling/modifications. IMO easier and more reliable than configuration in windows where the windows sound subsystem is difficult to circumvent and ASIO workarounds must be used.
Plus all alsa features are available to windows applications - bit-perfect loopbacks, merged soundcards, arbitrary routing of channels (i.e. virtual balanced outputs/inputs), and last but not least fully-maintained drivers for legacy hardware in the latest linux kernel.
Plus all alsa features are available to windows applications - bit-perfect loopbacks, merged soundcards, arbitrary routing of channels (i.e. virtual balanced outputs/inputs), and last but not least fully-maintained drivers for legacy hardware in the latest linux kernel.
The new adapter version finally allows switching between loopback and DUT.
My very first real measurement - opamps distortion. Noniverting, unit gain, output reduced by -1dB with a voltage divider.
Images:
1. The adapter with simple opamp measurement board connected.
2. Non-compensated measurement of RC4556N at 3kHz
3. Split-compensated loopback at the same level as the previous measurement
4. Compensated measurement of RC4556N
5. Repeated compensated measurement of RC4556N
6. Compensated measurement of NE5532P
7. The tool split-compensating both sides during measurement.
Clearly NE5532P has lower distortion than RC4556N. Both distortions are way above the compensated loopback distortion.
I am glad the dirt-cheap 10-turn Bourns fake pot from ebay does the job perfectly, allowing easy setting down to a few thousands of dB. Since both voltage-divider and low-pass filter transfers are measured and used during the split-sides calculation, the wire-wound pot inductance does not matter.
The 5k pot is connected to the soundcard output permanently to keep same load during calibration and measurement.
The subtracting input mode was used: R input signal minus L input signal while L input is connected to output ground. This eliminated ADC artifacts and common-mode noise, to some extent.
My very first real measurement - opamps distortion. Noniverting, unit gain, output reduced by -1dB with a voltage divider.
Images:
1. The adapter with simple opamp measurement board connected.
2. Non-compensated measurement of RC4556N at 3kHz
3. Split-compensated loopback at the same level as the previous measurement
4. Compensated measurement of RC4556N
5. Repeated compensated measurement of RC4556N
6. Compensated measurement of NE5532P
7. The tool split-compensating both sides during measurement.
Clearly NE5532P has lower distortion than RC4556N. Both distortions are way above the compensated loopback distortion.
I am glad the dirt-cheap 10-turn Bourns fake pot from ebay does the job perfectly, allowing easy setting down to a few thousands of dB. Since both voltage-divider and low-pass filter transfers are measured and used during the split-sides calculation, the wire-wound pot inductance does not matter.
The 5k pot is connected to the soundcard output permanently to keep same load during calibration and measurement.
The subtracting input mode was used: R input signal minus L input signal while L input is connected to output ground. This eliminated ADC artifacts and common-mode noise, to some extent.
Attachments
Last edited:
I've silently followed this extremely interesting thread from the beginning but now things seem to have matured to a point where it's about time to implement this with my RME ADI-2 Pro FS. Currently I have only a Puppy (Slackware) Linux installed on a old laptop, looks like I need to install a full-blown Ubuntu on my main machine to get this running, right?
I would not use less than i3, 4GB RAM. This single-channel mode where compensation runs only on one channel takes about 3 x 20% = 60% of my old xeon X5xxx core. It's good to have multiple cores to avoid potential xruns.
As of linux distribution - you need octave 5.1 and compilation stack for compiling playrec. If you can do it in puppy, why not.
Nevertheless installing Ubuntu 18.04/Mint 19 (only Ubuntu LTS versions make sense, the intermediate Ubuntu versions are betas for new features) on a 120GB SSD (20EUR brand new) takes 20 minutes.
As of linux distribution - you need octave 5.1 and compilation stack for compiling playrec. If you can do it in puppy, why not.
Nevertheless installing Ubuntu 18.04/Mint 19 (only Ubuntu LTS versions make sense, the intermediate Ubuntu versions are betas for new features) on a 120GB SSD (20EUR brand new) takes 20 minutes.
This simple adapter version is suitable for compensated measuring of non-balanced circuits. No output/input level equalization is available. Only one (fixed) output channel is calibrated/compensated.
Using only one input channel would be too much of a compromise because in single-ended measurements it is also important to subtract the ground-loop noise and/or ADC artefacts. Yet only one input channel (right channel in the diagram) needs to be calibrated/compensated, the non-calibrated/non-compensated left channel is used solely for subtracting the common-mode noise.
In measurement mode both output and input soundcard channels are available for any uncompensated usage.
Using only one input channel would be too much of a compromise because in single-ended measurements it is also important to subtract the ground-loop noise and/or ADC artefacts. Yet only one input channel (right channel in the diagram) needs to be calibrated/compensated, the non-calibrated/non-compensated left channel is used solely for subtracting the common-mode noise.
In measurement mode both output and input soundcard channels are available for any uncompensated usage.
Attachments
Last edited:
Meh, tried to install and use Ubuntu 18.04/Mint 19 but failed miserably.
I found out the hard way that 18.04 doesn't like Dell laptops like mine, overheats the hardware rather quickly (with no easy fix unless you're a total geek), causing a severe system stall (no way to shutdown gracefully, had to cut power) and when that happens in wrong moment it corrupts the file system so much that even booting in recovery mode ends with a kernel panic and no way to repair it. Game over :-(
Might try an older 16.x version instead?
Puppy Linux isn't useful either because it is so stripped down that the usual tools are simply not present (apt-get, gcc, ...). Installing anything is cumbersome with the supplied packet manager because almost everything ends up in fails with endless lists of missing libraries... I couldn't make it...
I found out the hard way that 18.04 doesn't like Dell laptops like mine, overheats the hardware rather quickly (with no easy fix unless you're a total geek), causing a severe system stall (no way to shutdown gracefully, had to cut power) and when that happens in wrong moment it corrupts the file system so much that even booting in recovery mode ends with a kernel panic and no way to repair it. Game over :-(
Might try an older 16.x version instead?
Puppy Linux isn't useful either because it is so stripped down that the usual tools are simply not present (apt-get, gcc, ...). Installing anything is cumbersome with the supplied packet manager because almost everything ends up in fails with endless lists of missing libraries... I couldn't make it...
It's a Dell Studio 1537 pp33l, 8GB RAM but only 2GHz Intel Core 2 Duo T6400 which might be on the edge of CPU power anyway.
The overheating with some Dells seems to be a known issue, has to do with the graphics chip/driver. Probably a bootable image of your system won't help, therefore.
There are ways to fix this it seems, people have managed to cope with it, but I must make sure I can step through the process in less than 20 minutes or so before the system stalls again. Being a Linux noob this is difficult, I have to google every silly simple thing
Anyway, thanks for your help!
The overheating with some Dells seems to be a known issue, has to do with the graphics chip/driver. Probably a bootable image of your system won't help, therefore.
There are ways to fix this it seems, people have managed to cope with it, but I must make sure I can step through the process in less than 20 minutes or so before the system stalls again. Being a Linux noob this is difficult, I have to google every silly simple thing
Anyway, thanks for your help!
I see, that is the old ntb you mentioned. I do not think the CPU is really up to the task, you will need 3 octave processes + arta + the system all running without xruns. I have quite bad experience with Core 2 CPUs (+ slow DDR2), they hardly keep up with modern web sites.
Is there any other machine you could use? Refurbished good brand laptops (Dell, HP, Lenovo) with i3/5 gen2/3 run at 150 EUR, with SSD/mSATA they work very nice, I use a few of them.
Is there any other machine you could use? Refurbished good brand laptops (Dell, HP, Lenovo) with i3/5 gen2/3 run at 150 EUR, with SSD/mSATA they work very nice, I use a few of them.
Make a USB stick with this one: Try it | Antergos Linux
It is Archlinux base not Debian/Ubuntu. It is a live Image you can install if you like. With that you can easy test/check if your labtop works
In antergos/archlinux is Octave 5.1 pre-build package
Last edited:
Very good.
Plus:
One terminal - octave mainPlay.m - that is the playback side
Another terminal - octave mainRec.m - that is the recording side
These two processes are sending zeromq messages to mainCtrl which controls and displays UI.
Please update the latest version (git pull).
The configs have been recently renamed to final name - configRec.m, configPlay.m (.example versions are stored in the repo).
First please configure playrec device IDs in nonlinear-compensation/configRec.m.example at master * pavhofman/nonlinear-compensation * GitHub , nonlinear-compensation/configRec.m.example at master * pavhofman/nonlinear-compensation * GitHub + the corresponding devices in the other direction nonlinear-compensation/configPlay.m.example at master * pavhofman/nonlinear-compensation * GitHub (all in .m versions, of course).
What does your octave mainListPlayrecDevs.m say?
Plus:
One terminal - octave mainPlay.m - that is the playback side
Another terminal - octave mainRec.m - that is the recording side
These two processes are sending zeromq messages to mainCtrl which controls and displays UI.
Please update the latest version (git pull).
The configs have been recently renamed to final name - configRec.m, configPlay.m (.example versions are stored in the repo).
First please configure playrec device IDs in nonlinear-compensation/configRec.m.example at master * pavhofman/nonlinear-compensation * GitHub , nonlinear-compensation/configRec.m.example at master * pavhofman/nonlinear-compensation * GitHub + the corresponding devices in the other direction nonlinear-compensation/configPlay.m.example at master * pavhofman/nonlinear-compensation * GitHub (all in .m versions, of course).
What does your octave mainListPlayrecDevs.m say?
Last edited: