Print

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

[rhallsw]

There is still a crackling noise that frequently occurs when music is streamed through JRiver via WDM.  The volume is not huge, but definitely audible over the music.  The incidence and frequency of the noise do not seem to be affected by either of the buffer parameters.  When present, the crackle frequency is about every few seconds and randomly spaced.  On some occasions, i get noise-free music; on other occasions, the same music becomes difficult to listen to like an old worn vinyl disk.  If WDM playback is noisy, and WDM/JRiver is bypassed, the noise is then not present.  The noise seems to be associated with WDM and only when music is being played.  I am using the latest JRiver Media 20 on Windows 8.1.  I use 2 zones with auto-switch as per instructions; this works great.

I have tried unsuccessfully to correlate WDM noise with other computer events.  If I had to guess, WDM may be reacting badly to some sporadic defect on the input stream that is not audible when WDM is bypassed.  Others on the thread report similar observations with a variety of music sources including Spotify.  Would a WDM facility to log errors help in tracing the source of the noise?

[Matt]

The problem is that we just can't reproduce the problem.

I've been playing via WDM all morning to test and it's just perfect.

Do you have any hints for us to possibly reproduce the problem?

[mwillems]

Matt,

I've been working on this issue at home, and my experience has been that it tends to be output device and/or PC-specific.  It may seem counter-intuitive that the output device would have an effect on the WDM driver's behavior, but that's been my observation (outlined below).  I have certain PCs that don't exhibit any issues with the WDM driver at all, and certain output devices that don't seem to have the issue at all.  But the "right" combination of PC and device will always exhibit the issue for me.

An example: I have an i7-4790K on Win 8 that has an Asus Essence ST PCI card and H6 daughter board.  It shows the following behavior:
1) All combinations of buffer settings produce periodic pops/dropouts when JRiver addresses the ST using WASAPI and I'm using the WDM driver.  Some buffer settings are worse than others.
2) Without using the WDM driver (outputting directly to the card) there are never any dropouts at all.  
3) It gets worse under CPU load.
4) Outputting to the card using ASIO produces fewer dropouts (but not zero dropouts) when using the WDM driver.  

I've methodically tried every combination of buffer settings and still get dropouts with the WDM driver with this hardware, especially with games.  So as part of my differential diagnosis, I tried different devices and PCs:  

1) If I plug a USB sound device into the i7-4790K (like an asus U7 or a Fiio e17), no more dropouts when using the WDM driver, even running intensive games.  
2) And, if I take out the internal card (the Asus Essence ST) and plug it into another computer (e.g. an i7 2600K on win 7), I get no dropouts using the WDM driver with the exact same physical card.

So it seems to be an issue with specific machine/interface combinations.  I've tried about 10-12 different output devices (including various onboard audio), and tested them (when possible) on four different machines.  My personal experience from those tests is that internal PCI/PCI-e interfaces and onboard soundcards tend to be more prone to the issue than external interfaces, although external interfaces are not immune.  Similarly, I've noticed that using an ASIO output is less susceptible to the issue than using a WASAPI output on the same device, but not all ASIO devices are immune, and obviously not all devices are ASIO capable.

My "best case" device is my Steinberg UR 824.  It produces no WDM related dropouts with any of the four computers I've attached it to.  

My "worst case" was the onboard audio on the Asus Z-97 MoBo with my 4790K system (which I obviously couldn't test on other machines).  It had crackles/dropouts every five or ten seconds when using the WDM driver (but had no issues during normal direct playback).

So my reproduction advice is to try using internal/onboard soundcards on a few different machines with WASAPI as your output setting, ideally with a source like a video game that might tax the CPU a little bit (although I get the dropouts with plain old webstreaming, they're just more frequent with games). Obviously this is at best anecdotal, but I thought I'd offer the results of my own testing in case it helps reproduce it.

[natehansen66]

I was hoping there was work being done on this, because it doesn't work for me. What rhallsw describes is exactly what happens to me.

As I understand it, JRiver is located in the Minneapolis? I'm just down the road a bit in Rochester. If it would help I'd be willing to bring my PC and audio interface up for testing (I use an Echo AudioFire 12 firewire multichannel interface). This pc and interface are my only system but I'd be willing to take a bullet for the greater good  .  First, I want to restore the pc to factory and start over to make sure there's nothing I've done that's causing the wdm issues. I have a "junk" pc in the basement that I'll copy my settings over to and try as well.

[JimH]

Thanks for the selfless offer.  Could you run a benchmark (under Help) and paste the results here?  Thanks again.

[rhallsw]

The problem is that we just can't reproduce the problem.

I've been playing via WDM all morning to test and it's just perfect.

Do you have any hints for us to possibly reproduce the problem?

Hi Matt

User mwillems suggests that the output device might be significant.  My output device is the Ayre QB-9 (with WASAPI), which I have been using with JRiver for several years.  This combination gives superb sound.  With CD or DVD into JRiver or Spotify without JRiver (presumably using a different Windows driver), I never hear audible faults or drop-outs.  With WDM/JRiver, the fault rate can vary from every few seconds to hours (even with the same music), although audible faults are the norm for me.  Since JRiver Media Center 20 is the playback device for the driver, I find it hard to believe that the output device might contribute to the problem.  I just tried QB-9 with Direct Sound instead of WASAPI and drop-outs were still present.

With WDM/JRiver the sound is slightly lower in volume and noticeably cleaner (except for the faults), when compared with the bypass mode.  The only way that I could help debug this problem is if you had an "instrumented" WDM driver that logged errors to the OS.  Even if this is possible, the drop-out faults might not be detected by WDM as errors.  One thing that I might try is to run a benchmark when the error rate is low or high.  I have never used the benchmark tool, and had forgotten that it existed.  When the fault rate is low, I have tried to add CPU load, e.g., web surfing, to "create" faults, but so far have found no correlation of faults with anything obvious.

Actually, user natehansen66 has made a splendid offer.  If he can reproduce the problem at your location, then this would be wonderful.  For a proper test, a typical service provider Internet connection should be used.  The JRiver corporate connection would be different and presumably much better and cleaner than the typical user Internet connection.  The real origin of audible WDM faults just may be in the integrity of the Internet connection.  This is a hard problem, and users who get these faults likely have something in common.  Thank you for your efforts in trying to reproduce the faults.

[natehansen66]

Thanks for the selfless offer.  Could you run a benchmark (under Help) and paste the results here?  Thanks again.

Will do....I'll try to remember later today.

[natehansen66]

Ok I had a couple minutes this morning so here it is. PC is nothing special....core i5 Acer on Win8.1 I got from Best Buy a little over a year ago. Math does seem a bit weak, no?

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 4.554 seconds
    Single-threaded floating point math... 2.757 seconds
    Multi-threaded integer math... 2.422 seconds
    Multi-threaded mixed math... 1.559 seconds
Score: 1683

Running 'Image' benchmark...
    Image creation / destruction... 0.371 seconds
    Flood filling... 0.369 seconds
    Direct copying... 0.461 seconds
    Small renders... 1.246 seconds
    Bilinear rendering... 0.925 seconds
    Bicubic rendering... 0.523 seconds
Score: 5648

Running 'Database' benchmark...
    Create database... 0.214 seconds
    Populate database... 2.128 seconds
    Save database... 1.001 seconds
    Reload database... 0.239 seconds
    Search database... 0.955 seconds
    Sort database... 1.099 seconds
    Group database... 0.698 seconds
Score: 3394

JRMark (version 20.0.103): 3575

[JimH]

That's a good machine.  Plenty of power.

If you haven't done so, can you test another sound device?  The internal audio, for example.

Here's a long thread with other benchmarks:
http://yabb.jriver.com/interact/index.php?topic=54396.250

Your math score seems normal.

[mwillems]

That's a good machine.  Plenty of power.

If you haven't done so, can you test another sound device?  The internal audio, for example.

Here's a long thread with other benchmarks:
http://yabb.jriver.com/interact/index.php?topic=54396.250

Your math score seems normal.

FWIW I have WDM dropouts on a machine with a JRMark over 5700 (this machine): http://yabb.jriver.com/interact/index.php?topic=54396.msg641558#msg641558

By contrast, one of my machines that never seems to have WDM dropouts has a JRMark in middle 2000's.  I'm not sure the issue is related to raw processing power, my guess based on my own testing would be that it's more interrupt-driven/driver-related.

Since JRiver Media Center 20 is the playback device for the driver, I find it hard to believe that the output device might contribute to the problem.  I just tried QB-9 with Direct Sound instead of WASAPI and drop-outs were still present.

I'm not sure what to tell you except that I have devices that never exhibit dropouts when connected to the same machine that experiences dropouts with other devices.  If the issue is a scheduling/interrupt issue the driver of the ultimate output device may well make a difference.  That doesn't mean it's the output device's "fault" (most of my devices playback fine when not using the WDM driver just like yours), but it points to a potential way to reproduce the problem at JRiver HQ.

The real origin of audible WDM faults just may be in the integrity of the Internet connection.  

I can guarantee that the internet connection is not the source of faults in my case as I get significant pops/dropouts with purely local playback like video games, or audio from other applications.  My dropouts with local playback are as frequent or more frequent than with webstreaming.  

You can confirm/disconfirm your hypothesis by testing your machine by using the WDM driver with local playback of audio files in another program (windows media player or VLC) and seeing whether you still get pops or dropouts.  

[rhallsw]

Ok I had a couple minutes this morning so here it is. PC is nothing special....core i5 Acer on Win8.1 I got from Best Buy a little over a year ago. Math does seem a bit weak, no?

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
Score: 1683

Running 'Image' benchmark...
Score: 5648

Running 'Database' benchmark...
Score: 3394

JRMark (version 20.0.103): 3575

I had quite similar benchmark numbers (actually slightly higher) with a USB DAC as the sound device.  Although these appear to be good benchmark values, WDM dropouts were bad at the time.

Does anyone else find that the rate of WDM dropouts varies a lot?  Sometimes I think that they are gone, and they return next day or later in the same day.  This might suggest one of the following:
1. The varying quality of the provider Internet feed.  WDM may be making some type of streaming fault more audible.  Some streaming services like Spotify cache music on the hard drive, making any observation suspect.
2. Other CPU activities on the computer like disk defragmentation (actually the latter is supposed to run only once per week)
3. Actual hardware faults (less likely).

I wish that I had an alternate sound device to try but I do not.  I can only vary the JRiver parameters.

[Matt]

I wish that I had an alternate sound device to try but I do not.  I can only vary the JRiver parameters.

What happens if you increase the buffering of the audio output device in Options > Audio > Device settings...?

[natehansen66]

That's a good machine.  Plenty of power.

If you haven't done so, can you test another sound device?  The internal audio, for example.

Here's a long thread with other benchmarks:
http://yabb.jriver.com/interact/index.php?topic=54396.250

Your math score seems normal.

Yeah I was planning on giving that a shot in the next few days. My old pc in the basement has the same wdm issues while using it with the mobo sound and audio measurement sw. I'll see how the mobo sound works on the main rig.

[natehansen66]

Ok I got some testing done this afternoon. Main PC and firewire interface are still stuttering with wdm. I hooked up the mobo sound with Wasapi and I get the same result....pops and clicks. I brought my old pc up from the basement (Acer Pentium E5500 on Win7, JRMark 1980, about 6 years old), loaded my MC settings from my main rig......and it works! Clean playback through my firewire interface via WDM. I should add that I'm still on MC20.

My offer still stands if the MC team would like to do some testing on the pc with wdm issues.

[rhallsw]

What happens if you increase the buffering of the audio output device in Options > Audio > Device settings...?

I had output buffering at 100 ms (default) with moderate WDM noise and increased it to 500 ms.  As far as I can tell, no improvement.  When noise is bad, I have also tried varying the live playback latency with no success; I have it at 50 ms (default).  Like some others, I cannot find a "sweet spot" for the two parameters to reduce this fault.  For me, the rate of noise faults also varies widely from time to time.  At some times, noise may be almost nonexistent; at other times, randomly spaced dropouts occur every few seconds on average.  Clearly, something is varying between these two situations.  Could it be the Internet connection quality?  I would be happy with a click or two per hour.

If when WDM noise is bad, I switch my default playback device from JRiver to the USB DAC (the same audio output device for JRiver), the noise is no longer present.  It would seem that WDM is sensitive to some presently unknown factor.  This is for sure a hard problem.

[natehansen66]

Could it be the Internet connection quality?  I would be happy with a click or two per hour.

You could determine if it's your internet connection by using the Loopback feature or download ASIO Bridge instead of using wdm. These both work flawlessly with internet streaming on my main machine where wdm doesn't. I really don't think your connection is the problem, or you could do as mwillems suggested and play some of your local content through another player and route it through the wdm. That will tell you real quick.

Like you, I've tried every buffer combination under the sun. Some days I'll hit a combination that works, but then I fire it up the next day and it's buggy again.

I spent about an hour listening to Spotify on my old pc via wdm and there were zero issues, where my main PC will have a glitch every 15-20 seconds. Streaming content on my main pc with loopback or ASIO bridge works fine so that tells me it's the wdm driver.

[rhallsw]

You could determine if it's your internet connection by using the Loopback feature or download ASIO Bridge instead of using wdm. These both work flawlessly with internet streaming on my main machine where wdm doesn't. I really don't think your connection is the problem, or you could do as mwillems suggested and play some of your local content through another player and route it through the wdm. That will tell you real quick.

Like you, I've tried every buffer combination under the sun. Some days I'll hit a combination that works, but then I fire it up the next day and it's buggy again.

I spent about an hour listening to Spotify on my old pc via wdm and there were zero issues, where my main PC will have a glitch every 15-20 seconds. Streaming content on my main pc with loopback or ASIO bridge works fine so that tells me it's the wdm driver.

If I select my USB DAC as the default audio device (Windows thinks that it is a speaker), then I get noise-free sound but without JRive0 in circuitr.  This sort of suggests that the Internet connection is OK.  If this is true, the WDM noise may be related to another Windows process that interrupts WDM sporadically.  I would need two sound devices to use loopback.

[Awesome Donkey]

Just curious but what OS, computer and audio hardware is everyone using?

[rhallsw]

Just curious but what OS, computer and audio hardware is everyone using?

Dell XPS8700 with quad core, Windows 8.1, Ayre QB-9 USB DAC (original model).  Ayre highly recommends JRiver for use with its DAC.

[mwillems]

So I may have had a breakthrough on my WDM issues, and I wanted to share.

Most of my machines were on windows 8.1, but I've been upgrading them piecemeal to windows 10.  Interestingly, I upgraded the machine that I had the biggest and most consistent WDM issues with (my i7 4790K), and so far in windows 10 the dropouts seem to have disappeared.  This is in contexts that very reliably reproduced issues before on windows 8.1.  I've been testing for about an hour and it seems to have resolved the issue.

Win 10's audio stack was supposed to reduce latency in a number of ways, several of which were automatic (required no extra effort from devs*), so it's possible that might be part of the story.  I'm cautiously optimistic and will report back if I start getting dropouts again.

*- from https://msdn.microsoft.com/en-us/library/windows/hardware/Mt298187%28v=VS.85%29.aspx

All applications that use audio will see a 4.5-16ms reduction in round-trip latency (as was explained in the section above) without any code changes or driver updates, compared to Windows 8.1.

[JimH]

That's pretty interesting.  And good news if it holds.

[natehansen66]

Interesting! It's my Win8.1 machine I'm having trouble with....my Win7 machine works fine with wdm.

[mwillems]

That's pretty interesting.  And good news if it holds.

So far so good.  I just finished about 4 hours of WDM listening on my newly upgraded Win 10 machine.  Other than a one-off pop when playback started (which is typical even on my well-behaved machines), I got no pops or dropouts the entire time.  That includes playing a specific video game that used to reliably produce the issue for about an hour with no issues. 

I'll report back as I test more, but I don't think I ever had a stretch this long with no pops on this machine with Win 8.1, so it looks like Win 10 definitely helps the issue with my setup; the proof will be in the pudding whether it's a true "cure."

For additional context: this was an in-place update not a clean install.  I didn't even have to re-install my proprietary audio device drivers, so I don't think this is a case of the "new broom sweeping clean."  I think Win 10 may just work better for live audio playback for the reasons linked above (or maybe Win 8.1 is badly behaved in a way that sometimes exposes a fault in the WDM driver, depending on your perspective).

Interesting! It's my Win8.1 machine I'm having trouble with....my Win7 machine works fine with wdm.

My testing pool was three Windows 8.1 machines (an i7 4790K, an i5 NUC, and a three year old i5 laptop) and one Windows 7 machine (an i7-2660k).  Two of the Win 8.1 machines had the issue to varying degrees (the i7 4790K and the laptop), but one of the 8.1 machines didn't have the issue at all (the NUC).  My Win 7 machine did not have the issue at all.

I upgraded the Win 7 machine to Win 10  a week ago, and it hasn't had any WDM issues since the upgrade, but it never had any issues before, so I didn't think anything of it.  I suppose the next step is to pay attention to what happens to the laptop when I eventually upgrade it.

Is anyone in the thread with these issues running Win 7 or Win 10?

[natehansen66]

I'm probably jumping the gun with this report......but so far the upgrade to Win10 seems to have taken care of the wdm issue for me. I had to make some changes to the buffers because there were some glitches with the previous settings but after that it's been good. The glitches that were present before I changed the buffer were much quieter than usual. We'll see how it plays out the next few days.....

[mwillems]

I'm still glitch free in my house.  I've got my fingers crossed.

[orangeart]

Well heartened by the reports of glitch free WDM under windows 10 I upgraded, no change though.

A couple of points that may help the devs.

If I exit jriver, close any process that may be holding a jriver file open, close the audio steam and disable the jriver driver in the windows audio control panel, then open an audio stream and play audio through another device, then cloes that stream, open jriver, open the audio control panel and re-enable the WDM driver then open a new audio stream things are much improved, still not perfect but better.

[orangeart]

Also worth saying what I've said before and that is the internal sample rate for the jriver ASIO driver seems to wander around a lot, if you use something like VB-audio cable or voice meter that can show in real time both the incoming sample rate and that requested by the outgoing ASIO device. It varies (on my systems at least) by as much as 200hz either way and this produces the popping and crackling. In fact you can hear that the audio is steady when the panel displays a lock and when the display shows a different sample rate than is expected you get popping and crakling, the further the rate strays from expected the worse the crackling.

I wonder if the WDM driver has the same problem communicating with the ASIO driver as these other apps do? maybe this is an ASIO driver problem and the WDM is just a red herring?

I hope this gets sorted, at least there seems to be some engagement and we have got past the head in the sand type support that us WDM driver users have had for the last year or so :-)

If you would like me to package up my PC (or both of them) with my audio interfaces and send them to the states ot try and help get to the bottom of this problem I'll happily do it. PM me with the details of where you would like them sent. I guess what is really needed is some sort of monitoring and reporting screen that allows WDM and ASIO errors and monitoring of dropped samples etc. What are the chances of that happening?

I do quite a lot of demonstrations of active crossovers, PC based ones normally. It would be great to get to the point where I can actually demonstrate this software doing the rest of the stuff it does so well.

Stefan

[gvanbrunt]

One thing to point out here: I believe the upgrade process replaces many drivers. Some may not be the latest versions available from manufacturers. At least that was what MS OS upgrades used to do.

So if anyone sees the issues "come back" after it is working for a while it would be good to take a look at what drivers were updated just before the problem comes back.

Lets hope it is fixed and this isn't what is happening though.

[lello]

I have this problem with WDM, and I do not know if you have already talked about (I have not found any discussion).

Given that use MC20, Win7 and an Asus Essence ST audio card with ASIO.

Essentially any other program uses WDM (YouTube, DVBViewer etc.), I have an annoying delay between audio and video. I looked among the various settings, but have not found anything that face for me.

I could solve the problem by switching to MC21?

[mwillems]

I have this problem with WDM, and I do not know if you have already talked about (I have not found any discussion).

Given that use MC20, Win7 and an Asus Essence ST audio card with ASIO.

Essentially any other program uses WDM (YouTube, DVBViewer etc.), I have an annoying delay between audio and video. I looked among the various settings, but have not found anything that face for me.

I could solve the problem by switching to MC21?

Try lowering the buffers outlined at the start of the thread and see if that helps.  The buffer settings are what determine the delay.  The A/V delay is to some extent unavoidable, but can be improved.

There shouldn't be a big difference between MC20 and MC21 with regard to latency.

[lello]

I put the buffer to a minimum, the latency of the sound card to a minimum, but still we have not sinned ....

[orangeart]

I have a similar problem which seems to down to a bug In the jrss downmixer. Since a few version ago if I set up all of my filters in a fresh install everything is fine, as soon as I switch on JRSS I get about a second delay. Switching it off doesn't fix the problem. Starting a new zone a inputting my settings all over again does. I can use JRSS without any other settings works just can't use it with any routing or filters. It is a pain as it means I can only send two channel stuff to the WDM.

As far as I'm aware this bug has never been fixed.

Try creating a new zone and see if you can get in sync before you change any settings. Once you get the settings you want inputted don't let jriver do any upgrades as this breaks it again.

Stefan

[rhallsw]

The problem is that we just can't reproduce the problem.

I've been playing via WDM all morning to test and it's just perfect.

Do you have any hints for us to possibly reproduce the problem?

Funny thing; JRiver updated automatically to the latest stable version 21.0.15 from my previous 21.0.9, and the clicks in the streaming audio (Spotify and other streams) went away.  Even more interesting: the video sync problem also went away.  I don't see any change in the version logs that might have had this effect.  Nothing else changed in my setup that I know about.  Was there a recent WDM change?  I hope the fix (whatever it is) persists; Spotify (premium) sounds wonderful.  I appreciate that this has been a baffling problem, but quite a number of users have had it.  I am listening right now to Bruckner on Spotify, wonderful, no clicks.

Parameters: Windows 8.1, WASAPI, USB DAC output device, both buffers at 100 ms.  I have zones set up as in the instructions.

[orangeart]

Have these WDM problems been sorted out yet? I daren't update to the latest version because of the other problems that causes me but if it's fixed then I will bite the bullet

Stefan

[natehansen66]

I haven't seen anything about the WDM in the changelog. The problem persists here.

[mwillems]

As an aside, there aren't any other bits of software out there that give access to a DSP crossover and all the other bells and whistles with an ASIO driver and WDM driver as input. I'd pay good money for a standalone product that did that, especially if it had a decent UI. I know a lot of people in the DIY audio community that would be pleased to have a bit of software that did that. If the devs got this sorted out properly it could open the gate to a whole new product.

Shame really.

If you're just trying to create a standalone DSP crossover in a box without a media center on top of it, read this thread all the way through: http://www.diyaudio.com/forums/pc-based/274331-ladspa-plugin-programming-linux-audio-crossovers.html

And here's a real-life build example: http://rtaylor.sites.tru.ca/2013/06/25/digital-crossovereq-with-open-source-software-howto/

The author of that thread has been working on a set of opensource crossover and DSP filters for linux, and has (later in the thread) acheived success and made the filters available.  That means there is a free option that at least in theory will do exactly what you're asking.  I haven't tested any of it personally, but I've been toying with the idea of setting them up as JRIver currently doesn't offer any kind of WDM/ASIO-like input driver on the Linux side.

To take advantage of it, you'd probably need to setup a separate linux system to be the "processor," but it sounds like he's even gotten things working with cheap embedded systems (like a raspberry Pi), but prefers a mini-itx solution.  Put another way, you could probably setup a freestanding processor using free software for less than $100 in hardware costs.  If you really just wanted a "standalone" processor, have a look.  There's obviously a bit of a learning curve, but it sounds like you're not getting what you need from the JRiver WDM driver.

For my part I'd like to see more WDM development, and more cross-platform input driver development (e.g. Linux/Mac).  It's my earnest wish that JRiver would offer some kind of input driver for Linux/embedded systems, so that I could use JRiver as the core of an embedded processor, but I'm not sure that's on the near-term development radar. 

As it is, the WDM works perfectly on 4 out of 5 of my windows systems, but started causing 100% reproducible blue screens on the fifth (the BSOD's trigger immediately after enabling the driver and the BSOD's often specifically identify the JRiver WDM driver sysfile by name). I had to turn WDM off entirely on that machine   

[orangeart]

Yeah that's interesting might give that a go for a test machine although most of my interfaces are Windows and Mac only and we mainly use Windows for HTPC stuff in our house.

[boudy]

I recently upgraded from MC19 to MC21 so that I could use WDM to play Spotify and other sources through my USB DAC.

MC21 plays fine on its own.

Other sources through WDM are unlistenable. I have tried the gamut of buffer settings. I have read through the prior threads and tried most of the recommendations.

MC 21.0.23

Windows 7 Pro (no I'm not upgrading to Windows 10, that's yet another sink hole)

Schiit Audio Loki Dac via WASAPI.