REW Beta Release LineUnavailableException trying to run at 48 kHz

[dlr]

I've been using REW for a while now, was able to get it to work with a Focusrite Scarlett for the generator output with a PCI-base card for input, M-Audio Delta 1010LT that I planned to use for distortion measurements. This required the java driver, but it was fine for days (kept the PC powered). Then I changed the Scarlett sample rate from 48KHz to 96kHz. No problem. Later I switched it back to 48K and REW popped up a java error. Since then the java driver will not work with the Delta 1010LT. I've re-installed the Delta driver and updated to the latest REW (I was one behind). No luck. This is the error in the log file:

javax.sound.sampled.LineUnavailableException: EXCL: Line 1/2 (M-Audio Delta 1010LT) does not have any lines supporting PCM_SIGNED 48000.0 Hz, 32 bit, stereo, 8 bytes/frame, little-endian

I verified that the sample rate is the same in REW and the Delta control panel as well as through the Windows 10 settings.

REW is fine with the ASIO for both Scarlett and 1010LT. REW shows all of the 1010LT I/O points, but trying to select one for input or output using the java driver always fails. Any ideas as to why this would fail after working?

 

[John Mulcahy]

I've been using REW for a while now, was able to get it to work with a Focusrite Scarlett for the generator output with a PCI-base card for input, M-Audio Delta 1010LT that I planned to use for distortion measurements. This required the java driver, but it was fine for days (kept the PC powered). Then I changed the Scarlett sample rate from 48KHz to 96kHz. No problem. Later I switched it back to 48K and REW popped up a java error. Since then the java driver will not work with the Delta 1010LT.

Something in the system thinks the card is running at a different rate so the OS is refusing REW's request for a 48 kHz input. Check the Advanced tab of the properties in the Windows audio settings for both input and output to make sure both have a default format that is 48 kHz.

 

[dlr]

Something in the system thinks the card is running at a different rate so the OS is refusing REW's request for a 48 kHz input. Check the Advanced tab of the properties in the Windows audio settings for both input and output to make sure both have a default format that is 48 kHz.

I initially verified all channels through the Sound Control Panel, 2 channel, 48000 Hz. I see that REW error says 48000 32 bit, so I just manually changed to 32 bit through the Windows control panel and re-booted. No luck, same error. I had never had to make any changes when I first started using the java driver for the 1010LT. I verify the sample rate in REW/Delta control panel, but the bit rate has to be set through Windows. The odd thing is that it works without a hitch using ASIO.

Is there any way to use ASIO for each device rather than Java? I know it won't do it now, but it is actually something that can be done using ASIO?

 

[phofman]

Then I changed the Scarlett sample rate from 48KHz to 96kHz. No problem. Later I switched it back to 48K and REW popped up a java error.

How did you change that rate? If in REW, then both Scarlett and Delta were switched to the new samplerate.

When using Wasapi exclusive, it's the client (i.e. REW) which requests and sets the bit width and rate, the windows configuration is bypassed.

Does your Delta windows audio mixer configuration allow for exclusive mode to override the mixer/shared mode? If not, windows mixer can block your soundcard while REW tries to access it exclusively.

Is the clock source in Delta config set to internal, not to SPDIF input?

 

[dlr]

How did you change that rate? If in REW, then both Scarlett and Delta were switched to the new samplerate.

When using Wasapi exclusive, it's the client (i.e. REW) which requests and sets the bit width and rate, the windows configuration is bypassed.

Does your Delta windows audio mixer configuration allow for exclusive mode to override the mixer/shared mode? If not, windows mixer can block your soundcard while REW tries to access it exclusively.

Is the clock source in Delta config set to internal, not to SPDIF input?

Switching to 96k by REW worked if I recall correctly, Scarlett and 1010LT. The Delta driver has an EXCL mode for inputs available. The Delta is set up correctly, clock is internal. It had been working for a couple of days until the switch back from 96 to 48K.

I just totally uninstalled/reinstalled REW. No change. However, one thing I just noticed is that the java driver will accept selecting the 1010LT as the output device. The generator output does drive the card, it's displayed in the Delta control panel. It's only the input that won't work. The error says there are no lines supporting the requirements. But it was working before and the output works. Very strange.

I my have misremembered the earlier sequence. I see that the java driver has only 48kHz option for the Scarlett. I may have switched it in the Scarlett control to 96kHz. Just tested that The Preferences window locked this time when I switched to 96 in the Scarlett control. No response to mouse. Shortly after REW crashed on a mouse event I think.

Another test. The Scarlett set for ASIO in REW. 48kHz, confirmed in Scarlett control. I changed to 96kHz in the Scarlett control. REW remained showing 48Khz. I started the generator, ran the RTA. The bandwidth on the graph stopped at 24kHz, so somehow REW was running the Scarlett output at its indicated 48kHz despite the Scarlett control showing 96kHz. This is ASIO. It may be that the Focusrite interface doesn't actually change the rate if it's selected by REW. Making the change in REW to 48k then to 96k does change the RTA bandwidth showing 48kHz. May be a big in the Focusrite driver. But this is a separate issue that isn't a problem for me or most others I suppose.

I still can't get REW to connect for input using the java driver. Output, yes, input, no.

 

[dlr]

Also just confirmed that using ASIO that REW changes the Delta sample rate. There are no issues with ASIO. It's all in java.

 

[phofman]

The Delta driver has an EXCL mode for inputs available.

The Delta controller cannot run output and input at different rates. Therefore, should the output be used by windows mixer and switched to some rate, the input (via exclusive) will not allow using a different rate. Even if the input is allowed for exclusive mode.

I see that the java driver has only 48kHz option for the Scarlett. I may have switched it in the Scarlett control to 96kHz.

REW cannot set rate for either the input or output device. When you say "for the Scarlett", does it mean there is Scarlett set for both capture and playback?

My 2 cents the Delta is used by windows mixer, maybe the playback, and runs at a different rate than you want the capture from REW to run.

 

[dlr]

The Delta controller cannot run output and input at different rates. Therefore, should the output be used by windows mixer and switched to some rate, the input (via exclusive) will not allow using a different rate. Even if the input is allowed for exclusive mode.

That could be an issue, but I had been using the two interfaces simultaneously. The change I made was the sample rate of the Scarlett, not the 1010LT. Edit: I hadn't considered that the two devices may not be able to run at different rates. But resetting rates should have fixed it if that was the issue.

REW cannot set rate for either the input or output device. When you say "for the Scarlett", does it mean there is Scarlett set for both capture and playback?

In REW, if you select ASIO, then both I/O can only be the single device selected. Both cards work fine that way. The java driver allows mixing with input on one, output on another. The problem is that no matter what changes I try (card controller and through Windows), REW reports that the 1010LT has no lines supporting the settings it lists: PCM_SIGNED 48000.0 Hz, 32 bit, stereo, 8 bytes/frame, little-endian.

I also found that the shared vs exclusive inputs show the same error with the exception that the shared error says 16 bit, the exclusive says 32 bit. In Windows sound control I've tried both. Default in Windows seems to be 24 bit.

My 2 cents the Delta is used by windows mixer, maybe the playback, and runs at a different rate than you want the capture from REW to run.

John said it looks like a mismatch on 48kHz format, but I've tried numerous times setting all to 48Khz with the same bit depth. If I have not luck, I do have a spare SSD. This system is dedicated as a measurement system, so I may try a clean install of Windows. My thought was that something in Windows got changed that I can't fix.

 

[dlr]

The Delta controller cannot run output and input at different rates. Therefore, should the output be used by windows mixer and switched to some rate, the input (via exclusive) will not allow using a different rate. Even if the input is allowed for exclusive mode.


REW cannot set rate for either the input or output device. When you say "for the Scarlett", does it mean there is Scarlett set for both capture and playback?

My 2 cents the Delta is used by windows mixer, maybe the playback, and runs at a different rate than you want the capture from REW to run.

This is interesting. As a test I set the output device to Delta 1010LT, input to Scarlett 2i2. It works. REW accepted it that way, I used an RCA/TRS adaptor (1010LT has only single ended output) to verify functioning. But when I do the inverse, the way I need it, REW rejects the 1010LT as input. With the output not set (default), it will not accept any 1010LT, either.

 

[John Mulcahy]

You could try FlexASIO with the delta/Scarlett combination to see if that works.

 

[phofman]

But when I do the inverse, the way I need it, REW rejects the 1010LT as input.

Do you have Delta input switched to analog in the Delta config GUI (not the windows mixer)? Are you sure it's not switched to SPDIF input?

I have played with quite a few Envy24-based soundcards in linux and worked on linux drivers for them. The controller is quite capable, but needs to be switched correctly. Please post pictures of the UI control tabs as described in https://imagescdn.juno.co.uk/manual/386417-01U.pdf.

IMO a dedicated thread would be better, to avoid off-topics in this one.

 

[dlr]

You could try FlexASIO with the delta/Scarlett combination to see if that works.

I installed that more to test if it works well in REW. Seems a bit flakey, rather slow responses. I wouldn't want to rely on it. It is seen as a version of ASIO in REW, so it requires selecting the ASIO Drivers option in REW. That then locks input and output to the same device. The Java driver is required to use different cards for I/O. I'm still puzzled by why Java works with the Delta as output and the Scarlett as input, but no longer vice-versa. It had been completely stable until my goof in changing the sample rate for the Delta output (I think using the Delta controller). Since then, it won't accept the Delta inputs at all using Java. Works properly using ASIO.

On an uninstall of REW is there anything Java not removed? I keep thinking that Java or Windows is the problem. If I can't resolve this, I'll install Windows on my spare SSD for a clean start.

Ref. my earlier question about an option to use two cards through ASIO, I tested a SW package called Multitone Analyzer. The selection for input or output simply lists all interface I/O driver options. It works for Scarlett output and Delta input using ASIO. I had ensured that both devices and Windows were all set to the same sample rate. However, I want to use REW as it has far more capabilities and the interface and output options are superb. No doubt it would require a lot of change to REW to add such an option and I may be one of only a few who might use it, but I thought I'd ask for your opinion on the feasibility of that at some point.

 

[dlr]

Do you have Delta input switched to analog in the Delta config GUI (not the windows mixer)? Are you sure it's not switched to SPDIF input?

The first thing I do when something doesn't work is verify all settings.

I have played with quite a few Envy24-based soundcards in linux and worked on linux drivers for them. The controller is quite capable, but needs to be switched correctly. Please post pictures of the UI control tabs as described in https://imagescdn.juno.co.uk/manual/386417-01U.pdf.

Again, it works with the Scarlett as output and the Delta as input, so it's not the settings. It had been working for a couple of days.

IMO a dedicated thread would be better, to avoid off-topics in this one.

Yes, glad to see that. I hadn't expected my entry into the thread to go as it has.

 

[John Mulcahy]

That then locks input and output to the same device.

No, it doesn't. The 'device' is FlexASIO itself, in the FlexASIO control panel REW provides you choose the underlying devices to use for input and output.

 

[dlr]

I stand corrected. Not sure what I did wrong the first time, must have only selected ASIO. I removed it, so I've reinstalled. Doing some testing with selections/settings, it does work now. At first it was glitching with a definite period like a buffer issue. It does slow down the interface. Make some selection in REW and you have to wait.

Stepped THD won't work at all. Same for calibration. After some delay both result in a popup indicating the soundcard did not provide any input data ASIO:ASIO4ALL...

The PC is an old Xeon E3, a 4-core 8-thread @3.4GHz, but I doubt that the hardware response is the problem. I tried setting ASIO4ALL for lower latency with no success. What's most frustrating is no Stepped THD, my primary need. If I recall correctly, when the Java driver was working I could set the Lock frequency to RTA and use the Rectangular window despite being separate physical units, as long as the sample rate was set identically. The harmonic distortion components were more accurate, I think. With ASIO4ALL the only way to measure distortion is against frequency in the RTA window using the Blackman-Harris 7 window.

Any test in the generator can be made, but nothing stepped.

ASIO4ALL is inconsistent as well. Even in Preferences the Check Levels function fails most of the with the same error. It initially shows the inputs at low level, black for the generator. After a short time it errors out. Every once in a while it will complete the check. Similar issue with calibrate.

At this point it doesn't give me a lot of confidence. IF one only needs the generator signals and no calibration nor stepped THD it's usable. Otherwise, not in my experience.

I'll try a clean install of Windows 10.

 

[phofman]

ASIO4ALL is inconsistent as well. Even in Preferences the Check Levels function fails most of the with the same error. It initially shows the inputs at low level, black for the generator. After a short time it errors out.

Standard ASIO is designed to use synchronously-running input and output. ASIO4All and FlexASIO emulators allow connecting each side to a different Wasapi/WDM device, but that requirement still holds. But most separate soundcards do not run synchronously (unless special precautions available for some soundcards only are provided). Therefore, using different capture and playback devices joined into ASIO calls will inevitably cause buffer under/overruns. The time until first issue is only the function of buffer size and the clock difference between the two devices.

As of your WASAPI excl issue - I really would prefer to see the Delta config screenshots. Also debug logs as described in https://www.avnirvana.com/threads/v5-20-10-early-access.10787/page-5#post-82326 would likely show what formats are reported by the Delta capture side.

 

[dlr]

Standard ASIO is designed to use synchronously-running input and output. ASIO4All and FlexASIO emulators allow connecting each side to a different Wasapi/WDM device, but that requirement still holds. But most separate soundcards do not run synchronously (unless special precautions available for some soundcards only are provided). Therefore, using different capture and playback devices joined into ASIO calls will inevitably cause buffer under/overruns. The time until first issue is only the function of buffer size and the clock difference between the two devices.

I installed another SSD with Windows 10. At first I was able to get REW to work using ASIO4ALL with stepped THD, but the results are garbage. I then ran the calibration. REW calculated the clock difference (kudos to REW) and that it can be saved in a cal file. But the cal file produced is garbage. The popup indicates it's to be used in the "Analysis" option that I don't use. I don't know if it's used in stepped THD or other tests.

And since I was trying other ways to set up for REW input using ASIO4ALL it is now just as the first Windows OS install. It says that the sound card did not provide input. ASIO4ALL just doesn't want to work properly with the Delta drivers, admittedly very old.

As a test I ran the Scarlett input and output using java. It calibrates perfectly, so the issue is evidently the old Delta driver has ASIO, but the api for Java isn't working reliably.

The Delta driver ASIO works well in Windows 10. Again, the Multitone Analyzer (MA) works fine with the cards simultaneously, but REW is my preferred software. In fact, even in MA the WASAPI option fails. The problem isn't REW, it's the Delta driver. Hence my query about a possible update (at some point) in REW to use ASIO directly for each card. But I suspect that's not likely to be reasonable given what I suspect would be the re-work required.

I am investigating other options such as FlexASIO> I'll report back if I have any success with other option(s). Mean time, I think I need to evaluate whether or not the Scarlett 2i2 only will work. The issue is that the output is very good, but the input as voltage increases at some point has significant increase in harmonic distortion components. The Delta is almost flat in that regard up to it's max input and at the upper voltage range is lower than the Scarlett.

 

[dlr]

I observed an odd thing that is probably related. Using ASIO4ALL for only the Scarlett, but with one Scarlett output line connected to the 1010LT input I noticed that REW Out was continuous, but both the Scarlett and 1010LT inputs had periodic total dropouts roughly on an 8-12 second on-period. Then about 4 seconds later the inputs would show signal again. REW thinks the output is constant, but evidently ASIO4ALL or somewhere in the path there is something not continuous. I've tried to find it in Windows, but can't identify the process(es).

 

[John Mulcahy]

Pretty unusual loopback measurement, I have never seen a result that slopes throughout the frequency range like that.

 

[dlr]

Pretty unusual loopback measurement, I have never seen a result that slopes throughout the frequency range like that.

Yes, very odd. When I run the cal function the sweep graph that shows headroom to the side starts the rise delayed and rises slowly, never fully reaching a plateau. It must be related to ASIO4ALL. Calibration of Focusrite and Delta cards using ASIO is exactly as one would expect.

 

[dlr]

The problem seems to be the slow response of ASIO4ALL. No doubt there must already be delay between output-to-input,although small. Going back to the problem I recently observed, when using ASIO4ALL there is always about a four second delay after starting the generator before any input appears on either Scarlett or Delta card regardless of the input. If I/O is only Scarlett, the delay remain, so it can't be the Delta driver now that I see this. It's almost immediate with the ASIO drivers.

 

[dlr]

I installed FlexASIO. It does work, though also limited. It does not have the periodic dropouts of the output that ASIO4ALL had. It's also able to run a calibration, but the result is similar, not usable. It has a similar sloping highpass for almost the entire bandwidth. Running functions within the RTA window are improved, may be reliable. The input results for the 1010LT appear to be near its spec for distortion. That is what I would expect given that the Scarlett output THD+N is rated -109dB, well enough below that of the 1010LT. The 1010LT is "THD -96dB", evidently not THD+N as noise is rather high in it, but that spec appears to be for the single ended inputs. I suspect that the balanced input is better, but that's a guess. However, running the FlexASIO Scarlett-to-1010LT shows the 1010LT input noise floor to be close to -100dBFS. The THD is (guessing) around -96dBFS which is exactly the spec for 0dBFS, although the test input is around -25.7dBFS according to REW. I set the Scarlett generator to -25.52dBFS because that was the output driving the Fosi V3 Mono to 2.83V with the Scarlett Output dial set to max.

There are four options in FlexASIO. Driver types "Windows WDM-KS" and "Wasapi" worked nearly identically for a 1kHz generator tone distortion test in the RTA window. The other two crashed the FlexASIO driver.

The Stepped THD will run using FlexASIO. The harmonic results seem reasonable, but since it's the combination of Scarlett and 1010LT harmonics, it's not definitive. But the values are good, better than those for either device in pure loopback mode. This was the goal, to use Scarlett generator that is very good to the 1010LT input that is good. This obviates the issue with the Scarlett input harmonics that increase at higher output levels. The 1010LT harmonics are fairly constant through the whole bandwidth. I would think that the data would be better if the calibration would run without a hitch.

If nothing else, I've learned a lot during this exercise.

When I have some time I'll post some of the graph captures.

 

[phofman]

The problem seems to be the slow response of ASIO4ALL. No doubt there must already be delay between output-to-input,although small. Going back to the problem I recently observed, when using ASIO4ALL there is always about a four second delay after starting the generator before any input appears on either Scarlett or Delta card regardless of the input. If I/O is only Scarlett, the delay remain, so it can't be the Delta driver now that I see this. It's almost immediate with the ASIO drivers.

Calculate the overall lengt of all buffers in that chain. Very likely you will get the delay you experience.

FlexASIO and Asio4All share the same principle - merging two async-running devices into one ASIO duplex call. They both will inevitably have buffer issues, sooner or later. The only method for REW which supports independent capture and playback devices in windows is Wasapi. Wasapi exclusive should and I dare to say will work if the chain is configured correctly.

You provided neither the configuration screenshots, nor the REW wasapi-excl adapter debug logs which would show what available params the soundcards actually report. All the other tests are just trial error which lead to nowhere. Only proper step-by-step diagnostics is the way forward.

 

[dlr]

Calculate the overall lengt of all buffers in that chain. Very likely you will get the delay you experience.

I've used the Delta cards for over 15 years, I know the options and have tried with the Delta buffer at minimum. The Scarlett control panel has no option for buffer change, it's minimal in all ways. The FlexASIO is set for Wasapi exclusive with the minimal buffer size, the control panel is not compicated. At this point there is no way to further reduce the total buffer length, although I've recently found a github app called FlexASIO_GUI that may provide more options. I plan to test that. The description says it's to make FlexASIO changes quicker, but the screen shows additional buffer and latency options not available in the FlexASIO control panel.

FlexASIO and Asio4All share the same principle - merging two async-running devices into one ASIO duplex call. They both will inevitably have buffer issues, sooner or later. The only method for REW which supports independent capture and playback devices in windows is Wasapi. Wasapi exclusive should and I dare to say will work if the chain is configured correctly.

The fact that in FlexASIO the WDM-KS driver functions essentially identically to the Wasapi Exclusive indicates otherwise. Microsoft describes WDM-KS as being kernel mode, so it may be the equivalent to Wasapi, that I can't say, but I can say that its results are equivalent to Wasapi. Just as for Wasapi, all of the RTA functions I've tested work equally well in both. Stepped functions and calibration seem to be the issues. Maybe John could enlighten us on that.

Here's a description:

Kernel mode: WDM audio drivers use the kernel streaming (KS) components, which operate in kernel mode. WASAPI Exclusive is similar to kernel streaming in function, but no kernel mode programming is required.

You provided neither the configuration screenshots, nor the REW wasapi-excl adapter debug logs which would show what available params the soundcards actually report. All the other tests are just trial error which lead to nowhere. Only proper step-by-step diagnostics is the way forward.

I'll find and examine the debug logs, but there are no other options in any of the device settings on my end that can improve the buffer/delay situation. If a change could be made in REW, that's another story.

I suspect that the problem may lie in the fact the Scarlett is USB. I suppose I could make a test with the motherboard audio output rather than the Scarlett to see what change may result. That would be interesting just on an academic level.

Edit: At this point ASIO4ALL is a dead end. For my use anyway.

 

[dlr]

One correction. I found that the Scarlett does have a settings control separate from the main control that allows buffer size changes. I tried various buffer sizes to no benefit. It even displays the round trip latency for buffer settings, but this if for a loopback of only the Scarlett.