Once again... Audio track loading slowly

Yeah I really can’t figure this one out. I got this same error every once in a while with my old setup also but now I have a brand new PC with up-to-date specs and no unnecessary software running in background. Could WD Blue (4TB in size btw) just be so bad HDD? I doubt it since it’s one of the most popular HDD’s out there. This happened with my old WD Red in my old PC also.

Anyway there’s never dropouts when my PC just doesn’t do something else in the background. But the MsMpEng.exe does this bigger scan always in the beginning of month, I’ve wondered it before and don’t know how to change it or is it even possible to change.

Hi @patouskii,

Apologies for the delayed response, I wanted to come back to this issue and take another look at what could be going on here. Just to confirm what exactly is going on here:

  • You were able to reproduce this issue with Steam not running on the PC at all
  • There was a lot of IO activity in regards to the MsMpEng.exe that is the Window AV and firewall aspect

If this is the case, can I please ask you for a screenshot of the resource usage monitor that you are using to narrow this issue down? Also, you mentioned that you have both Roon Control and RoonServer on the same PC, is there any change if you only use RoonServer and use another Remote for control?

Once I have the screenshot and this info, I will discuss this case again with the team and see if we can narrow down what aspect of MsMpEng could be causing this behavior.

Thanks,
Noris

Yes it seems to be linked to activity on my storage HDD, not only to Steam.

Now everything’s worked fine for many days again. If Windows starts its monthly virus check when music is playing, this might happen. I think this was the case with MsMpEng.exe. I’ve excluded all Roon folders and all music folders from the scan but it doesn’t seem to help.

Doesn’t seem to matter if I control Roon from PC or from iPad/iPhone. I have installed them separately and always close the Roon Control app on PC if I move to the sweet spot to listen. So only RoonServer running then. I can’t get you the screen shot at the moment since this problem isn’t happening all the time, only when there’s heavy I/O usage on the storage drive.

Thanks

Hi @patouskii,

That is certainly strange. I wonder if this could be due to something on the Windows side of things, maybe a Windows Update might help if you haven’t done one already or if it’s not affecting the system that much expect once a month for the virus scan maybe it might be better to leave it as is, it’s hard to say. You might also want to check out some Windows forums to see if anyone else is reporting similar behavior from MsMpEng.exe.

– Noris

Yeah I don’t mind if it happens so rarely and it clearly only happens when there’s heavy I/O activity on my PC. Otherwise everything’s working correctly. I’ll report back if this gets worse again.

1 Like

I need to raise this topic again. I’m running out of ideas here. I’m coming from this thread:

My setup is described there. I’m not using USB-bridge anymore, now I’m streaming to Linn Akurate DSM.

And while that thread was marked solved, problems continue infrequently.

I write to this topic since currently I’m experiencing this error message all the time and while searching Roon-forum about it, my own topic comes on top every time:

Debug: [prebuffer] sleeping in read – this isn’t good

Another common error message in roonserver.log is this one:

Trace: [push] restarting connection (Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall.)

I just can’t figure these out. I’ve spent tens of hours trying to solve this and nothing helps. My first question would be: What’s sleeping? There’s zero power saving features enabled on Asus BIOS, Windows 10, D-Link router settings, HDD settings… anywhere. Nothing should be sleeping ever on this PC unless I shut it down completely.

This problem is not related to the Steam and Windows Antivirus I/O usage I described earlier. It happens when the RoonServer and Roon are running with nothing else taking resources on my computer. Am I missing some power saving features somewhere?

I guess I just need to start spending money to buy a separate switch, new router or new storage drives to find out what causes this. It’s funny that I can stream 4K video to my TV with zero hiccups and I can play the most demanding PC games online with zero lag or problems but streaming FLAC files to Linn ADSM with Roon seems to be impossible task… ridiculous.

Here’s the latest:

07/12 12:38:11 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [100% buf] [PLAYING @ 0:20/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:17 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [100% buf] [PLAYING @ 0:26/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:22 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [100% buf] [PLAYING @ 0:30/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:24 Info: [stats] 5817mb Virtual, 378mb Physical, 320mb Managed, 1526 Handles, 79 Threads
07/12 12:38:27 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [100% buf] [PLAYING @ 0:35/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:32 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [100% buf] [PLAYING @ 0:35/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:37 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [88% buf] [PLAYING @ 0:35/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:39 Info: [stats] 5793mb Virtual, 364mb Physical, 322mb Managed, 1505 Handles, 73 Threads
07/12 12:38:43 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [43% buf] [PLAYING @ 0:35/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:45 Trace: [realtime] fetching time from NTP server
07/12 12:38:45 Trace: [realtime] Got time from NTP: 12/07/2019 9.38.45 (3771913125870ms)
07/12 12:38:45 Trace: [realtime] Updated clock skew to -00:00:00.0267051 (-26,7051ms)
07/12 12:38:48 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [23% buf] [PLAYING @ 0:35/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:52 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:52 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:53 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:54 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [1% buf] [PLAYING @ 0:35/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:38:54 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:54 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:55 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:56 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:56 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:57 Info: [stats] 5809mb Virtual, 365mb Physical, 322mb Managed, 1528 Handles, 77 Threads
07/12 12:38:57 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:57 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:58 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:58 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:38:59 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:39:01 Trace: [Akurate DSM] [Lossless, 24/44 FLAC => 24/44] [PLAYING @ 0:35/5:45] Rock’em Sock’em Hop - Blockhead
07/12 12:39:01 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:39:01 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:39:02 Debug: [prebuffer] sleeping in read -- this isn't good
07/12 12:39:03 Debug: [prebuffer] sleeping in read -- this isn't good

As my frustration got on new level, I decided to finally eliminate the D-Link router as a culprit. I bought Netgear GS105 unmanaged switch and just connected it in my system. Things work as expected so I click play on Roon and wait… after two tracks something is sleeping again and when I open the RoonServer_log.txt, I find the same error message:

Debug: [prebuffer] sleeping in read – this isn’t good

What next?

So I spent the whole Friday trying to solve this because what else could you do on Fridays? Things I did:

  • Reset BIOS to default settings

  • Reinstalled Realtek GBe Network controller drivers

  • Reinstalled and restored Roon from backup, also changed from RoonServer + Roon control to simple Roon only application on my Win 10 PC. Never noticed any SQ improvements using the former configuration anyway.

  • Reinstalled the newest firmware on D-Link router

  • Fiddled with Windows 10 services disabling/enabling some which had anything to do with networking or power saving

  • Fiddled with every possible Win 10 setting which has anything to do with power saving or networking

  • Checked probably ten times that my PC power saving options were all off and it was using the high power plan and advanced settings

  • Tried to disable indexing on my HDD because someone on internet told it could improve things, useless

  • Installed Asset UPnP server and Linn Kinsky control point to try out. Had no problems or dropouts with them so it’s Linn + Roon and their fragile relationship clearly.

  • And as I earlier told, added Netgear GS105v5 switch to the mix.

After everything had failed, I checked the advanced settings of Realtek GBe Family Controller driver (motherboard’s integrated network card). I googled about tips and found this article:

I fiddled the settings according to that article but no, still sleeping in reading error message. Then I tried to remove GS105 from the mix and directly connected everything to the D-Link 868L router again and then… no sleeping anymore. I got normal playback and full buffer again. Color me surprised.

But I had noticed that GS105 has positive effect on sound quality. I listened for a while and everything was still working normally. Then I plugged GS105 back in and now everything worked fine with it also… wtf. Once again I got it working (for now) by fiddling around settings like madman. I’m not sure what did it in the end but I hope it works for a while now.

Hi @patouskii,

Thank you for listing your current troubleshooting and glad to hear that the issue has subsides since making one of the changes! Let me clarify on a few of your points further:

Just so you are aware - these two types of messages do not indicate anything related with “sleep” functions on your PC. Sleeping in read is a general term that the Core or endpoint was waiting for some data (e.g. trying to read it), but the data was not delivered on time and the action was paused (e.g. put in sleep mode) until the data was delivered.

Seeing this in conjunction with a WSACancelBlocking call usually indicates that something regarding the network or the Core is preventing proper delivery of the media across then network, and in a lot of cases where I see this these kinds of traces indicate that the network is not fully stable.

Roon operates on different technology than your 4K video streams. While it is possible to buffer the a 4K video on Netflix, on-demand audio applications such as Roon consume a larger amount of bandwidth than simply streaming a video file, so these two types of applications are not really comparable.

I am hoping that the issues have since subsided with your most recent changes but if it comes back again, we need to find the answers to the three following tests:

  1. What happens when you use a different PC to host the Roon Core?
  2. Does the same behavior occur with a different router or at a different network setup?
  3. Does the same issue occur on a different zone?

If we are able to narrow down the behavior to just one piece of equipment, we would be much better suited to address the issue head-on. From what you have mentioned so far it comes and goes which sounds like a hardware issue somewhere along the line, and often these types of issues are the hardest to narrow down simply because the symptoms are not always visible.

Thanks for the reply.

Everything has now worked rock solid after the last message I wrote. I’ve listened to hours of music with no dropouts. I really can’t say 100% sure what was the reason but I guess it was about the advanced settings of the Realtek GBe network interface. I actually tried to switch those settings back to default just to see if I’d get dropouts again and I actually did get one dropout after that. But it was different dropout, it was the known problem with Linn and Roon when the track stops 1 second before ending. Anyway then I went through the advanced settings one by one and after I had disabled Flow Control, everything’s been rock solid again with zero dropouts.

Also I think that the network/router part of the troubleshoot is done. I now have Netgear GS105v5 unmanaged switch connected. D-Link 868L is only connected to router and data between the Roon core and Linn doesn’t go through it. It really can’t get any simpler than that I think.

I’ll write back if problems occur again.

1 Like

Hi @noris

Little update here:

Everything worked absolutely perfectly since my last post. But the problems came back after my vacation trip.

I was away for three nights and unplugged everything at home, my PC, Linn ADSM, router and switch. I came back last night and powered my setup and this morning played some music again. Believe it or not, I got the sleeping in read error message. Nothing had change whatsoever. My setup had just been unpowered for three nights and the error message is back.

After that troubleshooting began. I restarted every single gear, no help. I ran windows update and there was an update which it installed and it asked to be restarted, no help. So once again I look into the Realtek GBe network controller advanced settings, which were as I had left them. I first tried to switch Energy Efficient Ethernet option to disabled and restarted ADSM after that, no help. Then I opened D-Link settings and switched WAN port setting from Auto 10/100/1000 to 1000 only and did the same thing in Realtek advanced settings under the name of “Speed & Duplex”. Under Realtek advanced settings I also disabled Interrupt Moderation. Then restarted ADSM and then to my reference test of running three tracks with no dropouts… and it works. Got through four tracks actually so I guess it works again… for now.

But seriously, this is ridiculous. It’s so fragile. Now it stopped working with no obvious reason. Nothing changed… it just stopped working.

Btw. I’ve noticed that the dropouts only occur when I’m away from computer. If I use the computer while music is playing, I never get dropouts. But when I leave it playing and go to the sweet spot/AFK, then the problems start. It really feels like the computer would lose the connection and go to sleep mode or something, but that’s simply not possible since every sleep setting is disabled and computer optimized for high performance. Any ideas about this finding?

I’m afraid it is. Predating WIN 10, I had a WIN 7 machine completely ignore its power settings and go to sleep after 15 mins or so when left alone. Never did get to the bottom of it. Buggy drivers I presume? I have also had power saving settings on the Ethernet card cause trouble until they were switched off.

This whole saga of ”sleeping in read” is really weird. Every possible sleep and power daving setting is off and my Win10 PC should run with steady power all the time. But since fiddling with Realtek settings seems to do the trick, I guess the problem lies in the network interface. For some reason it goes to sleep while I’m AFK, even though I’ve disabled all the sleep and power saving settings from advanced tab.

Now I noticed there were updated drivers available for the Realtek NIC so I updated. After that all the settings were intact but once again I got the sleeping in read error. I fiddled with random advanced settings for the Realtek and then it started to work again… I turned off some offload settings for example, which previously were enabled and all worked fine then. This makes absolutely no sense.

Can you try a different network interface? USB NICs are quite cheap and handy to have around. I have had to use them on old Vista boxes due to WIN 10 not providing stable/working drivers for the Realtek on-board network chips. WIN 10 kept randomly disconnecting from the network. Logs showed there were issues with the NIC drivers not responding at that specific disconnection time, so it was an easy fix.

Windows (especially 10), Ethernet and drivers keep realms of support people in employment/frustration. If you are using a desktop PC try buying a replacement card and see if that helps.

1 Like

As @noris pointed out ‘sleeping in read’ does not refer to power or sleep settings in the OS. It refers to network latency.

EDIT: That said it is quite possible that NIC settings/drivers could be the cause of the latency.

1 Like

I used USB interface with my previous setup for many years. I had stability issues with Roon back then also. I’ve written about it in the beginning of this thread. I never had stability issues with any other software than Roon (I used JRMC and foobar2000 previously) so I like to think this is not only about my system but also problem with Roon.

If the problem keeps appearing I might give separate NIC a try and disable the integrated Realtek NIC for good.

I continued troubleshooting tonight and actually picked up a Intel I210-T1 gigabit NIC and installed it to a free PCI-E slot with the latest Intel drivers. I thought Intel must work best since I use Intel processor and mobo. Internet connection worked fine and Intel even has these neat diagnostic tools on their driver packet which showed that everything from cables to the card itself work fine.

Well, with default settings on I210 the first play ended up stopping 1 second before end of the track, the known problem with Roon + Linn streamer combo. I started to fiddle with the advanced settings but couldn’t make Roon work steady with the I210. I reinstalled Roon, tried with Intel drivers and default Microsoft drivers but no. Usually got through 1-2 tracks and then the playback cursor stopped somewhere around middle of the track while playback still continued. Similar error messages in log than with Realtek, though now it didn’t give sleeping in read.

I removed Intel I210-T1 and fired up the integrated Realtek NIC again. All the settings were intact from previous install so I played some music… and it drops on third track. I fiddled with random advanced settings (at this point it doesn’t matter what to change, just change something and it might work or not) and now it works again this morning with no dropouts. Gone through ~10 tracks now with no dropouts. But at this point I know that some day sooner or later, the problems will come back with no obvious reason. Maybe next time Windows decides to install updates or maybe when Realtek updates its drivers. And this bothers me a lot, the connection isn’t stable.

Since there’s no other connection problems, download speeds, online gaming or anything else, I can’t think of anything else than some sort of problem between Linn and Roon. They don’t play well together. I hope someone’s looking into this.

Update:

Since I’m on vacation and have nothing better to do, I decided to give I210 another try. I installed it to a different PCI-E port (switched places with Asus Xonar soundcard, which outputs optical spdif to Linn ADSM for movies and such where I need realtime audio). Once again Microsoft installed its own drivers but I installed the newest Intel drivers, rebooted router, ADSM and computer and after that tested. Once again, playback cursor stops in the middle of third track, but Roon shows no obvious errors in log. Then I switched Speed & Duplex to 1gbps full and disabled interrupt moderation from NIC advanced settings. After that I have now got through seven tracks with no dropouts, so it seems now Intel works also with some fiddling. Its behavior seems to be similar to Realtek though, far from stable.

Hello @patouskii,

Do you see the same behavior when you use Airplay to play to the Linn zone?

-John