Once again... Audio track loading slowly

Support
1

I’ve been facing this error message lately more and more. Music drops out or stutters first, then drops and next track starts playing. I’ve noticed it’s always connected to the usage of my storage drive. For example if I open Steam while playing music through Roon, I might soon get this error when Steam accesses the storage drive. I can’t understand why Roon can’t buffer the tracks so that when I access the storage drive while music is playing, it actually wouldn’t matter. Haven’t experienced similar behavior with any other media player applications.

I have RoonServer installed on my computer and I control it separately with Roon app on the same PC, iPad and iPhone. Computer is only few months old with proper specs, i5 8400, 16gb DDR4, SSD system drive, Windows 10 and storage drive is 4TB HDD (Western Digital Blue). Computer is connected through USB cable to Mutec MC-3+ USB.

Here’s what log file says when the dropout happens (RoonServer log).

01/14 14:31:10 Info: [stats] 5811mb Virtual, 29mb Physical, 313mb Managed, 1516 Handles, 75 Threads
01/14 14:31:15 Trace: [Tykki WASAPI] [Lossless, 16/44 FLAC => 16/44] [13% buf] [PLAYING @ 5:18/6:29] Slush - Hot Chip
01/14 14:31:20 Trace: [Tykki WASAPI] [Lossless, 16/44 FLAC => 16/44] [19% buf] [PLAYING @ 5:23/6:29] Slush - Hot Chip
01/14 14:31:20 Trace: [Tykki WASAPI] [zoneplayer/raat] sync MC-3+ Smart Clock USB: realtime=1834061096000 rtt=0us offset=-289435904us delta=-32us drift=-23192us in 1834,052s (-12,645ppm, -45,523ms/hr)
01/14 14:31:22 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:24 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:25 Trace: [Tykki WASAPI] [Lossless, 16/44 FLAC => 16/44] [7% buf] [PLAYING @ 5:28/6:29] Slush - Hot Chip
01/14 14:31:25 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:25 Info: [stats] 5827mb Virtual, 30mb Physical, 313mb Managed, 1532 Handles, 79 Threads
01/14 14:31:25 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:25 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:26 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:26 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:26 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:27 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:28 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:28 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:29 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:29 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:29 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:29 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:29 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:29 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:30 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:30 Trace: [Tykki WASAPI] [Lossless, 16/44 FLAC => 16/44] [1% buf] [PLAYING @ 5:33/6:29] Slush - Hot Chip
01/14 14:31:30 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:30 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:30 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:31 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:31 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:31 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:32 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:32 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:33 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:33 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:33 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:34 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:34 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:34 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:34 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:35 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:35 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:35 Trace: [Tykki WASAPI] [Lossless, 16/44 FLAC => 16/44] [1% buf] [PLAYING @ 5:38/6:29] Slush - Hot Chip
01/14 14:31:35 Trace: [push] restarting connection (Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall.)
01/14 14:31:35 Trace: [push] retrying connection in 56440ms
01/14 14:31:35 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:36 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:36 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:36 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:36 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:36 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:37 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:37 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:37 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:38 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:38 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:38 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:38 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:38 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:39 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:39 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:39 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:40 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:40 Trace: [Tykki WASAPI] [Lossless, 16/44 FLAC => 16/44] [1% buf] [PLAYING @ 5:43/6:29] Slush - Hot Chip
01/14 14:31:40 Info: [stats] 5811mb Virtual, 31mb Physical, 312mb Managed, 1520 Handles, 75 Threads
01/14 14:31:40 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:40 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:40 Trace: [MC-3+ Smart Clock USB] [raatclient] GOT [7] {"status":"Dropout","samples":4833}
01/14 14:31:41 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:41 Trace: [MC-3+ Smart Clock USB] [raatclient] GOT [7] {"status":"Dropout","samples":20703}
01/14 14:31:41 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:41 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:41 Trace: [MC-3+ Smart Clock USB] [raatclient] GOT [7] {"status":"Dropout","samples":22050}
01/14 14:31:42 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:42 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:42 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:42 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:42 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:42 Trace: [MC-3+ Smart Clock USB] [raatclient] GOT [7] {"status":"Dropout","samples":17640}
01/14 14:31:42 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:42 Trace: [MC-3+ Smart Clock USB] [raatclient] GOT [7] {"status":"Dropout","samples":11853}
01/14 14:31:43 Trace: [MC-3+ Smart Clock USB] [raatclient] GOT [7] {"status":"Dropout","samples":22050}
01/14 14:31:43 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:43 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:43 Trace: [MC-3+ Smart Clock USB] [raatclient] GOT [7] {"status":"Dropout","samples":22050}
01/14 14:31:44 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:44 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:44 Debug: [prebuffer] sleeping in read -- this isn't good
01/14 14:31:44 Trace: [MC-3+ Smart Clock USB] [raatclient] GOT [7] {"status":"Dropout","samples":22050}
01/14 14:31:44 Warn: [Tykki WASAPI] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
01/14 14:31:44 Trace: [Tykki WASAPI] [zoneplayer/raat] too many dropouts. stopping stream
01/14 14:31:44 Info: [Tykki WASAPI] [zoneplayer] advance didn't change the track. returning short read
01/14 14:31:44 Warn: Track Stopped Due to Slow Media
01/14 14:31:44 Info: [audio/env] [zoneplayer -> stream] All streams were disposed
01/14 14:31:44 Debug: Lastfm 'f2271328bfd37e591fd543d69d8654c4' DONE: Hot Chip - Slush 
01/14 14:31:44 Info: [zone Tykki WASAPI] OnPlayFeedback StoppedEndOfMediaUnnatural
01/14 14:31:44 Debug: [zone Tykki WASAPI] _Advance
01/14 14:31:44 Info: [audio/env] [zoneplayer] All streams were disposed
01/14 14:31:44 Info: [audio/env] [zoneplayer -> stream -> endpoint] All streams were disposed

What does sleeping in read mean? I’ve configured the PC with high performance power saving settings and HDD shouldn’t sleep until it’s been idling for 120 minutes.

Any advice how to get rid of the problem? Thanks in advance.

2

Steam, are you trying to game on the same computer that is running your RoonCore?

3

As I live in one room apartment and my computer is two meters away from my hifi setup, I see no need for dedicated computer for Roon Server. There’s simply no benefit of having two computers here. I have one computer which I use for multiple things, including gaming and watching movies. Naturally I don’t do all these activities at the same time when I listen to music. But I might open Steam to background while I’m on computer and listen to music. Modern computers are completely capable on multitasking. My computer is optimized for music playback, other tasks come second in priority.

The problem here is that whatever activity there is on storage drive at the same time music is playing through Roon, often causes this error. I’d like to know the reason to this as no other media player application behaves this way. I’ve used foobar2000 and JRiver many years before I went for Roon lifetime.

5

Hello @patouskii,

Thanks for contacting support. “Sleeping in read” generally indicates that the Core isn’t getting the media fast enough from where it’s being streamed and is likely related to your network setup. I am seeing that your buffer is going down and that you’re also failing to connect to some of our services in that trace further indicating that this is networking related.

I would start by taking a look at your network setup, does it follow the guidelines of our Networking Best Practices? What is the exact model/manufacturer of your router, switches, range extenders, powerline adapters, ect. in this setup? How is the Western Digital HDD connected here, are you making use of a HDD -> USB adapter or is it part of the computer itself?

Please let us know this info when possible.

Thanks,
Noris

6

You don’t say how the storage drive is connected but those symptoms sound like the drive might be sharing a bus with other activity. If internal can you move it to another SATA channel. Or if USB, another socket (and swap out the cable for a known good one). If USB how is the drive powered?

I would also look at Windows Event viewer for any error messages around the time of the issue.

If you move some of the music to the SSD and point roon at it, do you still get the issue when playing from the SSD?

7

Thanks for replies, now we’re getting somewhere.

I use internal HDD drive which is connected to motherboard (Asus Z370-P) with regular SATA-connection. I assume the cable is the one which comes with the motherboard. I didn’t build this one myself, bought a ready made packet from known Finnish retailer. I can try switching SATA port later but don’t really believe in differences between SATA cables.

My router is D-Link 868L and it’s connected with ethernet cable (proper spec) to my computer. Everything has latest firmware and drivers, I’m very strict with that. Roon network setup page really doesn’t give me anything new. I’ve tried to play with the router settings but don’t really know how it could affect this one since I don’t play anything over my network here (computer is connected through USB and storage is internal).

I use ProceXP to monitor events on computer, it diggs little deeper than the regular event viewer. Usually when the playback drops, there’s some other activity on the HDD than Roon.

8

Hey @patouskii,

One other suggestion that I have here is taking a look at the router configuration itself in case that’s the bottleneck. You will want to make sure IPV4 and IPV6 multicast streams are enabled as per these instructions.

You may also want to take a look at “IGMP Snooping” or “IGMP Proxying” as I have seen those router setting help in the past with similar issues.

– Noris

10

I actually had multicast streams disabled for some reason. I turned them on for IPV4 and 6, let’s see if it helps.

1 Like
11

Hi @patouskii,

Did turning on multicast help?

– Noris

12

Hi Noris,

Well I got to this day without dropouts but now when I came home, opened Roon and started playback, everything worked fine until I opened Steam again, just for test. It seems there’s straight connection to opening Steam and especially when Steam updates games and access the storage drive. Once again, playback started to stutter and then it jumped to the next track. It goes on as long as Steam uses the storage drive, it’s easy to monitor the usage with Process Explorer (https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer). I storage my music and games on the same 4TB internal WD Blue HDD. When I close Steam, the stutter and dropouts stop also. So it’s only because other program has high usage of the HDD drive at the same time when Roon uses it. It seems that Roon is very sensitive to this. Maybe there should be an option in audio settings to raise the buffer size for tracks or something?

Now when it’s certain that Steam causes this, I can just keep it closed when I play music. And that’s how I normally operate. It’s still weird though that two programs can’t access one HDD at the same time without problems.

17

Some options might be in the hardware realm, you could update the WD Blue which is 5400 rpm drive to say a WD Black which at 7200 rpm might be better up to the task. Or, you might also add a 2nd drive and move steam to it; thus separating and avoiding drive competition.

Also and this one is a bit out there, but you might verify, that your Roon watched folders on the WD drive does not include any folder touched by Steam. Roon will “scan” any file changes/additions. So, in that scenario, one program writes/changes a file and then Roon immediately kicks off to analyze the file.

Actually, you could kind of test that by Turning OFF Backgound Audio Analysis under Settings/Library and see if there is any improvement.

18

Well Steam is closed when I concentrate on music. I don’t get dropouts when there’s no other activity on the PC. So really there’s no problem but of course I’m wondering how the dropouts occur in the first place. IMO that just shouldn’t happen even though Steam would be accessing the same HDD. It can probably also happen with other apps accessing HDD simultaneously.

I don’t want any faster spinning drive to make noise here. Also Roon is only watching my Music drive, which obviously is on the same HDD but different drive than Steam-storage. No background analysis happening here since everything’s been analyzed long time ago and it’s set on throttle anyway.

1 Like
20

Ok today this happened again but not with Steam. Now it skipped multiple tracks and when I checked out what’s happening in the background, I find svchost.exe with heavy I/O usage. Most probably it’s MsMpEng.exe (Windows anti-virus and malware) which can’t even be closed completely, it’s always running background. Is it really so that when something else uses the storage drive, Roon simply can’t keep up and starts skipping tracks? I can’t believe Roon would work this way? Why isn’t the track fully buffered before playback or could we maybe even have a setting for that? All drivers are up to date, windows is up to date, all firmware are up to date and everything is running smoothly but always when I play music and some process decides to access my storage drive at the same time, this happens.

21

Roon is trying to buffer the track, but something about your setup or machine is failing to deliver the media in time – you can see the buffer hitting 7% and then failing to fill up in the trace you posted in the original post:

01/14 14:31:24 Debug: [prebuffer] sleeping in read -- this isn't good 01/14 14:31:25 Trace: [Tykki WASAPI] [Lossless, 16/44 FLAC => 16/44] [7% buf] [PLAYING @ 5:28/6:29] Slush - Hot Chip 01/14 14:31:25 Debug: [prebuffer] sleeping in read -- this isn't good

So why is this happening? It’s really hard to say. You may want to try playing media from a different drive to confirm whether this has something to do with the WD drive, or you might want to do some additional testing on the hardware.

We can absolutely continue to work with you on this issue, but ultimately this is going to come down to figuring out why this setup can’t keep up. Just want to be clear that what you’re proposing is something we’re already doing, which is working properly on many thousands of other installs – I agree that your specs look like they should be fine, so something doesn’t add up here.

Sorry for the frustrations here @patouskii – I’m sure we can figure this out, so thanks for your patience here.

22

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.

23

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

24

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

25

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

26

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
27

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