INTERACT FORUM
Windows => JRiver Media Center 33 for Windows => Topic started by: ppataki on September 14, 2024, 02:53:25 am
-
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
-
Make sure Windows Defender is configured. Don't use anything else for antivirus.
WDM should work.
Anything else unusual about your setup?
-
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
-
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
-
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
-
It could also be limited by bandwidth.
-
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.
-
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?
-
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
-
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.
-
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?
-
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
-
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
-
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)
-
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.
-
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?
-
I've tried various browsers and MC always stutters using browsers especially. I assume processor is taking away from MC. I tried increasing MC priority to high but doesnt seem to solve the issue.
Anything I can do to prevent stuttering?
-
Web browsers in MC are an external component (e.g. Edge via WebView2 which is the current default on Windows). Perhaps something like an antivirus app or some other app is doing something to cause issues with it?
-
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?
-
It happens specifically when I launch web browsers and open tabs
-
WDM device is configured for exclusive mode?
Did you try the test with a virtual asio device and asio line in?
-
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
-
Try setting the WDM driver in Windows to 192000 Hz from 48000 Hz and see if that changes anything.
-
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
-
What processor, sample rates, number of channels, and are you using any dsp?
-
Oh, you mean it happens when using an actual web browser, not when using the embedded browser in MC itself. I've seen this happen on Windows on a lower performing system when Windows Defender's memory integrity feature was enabled. This uses virtualization technology which can interfere with audio playback in MC and cause stutter issues on lower powered systems for example. You can try increasing the buffer for the audio output used and see if that makes a difference, but the case I experienced years ago I ended up having to disable memory integrity in Windows Defender's settings in order to resolve it.
If memory integrity isn't enabled, then it kinda sounds like spikes in DPC latency. In that case try using an app like LatencyMon and see if DPC latency spikes are happening. Like whoareyou mentioned it's probably a good idea to list system specs.
-
What processor, sample rates, number of channels, and are you using any dsp?
i7 Processor, mostly Flac 16-44 or MP3 320kbps, 2 channel, DSP only Volume leveling enabled.
Device name DESKTOP-1TJAT9I
Processor 12th Gen Intel(R) Core(TM) i7-12700K 3.60 GHz
Installed RAM 64.0 GB (63.8 GB usable)
System type 64-bit operating system, x64-based processor
-
Oh, you mean it happens when using an actual web browser, not when using the embedded browser in MC itself. I've seen this happen on Windows on a lower performing system when Windows Defender's memory integrity feature was enabled. This uses virtualization technology which can interfere with audio playback in MC and cause stutter issues on lower powered systems for example. You can try increasing the buffer for the audio output used and see if that makes a difference, but the case I experienced years ago I ended up having to disable memory integrity in Windows Defender's settings in order to resolve it.
If memory integrity isn't enabled, then it kinda sounds like spikes in DPC latency. In that case try using an app like LatencyMon and see if DPC latency spikes are happening. Like whoareyou mentioned it's probably a good idea to list system specs.
It's i7 so not low end ... regarding latency, honestly I'm not that techie and wouldn't know what to look for or do about it in LatencyMon
Processor 12th Gen Intel(R) Core(TM) i7-12700K 3.60 GHz
Installed RAM 64.0 GB (63.8 GB usable)
GPU: 3060ti
System type 64-bit operating system, x64-based processor
-
LatencyMon will tell you if DPC latency spikes are happening and what a basic culprit of it may be. Something's definitely happening on your system though, as it shouldn't happen with a system with that much RAM and a newer CPU like that. It's hard to say what exactly is causing it, I would put my money on a driver or something causing DPC latency spikes or memory integrity being enabled and causing issues but I could be wrong with those guesses.
-
LatencyMon will tell you if DPC latency spikes are happening and what a basic culprit of it may be. Something's definitely happening on your system though, as it shouldn't happen with a system with that much RAM and a newer CPU like that. It's hard to say what exactly is causing it, I would put my money on a driver or something causing DPC latency spikes or memory integrity being enabled and causing issues but I could be wrong with those guesses.
Thanks for your help ... I installed LatencyMon ... initially it said for me to check contol panel for CPU throttling cause of a audio issue. I had it on "balanced", so I changed it to high performance and it definitely improved, however still a slight issue but definitely less than before. It mentioned something about bios but not sure if I want to mess with that ... would bios setting on any CPU throttling be any different that that in Control panel Power settings?
Strangely I got this screenshot after making power "high performance"
-
Antivirus?
Or something else running in the background.
-
It won't work to have exclusive mode set in two applications. Exclusive mode means that the app has control of the audio.
-
Exclusive mode is enabled in Tidal, there is no second app
-
You could try increasing the buffering MC is using in Options > Audio > Device settings...
-
I have tried adjusting it here (attached), it actually gets worse :(
-
I guess we would need an option to change the buffer size of the WDM device itself
-
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.
-
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)
-
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?
-
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.
-
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
-
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
-
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
-
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
-
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)
-
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?
-
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).
-
You can also open a Windows Terminal, Command Prompt or PowerShell window as an administrator and copy/paste the following line in...
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 replacement rules ruin the path. Its supposed to be J<dot><space>River, not JRiver
-
Oh, you're right, oof.
-
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.
-
Yeah, it seems to happen with WASAPI exclusive in apps like that.
-
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.
-
I have tried with 100ms, 250ms, 500ms and 1000ms as well, unfortunately the stuttering is still there
-
Turn off exclusive mode in Tidal and reboot.
-
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)
-
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.
-
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.
-
Thanks for the nice report.
Did you try turning off Exclusive Mode?
-
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.
-
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
-
JimH,
exclusive mode off in MC and Windows = something went wrong error in MC
exclusive mode off in MC But On in windows = same playback error
However...
DSD files in same playlist that are being down sampled to 192 are not effected.
But...
192 is selected as sample rate in windows, so 192 files will play as well, but not the other common sample rates.
assuming changing sample rate there will result in only selected sample rate files playing and DSD file will play only being converted that selected rate.
-
Antivirus?
Or something else running in the background.
What's strange is it only happens when opening web browsers .. Edge, Chrome etc
Uninstalled AV and no difference.
-
How about looking at the driver tab? Look for driver taking way more time than anything else?
-
How about looking at the driver tab? Look for driver taking way more time than anything else?
Sorry what you mean "driver tab" ... how would i go about this? Might verywell be a driver ...
-
The Drivers tab in LatencyMon.
-
experimented a bit more with this rebooting after each registry change to be sure it was applied
results = glitchy playback with any value tried under 1000, 1000 was completely unstable (constant loop of opening and immediately closing playback)
changing any of the MC input or output buffers (live playback latency, output device buffers) made no difference to this
-
Exactly the same as in my case
Thanks for testing, appreciated
-
I tried the same using asio line in and get the same results (using qobuz as that supports asio output devices) so that would suggest the problem is not specific to the WDM driver but is instead in how MC handles a live input.
-
Would be nice to fix it either way in one of the upcoming releases
-
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've had the same experience repeatedly. My solution was to stop using WDM altogether, which I had the luxury to do.
-
Thank you for confirming the same
For those that don't have that luxury it would be great to get this fixed
-
I have the same experience with WDM driver. It does not work correctly for years thru many versions. I don't use it because of this. Currently using only ASIO - this is perfect. If I would not have ASIO HW (RME UCX II), then I would not use MC anymore.
-
I merged two threads even though they were slightly different. The latencymon message above may point to an NVIDIA driver problem.
Rogueblue,
Stuttering audio is probably not a CPU problem. It doesn't take a lot of power to play audio.
-
I don't have high DPC spikes due to the Nvidia driver, @Awesome Donkey does not have DCP spikes at all and still we both have the stuttering issue at 192kHz
I doubt this is an Nvidia driver issue
As @mattkhan said it is rather an issue with how MC handles live input
Or it can still be a WDM driver issue
-
Given the same happens with asio line in, you would think it's an MC issue rather than device specific.
-
I just tried Qobuz playing into WDM and there was significant stuttering at 192 Khz.
I also tried using MC32 as the input program rather than Qobuz and there was no stuttering at 192 KHz.
So, it seems that the problem depends on the input source.
For people who are having this problem, if you still have MC 32 (or an earlier version) you might try playing 192 KHz to the WDM on MC 33 as a test.
Windows 10, HP Laptop, Realtek speaker, MC 32.0.29
-
MC33 stutters too, no change unfortunately
-
I had MC 32 output to WDM on MC 33. You have stuttering on that configuration?
-
Antivirus can treat separate versions differently.
Settings matter.
-
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)
You can't have two programs set to exclusive. Exclusive means exclusive.
-
I posted a while ago that it's not every source causing the problem, I used mpc to demonstrate. It's nothing to do with antivirus though, the evidence says it's an MC problem in handling input streams.
-
I posted a while ago that it's not every source causing the problem, I used mpc to demonstrate. It's nothing to do with antivirus though, the evidence says it's an MC problem in handling input streams.
Steps to duplicate would help. Including settings.
-
Already posted earlier I believe, settings are not so important because behaviour seems invariant to any relevant settings like buffers
Configure tidal or qobuz to play back to wasapi exclusive
Enable WDM driver
Play some 192kHz content in either app
MC will stutter badly
Repeat in qobuz outputting to an asio device which is capable of looping back to an input
Open asio line in pointing at those channels
MC will stutter badly
Change buffers as you like (large, small, whatever) makes no difference, it still glitches severely
-
You can't have two programs set to exclusive. Exclusive means exclusive.
Exclusive mode is unique to each device. So, within Tidal/Qobuz you select WDM as your output device and set that to exclusive mode so you can send 192 Khz. Then, within MC you select your output device in exclusive mode to be able to send 192 KHz to your DAC.
I used Qobuz with its default settings with WDM as the output device in exclusive mode and MC with its default settings for WDM and got significant stuttering. My output device from MC was in Wasapi exclusive mode. If you have Qobuz that should be easy to test.
-
It's pretty easy to reproduce fortunately.
1) Get access to Tidal and open the Tidal app on Windows.
2) Set Tidal to use the WDM driver and make sure exclusive mode is enabled for it.
3) In my own tests in MC I'm using WASAPI exclusive with my USB DAC. Maybe does it for ASIO too, not sure, haven't tried. But for this test I would advise WASAPI exclusive in MC.
4) In the Tidal app find an artist/album that is available and plays at Max quality. For my testing I used George Harrison's All Things Must Pass (50th Anniversary) release. You can find it here: https://tidal.com/browse/album/275643024?u
5) Attempt playback, which should be at 24/192 and it should stutter significantly.
-
I tested it with both WASAPI excl. and ASIO, both stutter like hell
-
Please test without exclusive mode set in MC.
-
Turned off exclusive mode in MC. Same stuttering.
-
If anyone has experienced the issue in a case that doesn't require a paid subscription, that would simplify testing a bunch.
-
Fwiw both apps have a free trial
-
As I said previously I suspect that you can reproduce it using a second (portable) MC or another player like foobar2000 and set it to use the main MC's WDM driver output (with exclusive mode enabled) while playing back local 24/192 media in the secondary player.
If I had time I'd test it myself but can't at the moment. If nobody else does I'll see if I can get the chance to try it.
-
I'm playing a 192 kHz file with Winamp to the WDM driver and it's playing nicely. MC is getting the 192 kHz signal. I'm outputting to my Mytek DAC.
What else should I do to reproduce?
I tried as 5.1 and 2 channel from Winamp and both worked (converted to stereo by MC's output).
Thanks.
-
The problem has been reported with Tidal and Qobuz. I would suggest trying those.
-
I tried this with Qobuz and it works just fine with WASAPI (no stuttering) but not with WASAPI Exclusive.
For Quboz, I see the same thing with shared mode set to 192 Khz in Windows options. The problem with using shared mode is that everything gets upsampled by Windows to the shared mode frequency, in this case to 192 KHz.
Just to add another wrinkle, in Amazon Music 192 Khz works in both shared mode and exclusive mode. But with exclusive mode set within Amazon Music and enabled for the WDM driver, Amazon music says it is sending 192, but the signal WDM receives is the shared mode sample rate set that is set in Windows settings. No idea how that happens, but Audio Path clearly shows that it is getting the shared mode sample rate, even though everything is set to exclusive mode.
I no longer subscribe to Tidal but as I remember you cannot send 192 Khz unless you use exclusive mode. That should be checked by a current subscriber.
Now I am totally confused.
-
There's one more possibility that I haven't raised because it seemed unlikely.
They may be trying to detect another program recording their streams, and when they think they do, limiting the bandwidth so that it seems to work but doesn't.
-
The cases I tested seemed to work at 96K. I would be surprised if they throttled 192 but not 96, but who knows.
-
There's one more possibility that I haven't raised because it seemed unlikely.
They may be trying to detect another program recording their streams, and when they think they do, limiting the bandwidth so that it seems to work but doesn't.
I confirmed this is not the case as following
* qobuz output to asio to channels 1 & 2
* MC asio line in listening to channels 1 & 2
* MC asio output to some other channel range
* reaper daw listening to asio channels 1 & 2
* start playback, confirm audible audio (played by MC) is glitchy
* start recording in reaper for 10s or so
* render track to a 192kHz wav
* stop all of the above
* play wav file in MC
* audio plays normally
conclusion = 192kHz input processing in MC is flawed
-
Been struggling with this for a couple of years now and thought Its something I'm doing wrong... good to see I'm not alone :)
With Tidal I don't use Exclusive mode with MC WDM 192kHz cos stutterzzzz! This on Win10 and now Win11 ASIO
Straight to SMSL SU-9 DAC Exclusive mode is fine with everything
WASAPI will sometimes give no sound at all on WDM using exclusive but I haven't really played around on WASAPI that much as I seem to have less issues with ASIO
-
Do we know if this issue is going to get fixed anytime soon?
-
I recently set up a customer who is using Roon with the WDM so that he can use MC's visualisations. Glad to say that with WDM in WASAPI exclusive mode in Roon, there is no issue with either Tidal or Qobuz playback of 192 KHz. The audio device is also in WASAPI exclusive mode in MC.
-
Same problem: i solved settimo the wdm live latency from 50 to 100 ms