REW Beta Release LineUnavailableException trying to run at 48 kHz

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
I ran a test using the motherboard onboard sound out to the 1010LT input. The calibration and stepped THD ran successfully. The distortion levels are seriously bad, this is a very old PC, but it works using the FlexASIO WDM-KS driver. When I tested FlexASIO with the Scarlett only, full I/O, it worked. But switching back to the Scarlet-1010LT started having an error that I still cannot eliminate, "Unable to start ASIO capture". Rebooting does not help. Yet WDM-KS driver still does. It seems that once something causes a problem with Wasapi in Windows, it doesn't recover. So I'm testing using the FlexASIO WDM-KS driver now. It never fails.

It looks like the problem using Scarlett-to-1010LT is related to USB. REW must time out on input due to delay in the output from the Scarlett on USB.
 

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
I shouldn't say time out in REW. It does run the calibration, but there's something wrong with the data transfer. Still seems related to USB or possibly the Scarlett itself.
 
Last edited:

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
FlexASIO using the WDM-KS driver is very stable. It reproduced the results I'd had early on, but they weren't correct as I thought. this is a loopback test from Scarlett to 1010LT at -25dBFS (the -20 was a mistake). They were too good.
48k FlexASIO WDM-KS THD vs Freq Scarlett -25dBFS to 1010LT.png
 

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
Calibration in REW will complete now with small tweaking in the FlexASIO_GUI app. The result is still far from linear, but I created a calibration file from that. Subsequent loopback measurements of Scarlett-to-1010LT look close to what I expected. I would like to ask John for his thoughts as to how/why it could be this way. When the calibrtion is run, the run-time graph rises quickly at first and appears to asymptote to the top.
Scarlett 2i2 to 1010LT FlexASIO WDM-KS Calibration.png
 

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
Subsequent loopback measurements using the cal file look reasonable.
48k FlexASIO WDM-KS THD vs Freq Scarlett -3dBFS to 1010LT Calibrated B-H4.png
48k FlexASIO WDM-KS THD vs Freq Scarlett -12dBFS to 1010LT Calibrated B-H4.png
48k FlexASIO WDM-KS THD vs Freq Scarlett -15dBFS to 1010LT Calibrated B-H4.png
48k FlexASIO WDM-KS THD vs Freq Scarlett -20dBFS to 1010LT Calibrated B-H4.png
48k FlexASIO WDM-KS THD vs Freq Scarlett -25dBFS to 1010LT Calibrated B-H4.png
 
Last edited:

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
Loopback tests of the 1010LT only show that the noise is rather high, but the harmonic distortion components are rather constant across the bandwidth. On the contrary Scarlett loopback tests show that above about -20dBFS the harmonic components increase rather dramatically, in particular the 2nd and 3rd.. This is borne out in the Scarlett-to-1010LT loopbacks above. I had thought that the Scarlett output distortion was more stable as output increased than it appears to be.

FlexASIO is evidently the best option if two audio processors are desirable to be used simultaneously as in my case. But there is still the question of the impact of the calibration. Subsequent loopback measurement run using the cal file does result in a perfectly flat 20-20kHz response.
Scarlett 2i2 to 1010LT FlexASIO WDM-KS Calibration using Cal file.png
 
Last edited:

phofman

Member
Joined
Jun 26, 2019
Posts
186
There are no technical reasons why one method should produce different measurements to another method, provided both are bit perfect. ASIO through FlexASIO to Wasapi exclusive is just as bitperfect as java Wasapi exclusive itself - the same final destination, just complicated with the ASIO API callbacks in case of FlexASIO.

My 2 cents: your FlexAsio is not configured for Wasapi exclusive, it uses shared mode through the windows mixer which resamples for 1010LT running at some different samplerate, at which it is locked (would be visible in the config screens). That may also explain the uneven frequency response. As I said, the wasapi excl. debug logs would have most likely revealed what was going on as they list all formats/rates reported by the soundcard as supported. Neither the debug logs nor the config screens were posted here. FlexAsio just adds a redundant level of complexity.
 
Last edited:

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
I've continued to pursue this. FlexASIO worked using the WDM-KS driver, but stopped working with the Wasapi backend. Evidently the two have different internal paths to the sound card despite the fact that they both bypass the Windows settings.

I also switched all settings to 44.1kHz sample rate thinking that might be less susceptible to settings issues. When that still failed Wasapi in REW I made another test using the Multitone Analyzer. I found that despite confirming the rate in the Delta and Scarlett control panels, the Delta rates were in conflict even with the Delta I/O. I'll attach a capture of it so show settings in the cards and the error shown in the app. IT has the benefit of displaying all channel options simultaneously for all available drivers. It seems to confirm my thought that something got screwed up in Windows and wasn't changing in the Wasapi path even after a reboot. WDM-KS never failed, ever.

I eventurally solved that by installing FlexASIO_GUI. It ostensibly does nothing more than the FlexASIO control panel, but afterwards the Wasapi backend started working again in REW. I can't recall exact sequence of events as I spent considerable time with many changes/verifications. But the Wasapi driver has since been stable in REW.

Subsequent posts will have more info.
 

Attachments

  • Sample rate irregularities.png
    Sample rate irregularities.png
    83.5 KB · Views: 11

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
The captures I'll show here are what occurs in REW when I run a calibration with Scarlett output to 1010LT input. It's perfectly repeatable, every time, no matter the output dB setting. There's a roughly 5db variation 20-20kHz. I'm posting these in the hope that John may see something to investigate. There are two captures, one showing a calibration directly, the other when I used Eq-APO to linearize the calibration. I did this to compare the result against a measurement with a calibration file. The end result was a nearly identical result.

This is the run of the raw calibration window of Scarlett to 1010LT.
Calibration irregularity input sweep.png


This is the calibration window with the Eq-APO that linearized the Scarlett output. It's gain across the 20-20k bandwidth to a nearly flat response, essentially the same thing that a calibration file would provide. The problem is that the added gain across the bandwidth causes excessive distortion results.

Calibration window FlexASIO_GUI Wasapi 44.1k EqAPO input sweep.png


The gradual slope is consistent and always precisely the same each time. The resultant FR overlays are perfect.
 
Last edited:

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
In comparison, these are the results of direct loopback calibrations of the Scarlett and 1010LT at different sample rates to show that there's no issue with either one individually. The 1010LT has an issue with 96k (the card is over 20 years old), so I show the 88k. At some point I'll be replacing all caps on the 1010LT, that may be the issue with 96k. But all other rates calibrate nearly identically.

Note that the 1010LT loopback is for the single ended loop. The card only has a balanced input, no balanced output unfortunately. But I planned on using the Scarlett for output. Testing is still pointing to the Scarlett being a USB card. I have no other USB card to test this hypothesis.
Loopback measurements of Scarlett 2i2 and Delta 1010LT.png


What makes it seem more likely that the issue lies with USB is the result of doing a calibration using the motherboard sound output to the 1010LT input (single ended). The result is surprisingly good (disregarding later distortion tests I ran). There is not even an extra cable needed, the motherboard output can be directly connected to the short 1010LT input RCA cable. It confirms that using two different cards works well. This used the Wasapi exclusive drivers for both.
44.1k Cal Motherboard-to-1010LT FlexASIO Wasapi dBr.png
 

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
I turned on logging in REW and FlexASIO and examined the logs as well. At first the discrepancy in sample rate was apparent. But this only prevented the Wasapi driver from working after it failed in REW, ASIO still worked in other software. After the fix I mentioned above that still does not result in a good calibration, I examined the logs again and took time to try to separate sections with spacing. Nothing I could find shed any light on the problem. I'm attaching the log files here. This is after switching all to 44.1kHz with no sample rate issues. I also ensured that Wasapi Exclusive was always set except when using Eq-APO that requires non-exclusive access for the output.
 

Attachments

  • REW soundcard_debug.txt
    66.2 KB · Views: 8
  • FlexASIO.log.txt
    297.6 KB · Views: 7
  • FlexASIO.toml.txt
    252 bytes · Views: 7

phofman

Member
Joined
Jun 26, 2019
Posts
186
I got lost in your reports. Nevertheless the logs suggest the LT1010 exclusive access (i.e. directly to the driver) supports only 44.1kHz. That would hint at the locked rate I talked about - the windows driver user guide does show the checkbox for locking the rate - but the setup screenshots I asked about were never posted here...
 

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
I got lost in your reports. Nevertheless the logs suggest the LT1010 exclusive access (i.e. directly to the driver) supports only 44.1kHz. That would hint at the locked rate I talked about - the windows driver user guide does show the checkbox for locking the rate - but the setup screenshots I asked about were never posted here...
What setup screen shots are referring to that I haven't posted? I just supplied what you initially requested in post 16. I just ran a calibration in REW at 88 and 96kHz using the Delta ASIO drivers. Regardless of whether or not the 1010LT driver supports exclusive mode only at 44.1k what I just posted with the log files was for all the latest testing at 44.1k to eliminate any higher rate issues so it's not related to exclusive mode use. As I said, I've always ensured that exclusive mode was set. It's also unrelated to buffer size (I've tried every possible range setting). Unlikely related to clock issues since I tested the combination of motherboard output to 1010LT input. Two clocks, works perfectly. I posted that screen capture earlier.

Process of elimination. I've tried essentially every possible combination I can figure out. Changing a single item at a time.

To repeat, when using the FlexASIO (first suggested by John) the WDM-KS driver never failed to run in REW, though the Wasapi did. WDM-KS is described by Microsoft as kernel mode and my understanding of that is that both Wasapi exclusive and WDM-KS are essentially the same only using different coding to implement. Wasapi may take a different path to the card, that's my take on it. The exclusive setting bypasses most of the Windows code.

This is the 96kHz calibration in REW. I doubt it's not in exclusive mode through the Delta driver, but since this is for the same I/O device and the Delta control panel does not provide anything specific to exclusive or not it may not show anything helpful. The REW generator did have the check box for Lock Frequency to RTA FFT set, though it may be only a requirement for most accurate THD vs Level. Still details in REW that I haven't dug into thoroughly.

I still suspect that it has to do with USB. That's the single factor significantly different in all combinations.

Delta 1010LT 96kHz ASIO Exclusive Single Ended Loopback Calibration -6dBFS.png
 

phofman

Member
Joined
Jun 26, 2019
Posts
186
I got lost in what is the problem you are trying to solve, sorry.

I am talking about screenshot of this setup

1731395605511.png


FlexASIO logs when using WDM-KS backend would likely help to see the difference between wasapi excl. and wdm-ks as called by the Portaudio library used by FlexASIO. You can ask FlexASIO author, recently he has been active in Portaudio WDM-KS source code too https://github.com/PortAudio/portaudio/commits/master/src/hostapi/wdmks .
 
Last edited:

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
I understand your confusion. That control panel is the old one. I think it used the drivers for Win98 and maybe worked in Windows 7, I recall seeing that one. However, the (partial) one I showed in the attachment in Post #34 is the current one that is in Windows 10. I had planned to use an old Windows 7 PC with the Scarlett. However, I purchased the 2i2 Gen 4 that only has drivers available for Window 10 and later, so I was forced to move to Windows 10. The Delta driver installed is the only one I found that would work in Windows 10. This is the new Delta control panel. Note the check box for "disable asio direct monitoring". I have tried it both ways. It makes no change in REW. Also had the mode to Professional in the other Windows 10 SSD, forgot to set that here. I just tested that, makes no difference in REW, either. Same 5db highpass slope in calibration Scarlett-to-1010LT. It may be that the mode setting only affects the output, but I'm only using the input.

Windows 10 M-Audio Delta Control Panel.png


Also, recall that running calibration in REW, whether 44.1K or any other rate, results in exactly the same response. Every time. In the overlay screen for multiple runs of any option settings results are perfect overlays. It's not sample rate related. REW calibration is as expected for any card uniquely and for when using the motherboard output to 1010LT input. The one and only problem is with the Scarlett USB in the mix.

Edit: Just realized that the mode setting is only for spdif anyway, so unrelated as well.
 
Last edited:

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
FlexASIO logs when using WDM-KS backend would likely help to see the difference between wasapi excl. and wdm-ks as called by the Portaudio library used by FlexASIO. You can ask FlexASIO author, recently he has been active in Portaudio WDM-KS source code too https://github.com/PortAudio/portaudio/commits/master/src/hostapi/wdmks .
I had considered that, will look into it some, but given that with proper settings that the Wasapi exclusive now works and produces the same result as WDM-KS I wouldn't expect to see anything different. It's not as if WDM-KS produces expected results and Wasapi does not. Neither one of them provides the expected result in REW when the USB device is in the mix.
 

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
The github repository for PortAudio has useful information, it only for making it more clear the differences in Wasapi and WDM-KS. So Wasapi is considered high-level API.
Usually you access audio via high-level APIs such as DirectSound, WMME or WASAPI. WDM/KS is refers to directly accessing kernel audio drivers from user space.
API's like WMME, DirectSound and WASAPI are implemented on top of WDM/KS (Kernel Streaming) but you can also talk to WDM directly from user space.
This is then why I was able to insert Eq-APO into the Wasapi path.

Also found another interesting comment in the MusicBee forum, though it may not be relevant to my problem.
I find it very strange that you said your Windows only supports 48khz, I think you meant that was the sampling rate set in the Device properties (Control panel/Sound/properties/Advanced). Wasapi-exclusive will ignore that setting and send whatever the audio file's original sample rate is to your audio drivers, whether it's 44.1k or 192k. What this means though is that your audio device must be able to support the rates of your files. E.g., my device supports 44.1, 48, 96, and 192k. In the BASS audio engine world, if my device gets sent a sample rate it does not support, for example a 22.05k radio stream, bass.dll will "kick in" and internally resample that to a supported rate, i.e. 44.1k. Otherwise, you would have no audio output.
 

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
More process of elimination. The 1010LT has no balanced output, so I made an RCA-to-Balanced connection since I knew that the 1010LT unbalanced calibration was fine. This allowed me to test whether or not the USB link was a problem. To my surprise, the result was what one would expect. The signal level into the Scarlett is low, the motherboard output level 0db is 1V and of course the Scarlett input is half what one would get with a full balanced input of 1V. Distortion is awful, but not of consequence. What is of consequence is the 20-20k fundamental response. It was nearly flat, within 0 to -0.2db.

That prompted me to then connect Scarlett (balanced) to 1010LT unbalanced. Again, the response was again as one would expect.

My problem all along may be that something is failing on the 1010LT card for the balanced input, something I had not considered until now. The unbalanced I/O is fine. I have a second board to swap and test. If that has the same issue with the balanced input then I would have to conclude that there's an issue with the driver for the balanced input. It's all puzzling and frustrating, but at least I may be able to zero in on the real issue. My thought that the USB connection was the problem is evidently wrong.
 

dlr

New Member
Thread Starter
Joined
Jul 20, 2024
Posts
36
I installed the other 1010LT I have. It works as expected. Running a cal results in +0/-0.5 20-20kHz. The first card balanced input definitely was the problem. The same balanced I/O channels are used for microphone or line input that require card jumpers changed if they are to be used for line input. It may be that the original owner (both these I bought used) damaged the balanced input. The unbalanced were all good. Swapping cards should have been my first troubleshooting effort.
 
Top Bottom