Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ppataki]

I have been using the WDM driver for a long time and I love it - for me that is one of the most valuable features in JRiver

I have recently noticed that if I play 192kHz content (from Tidal) the audio starts stuttering immensely (totally unlistenable)
There is no issue with content up to 96kHz though

Does anybody else have the same problem?
I hope this can be solved
Thank you

[JimH]

Make sure Windows Defender is configured.  Don't use anything else for antivirus.

WDM should work.

Anything else unusual about your setup?

[mattkhan]

Look at the buffers used for the output device, look at CPU load in MC

I don't think it's that unusual for live input in MC to have audio glitches, it is quite sensitive to load

[ppataki]

I am using Windows Defender only, no other AV software

CPU load when playing 96kHZ content is 6%, when playing 192kHz content it is 8% so that shall definitely not be an issue
No matter what value I set for the buffering the stuttering is all the same

Not sure what counts as unusual I have Dirac Live and Metaplugin VST3 plugins + using a bunch of JRiver's built-in DSP capabilities

[ppataki]

Forgot to add that I have the very same issue with my home office system too
There I use a laptop but again the CPU load is not an issue either

[JimH]

It could also be limited by bandwidth. 

[Manfred]

Do you use WiFi from the Router to your Laptop/PC?
- Then may be as JimH noticed bandwidth could be an issue.

Do you use WiFi to stream from your Laptop/PC to a streamer?
- Many Streamers using WiFi for playback are limited to 96kHz PCM, e.g. my Devialet.

[mattkhan]

isn't this tidal on the same pc playing through WDM to MC and then straight out to an output device connected to the same PC?


what happens if you disable the VST and/or jriver DSP? does it still stutter?

[ppataki]

My PC is the only source and I use wifi, see my Speedtest attached; I doubt that it is a bandwidth related issue

isn't this tidal on the same pc playing through WDM to MC and then straight out to an output device connected to the same PC?
Yes it is

If I disable all the JRiver and all the VST plugins the issue is still there

[JimH]

The speed test tests your speed from some Internet server but not from Tidal.

Other processing may slow it down a lot.

Try testing without MC.

Test without Wi-fi.

[mattkhan]

I can't see what wifi has to do with this, I would think this is driven by something in the WDM driver which doesn't, as far as I know, expose any controls for configuring buffers etc

as I said before, it is v sensitive to what you put into it and which devices it interacts with

@ppataki a test you might want to try is using https://vb-audio.com/Matrix/ as an alternative mechanism to get audio into MC (i.e. route tidal through here to a virtual asio device and then use that virtual asio device as an asio line in input), this would be one way to narrow down the problem to the wdm driver

another alternative, grab HLC (https://accuratesound.ca/hang-loose-convolver-hlc/) and use the free trial with the same DSP pipeline configured in it and see if that is reliable or not

what's the output device and how is it configured?

[Awesome Donkey]

Hasn't this issue with stuttering and the WDM driver been reported by some users since day one? I seem to recall this type of thing was reported multiple times over the years when trying to use high sample rate (e.g. 192 kHz) content like Tidal with the WDM driver and one of the potential workarounds to stutter issues was to mess with buffer settings. What's the specs of the PC you're using? Maybe it's running into a resource issue?

https://yabb.jriver.com/interact/index.php?topic=116637.0
https://yabb.jriver.com/interact/index.php?topic=127251.0

[ppataki]

I have exactly the same issue that the others have reported in those earlier threads
In this case I guess the proper solution shall be to fix the WDM driver so that it works fine with higher sample rates too

I have a PC with an Intel Core i5-13400 and 32GB of RAM - it shall not be a resource issue for sure

[mattkhan]

another test, eliminate tidal from the equation and play a 192kHz file via some other playback software and see if it still glitches. If it does, you can rule tidal out of the equation.

fwiw I ran a quick test by playing https://www.audiocheck.net/download.php?filename=Audio/audiocheck.net_pink_192k_-3dBFS.wav via MPC-HC through WDM and out to my usual output device (https://en.antelopeaudio.com/products/orion-studio-synergy-core/ connected via TB) without any glitches, audio path attached to illustrate

I don't use tidal so can't easily test that but you can see that there's no  generic issue with higher sample rates (otherwise it would fail for me)

[JimH]

In this case I guess the proper solution shall be to fix the WDM driver so that it works fine with higher sample rates too

I can guarantee you that the problem is not the WDM driver.  It has worked well for a long time.

[ppataki]

I have tried MPC-HC and that worked fine. The 192kHz file was playing fine locally.

I was wondering if there was an option to be able to change the buffer size for the WDM driver, would that help?

[Awesome Donkey]

Maybe something (Tidal app itself, perhaps?) is causing a spike in DPC latency which is only apparent when accessing Tidal Max (192 kHz) content through the WDM driver? LatencyMon might be helpful in that case.

It's been years since I've seen this issue mentioned since Hendrik made changes to the WDM driver that seemingly addressed this issue. Anyone else who uses Tidal with the WDM driver experiencing anything like this?

[mattkhan]

WDM device is configured for exclusive mode?

Did you try the test with a virtual asio device and asio line in?

[ppataki]

The WDM device has exclusive mode turned on (see attachment)
And Tidal is also using Exclusive mode (see attachment)

Unfortunately I could not try VB-Audio, to be honest it is a bit above my head how to configure it properly

Regarding LatencyMon, see the attachment for both 44.1Khz and 192kHz playback
DPC is indeed way higher with 192kHz and the count of hard pagefault is sky-rocketing

[Awesome Donkey]

Try setting the WDM driver in Windows to 192000 Hz from 48000 Hz and see if that changes anything.

[ppataki]

Try setting the WDM driver in Windows to 192000 Hz from 48000 Hz and see if that changes anything.

Unfortunately not, it is the same

[JimH]

It won't work to have exclusive mode set in two applications.  Exclusive mode means that the app has control of the audio.

[ppataki]

Exclusive mode is enabled in Tidal, there is no second app

[Matt]

You could try increasing the buffering MC is using in Options > Audio > Device settings...

[ppataki]

I have tried adjusting it here (attached), it actually gets worse

[ppataki]

I guess we would need an option to change the buffer size of the WDM device itself

[AGAWA]

am i right thinking that USBStreamer is an interface between PC and some DAC? If so, perhaps it will be worth trying to remove this unit and see if problem disappears. Not long ago there was similar problem  and interface unit was returned to manufacturer.

[ppataki]

I have mentioned in one of the above posts that I have another system as well where I have exactly the same issue - and it has no USBStreamer (which is actually a miniDSP UDIO-8)

[Awesome Donkey]

It's probably going to be hard to diagnose a cause for this one (unless others can reproduce it), because according to LatencyMon Windows' DirectX kernel module is causing DPC latency spikes (which may be hard in itself to hunt down a cause). I don't think the cause is the WDM driver itself because it's been years since anyone reported that (and Hendrik made fixes to it that seemingly made the issues go away). DPC latency spikes can cause stuttering issues with audio, not just when using the WDM driver and that would be my guess to what's happening here. But what is exactly causing these DPC latency spikes? Have you tried updating all your system drivers, especially audio drivers?

[Awesome Donkey]

Okay, I just tried it out for myself (as I don't use the WDM driver feature normally) and can reproduce the stuttering at Max (192 kHz) on Tidal when playing back music. I used George Harrison's 50th Anniversary Super Deluxe edition of his album All Things Must Pass as the test and indeed it does stutter when Tidal is set to use Exclusive Mode for the audio output. On my machine at least with LatencyMon open there's no spikes in DPC latency when this occurs so all green/good there. If you disable Exclusive Mode in Tidal it plays back at 48 kHz which apparently you need Exclusive Mode enabled in Tidal to playback at higher sample rates like 192 kHz so that's a no good.

Changing buffer indeed doesn't help, and in most cases does indeed seem to make it worse.

[ppataki]

Okay, I just tried it out for myself (as I don't use the WDM driver feature normally) and can reproduce the stuttering at Max (192 kHz) on Tidal when playing back music. I used George Harrison's 50th Anniversary Super Deluxe edition of his album All Things Must Pass as the test and indeed it does stutter when Tidal is set to use Exclusive Mode for the audio output. On my machine at least with LatencyMon open there's no spikes in DPC latency when this occurs so all green/good there. If you disable Exclusive Mode in Tidal it plays back at 48 kHz which apparently you need Exclusive Mode enabled in Tidal to playback at higher sample rates like 192 kHz so that's a no good.

Changing buffer indeed doesn't help, and in most cases does indeed seem to make it worse.

I really appreciate this, thank you!
Now at least we know that I am not alone with this

Actually in the meantime I did another test: if I don't use the WDM driver but just play 192kHz content in Tidal directly to my UDIO-8 it plays fine, absolutely no glitches

So I guess this ultimately means that something must be wrong with the WDM driver indeed

[mattkhan]

I tried this out and can confirm same behaviour, 192kHz is v bad as there are constant micro dropouts so it's a bit different (or just loads loads worse) to usual buffer related problems

no dpc latency issue here at the time btw, system is completely healthy so it's either a WDM issue or a tidal desktop app issue

[mattkhan]

to rule out tidal, I tried qobuz which also offers 192kHz via a desktop app to wasapi exclusive and which gives you more control over buffers at their end

made no difference, 192kHz is a total fail

I think this concludes that it must be a WDM issue

[ppataki]

Thank you for checking from your end too, really appreciated!

I hope this issue will be taken up by the dev team and fixed in due course

[Hendrik]

The WDM driver has a bit of a hidden feature to change its buffer size, maybe try this and see if it helps you at all.

Save the attached file as a .reg file (eg. WDMBufferSize.reg) and run it. The MC27 reference in it is intentional, keep that as is. You can change the value for the frame size, its in hexadecimal, 64 would be 100ms (the default is 10), the maximum is 1000 (000003E8 in hex)

[mattkhan]

first impressions

250ms is a lot better for tidal but not perfect (the odd glitch here and there)
qobuz is totally unreliable with any value

fwiw, after changing this, I went to change the live playback latency and MC hung (reports as apphang). No idea if related.

btw, when does it take effect? it doesn't seem that restarting playback is sufficient nor restarting the source app (nor even restarting MC individually) but it's hard to tell (e.g. I changed it back to 10ms to check it failed again, restarted various things but it still seems reliable)

I had no such reg key btw so presume there is some internal default used in that case?

[Awesome Donkey]

You can also open a Windows Terminal, Command Prompt or PowerShell window as an administrator and copy/paste the following line in...

Edit: Removed because it doesn't work like that

Using this you don't need to convert normal (decimal) values to hexadecimal so you can use 10, 50, 100, 200, 1000, etc. instead of 100 in the example (and it'll set the correct hex value for the registry key automatically).

[Hendrik]

You can also open a Windows Terminal, Command Prompt or PowerShell window as an administrator and copy/paste the following line in...

Code: [Select]

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\JRiver\Media Center 27\WDM" /v FrameSizeMS /d 100 /t REG_DWORD /f
Using this you don't need to convert normal (decimal) values to hexadecimal so you can use 10, 50, 100, 200, 1000, etc. instead of 100 in the example (and it'll set the correct hex value for the registry key automatically).

Don't post it on the forum, the stupid replacement rules ruin the path. Its supposed to be J<dot><space>River, not JRiver

[Awesome Donkey]

Oh, you're right, oof.

[kr4]

to rule out tidal, I tried qobuz which also offers 192kHz via a desktop app to wasapi exclusive and which gives you more control over buffers at their end

made no difference, 192kHz is a total fail

I think this concludes that it must be a WDM issue

I tried this with Qobuz and it works just fine with WASAPI (no stuttering) but not with WASAPI Exclusive.

[Awesome Donkey]

Yeah, it seems to happen with WASAPI exclusive in apps like that.

[Hendrik]

btw, when does it take effect? it doesn't seem that restarting playback is sufficient nor restarting the source app (nor even restarting MC individually) but it's hard to tell (e.g. I changed it back to 10ms to check it failed again, restarted various things but it still seems reliable)

Whenever the driver is initialized, its not really meant to be runtime configurable. I guess leaving it alone for a while without audio may make Windows restart it? Its a bit opaque.

[ppataki]

I have tried with 100ms, 250ms, 500ms and 1000ms as well, unfortunately the stuttering is still there

[JimH]

Turn off exclusive mode in Tidal and reboot.

[ppataki]

Turning off exclusive mode in Tidal turns off high-res as well so there is no point in doing that (everything will play in 48kHz)

[JimH]

That's a Tidal thing.  They must be trying to prevent piracy.

But you said earlier that exclusive mode was set in MC.  You can't do that with two applications.

Try WASAPI.

[B4Unyu]

fyi
referencing: exclusive mode

something changed with the handling of exclusive mode in Windows 11.
made no related changes to audio device settings in MC or windows, in the more sound settings (the old windows' sound setting popup).

condition:
in Windows,
exclusive mode and app priority selected

in MC:
prevent HDMI display from turning off = unchecked (allow monitor to turn off/enter low power state.
exclusive mode = On (WASAPI Exclusive)
hardware connection is motherboard audio jack line out for pc speakers.

result:
in the midst of playing a song (any common sample rate), let the monitor fully enter low power, wake with mouse/keyboard results in the audio playing at faster speed.

note:
USB DAC device not affected.
Monitor connected via motherboard hdmi->displayport (but not using this for audio, just as display)
nvidia graphics card hdmi straight to a/v receiver (power off/standby state) then to powered down TV

just fyi,
don't care if this is fixed or not, can be worked around, not laying blame anywhere, don't even know if this is specific to this PC, but likely Windows thing again, if it happens on your PCs, probably makes no difference MC32 or MC33.

might enlighten somebody's thoughts about what is going on with topic issue.

[JimH]

Thanks for the nice report.

Did you try turning off Exclusive Mode?

[Awesome Donkey]

Use of Exclusive Mode here is probably the key. There's an experiment somebody can try if they're curious; load up a second version of MC (e.g. a portable version) and set it up to use the WDM driver from the primary version of MC as its audio output. Then make sure WASAPI exclusive is being used and in that portable version of MC try playing back a 24/192 file and see if you can replicate what's happening with Tidal and Qobuz at 192 kHz when using WASAPI exclusive.

[mattkhan]

fyi
referencing: exclusive mode

something changed with the handling of exclusive mode in Windows 11.
made no related changes to audio device settings in MC or windows, in the more sound settings (the old windows' sound setting popup).

I tested on Win10 and power states not involved so this does not seem relevant to the issue reported in this thread