Music stops abruptly and Roon plays only silence

Hi,

I have been experiencing an issue since I started my Roon subscription in Sept 2018, and I can’t seem to figure out what is going on and I am starting to despair at ever getting this issue solved.

My set-up is as follows:

  • Roon for Windows (v1.6 build 401)
    • All Roon components are running on same PC
  • Windows 10, 64-bit, latest updates installed
  • MSI GTI Titan GT80-2QE laptop
    • Intel i7-4980HQ
    • 32Gb RAM
    • RAID0 hard drive array (4 x 256Gb SSD)
  • Chord Hugo TT DAC
    • USB connection into Hugo’s “high quality” USB port
    • ASIO driver (same happens with WASAPI driver)

When I am listening music, Roon will just stop sending the music to the DAC.

  • If I restart Roon without restarting the DAC, the music will play again.
  • If I restart the DAC without restarting Roon, the music will play again.
  • If I press Pause or skip tracks without starting Roon or the DAC, Roon will continue to play silence.

When the music stops playing, Roon thinks it is still playing - the track time continues to increase as if the track is still playing.

While my laptop isn’t as good as a modern desktop, it is still a pretty decent laptop and the DSP shows that the music is being rendered at “60x”.

The issue happens regardless of music source (I use TIDAL and FLAC stored on a NAS drive).

Any ideas on how to fix this?

Thanks in advance.

Not sure if this is a second issue or whether it is related, but I changed my DSP settings today to make it perform upsampling to DSD and a few other things. I was getting the speed displayed as “2x” - I then turned on the multithreaded setting and it increased to “6x”.

When I open Google Chrome, music playback in Roon is momentarily disrupted (couple of seconds). It happens every single time. I had to change the process priority on the RAATServer.exe process to real time in order to correct this small dropout.

Is this the correct fix for this issue? If so, is there a way for me to make Roon start RAATServer.exe as a real time process automatically? Right now, I have to change this priority manually every time. :frowning:

Thanks

Hello @Framgeld,

Thanks for contacting us regarding this issue and thanks for outlining the issue very clearly.

Your Core seems to be up to spec as far as I can tell, but having to change the priority is not something that you should have to do to have Roon working. Can you let me know how often you notice this issue?

You mention that you are experiencing temporary Roon disruption every single time you open up Chrome, but when the music stops abruptly, how long is this into a listening session?

Also, just to confirm here, if you don’t have any DSP active on your Roon zone, does the same issue with Chrome occur? Do you have the newest updates for Chrome and does you laptop have the newest Chord Drivers?

Thanks,
Noris

Hi @noris,

Your Core seems to be up to spec as far as I can tell, but having to change the priority is not something that you should have to do to have Roon working. Can you let me know how often you notice this issue?

Changing the priority is the fix for the issue when I open Chrome. It does not resolve the issue where Roon stops playback until I either restart Roon or restart the DAC (so far, haven’t found a workaround for this issue). I would say it happens once per hour, maybe? May be worth noting that streaming to Airplay never has this issue (I stream all day during the week, as I work from home).

You mention that you are experiencing temporary Roon disruption every single time you open up Chrome, but when the music stops abruptly, how long is this into a listening session?

Also, just to confirm here, if you don’t have any DSP active on your Roon zone, does the same issue with Chrome occur?

It would appear that the “blip when opening Chrome” issue occurs when the Sample Rate Conversion DSP is enabled. When I disabled it, I did not get pauses during playback when I opened Chrome. That said… increasing the RAATServer.exe priority to real-time while having the same DSP enabled also fixes it.

Do you have the newest updates for Chrome and does you laptop have the newest [Chord Drivers]?

Yes, my Chrome is up to date, as is my Chord Hugo TT driver. Chord haven’t updated the Hugo TT drivers in quite some time (17th Jan 2018 is the timestamp on the EXE in the driver ZIP file).

Hi @noris,

Some further information that you may find interesting (I find it very interesting)…

It would appear the RAATServer.exe processing with the Sample Rate Conversion on my machine is ONLY being affected by Chrome, and only when the Chrome UX is being shown from being closed (i.e. creating new tabs does not affect it). I did the following things and none affected RAATServer.exe:

  • Opened the Steam client and updated to latest version
    • This also downloaded and updated 14 games to the latest version
  • Opened the Vivaldi web browser and updated to latest version
  • Opened the Firefox web browser and updated to latest version
  • Opened Filezilla and connected to an FTP server
  • Opened Windows Task Manager
  • Searched my “C:” drive for “* . *” (without spaces) using Windows File Explorer

Steam and Vivaldi both use the Chromium engine (like Chrome), yet are unaffected. It seems to be something happening when Chrome is rendering its UX for the first time. Closing the Chrome UX then re-opening causes the blip in RAATServer.exe.

I disabled all of my Chrome extensions and re-tested, and the issue persists.

I also turned off the parallelism of the Sample Rate Conversion DSP setting, and the issue persists.

In the approx 40 minutes of listening this evening, I have had to do the DAC/Roon restart twice.

Hello @Framgeld,

Thanks for running those test. I would like to take a deeper look at this issue and see what the diagnostics from your core indicate. Can I please ask you to reproduce this issue once more and then note the exact local time in your country (e.g. 10:19PM) and let me know this info? Once I have the timestamp, I can go ahead and enable this feature and take a look for any error messages displayed.

Thanks,
Noris

Hi @noris,

Something similar just happened now (10:37pm).

I will report further occurrences.

Hi @noris,

The exact issue just happened early into a track at 11:42pm.

I clicked Skip at 11:43pm, and as usual, the music did not play.

Happened again: 12:15am.

Hi @Framgeld,

Thanks for listing those timestamps. Now that I have this information available, I have gone ahead and enabled diagnostics mode for your account and what this action will do is next time your Core is active, a set of logs will automatically be generated and uploaded to our servers for analysis. I will take a look to see what the diagnostics say and if they shed any light on why this issue could be occurring.

Thanks,
Noris

Hi @noris,

My Roon Core has started up: hopefully, you should be getting the diagnostic logs shortly (if it is an automatic process).

Thanks.

Hello @Framgeld,

Thanks for letting me know that, I can confirm that the diagnostics have successfully reached our servers and I’m taking a look.

As far as I can tell, the driver itself is crashing but it is not clear as to why. This could be due to the driver itself and it might be useful to perform a re-install from Chord’s website, but since this occurs with both ASIO and WASAPI drivers, I am wondering if perhaps the USB cable is damaged.

Would you by any chance have another USB cable around the house that you can try using, and let me know if the same issue occurs?

I will also be doing some testing on my end with the Hugo TT I have from the lab and will let you know if I experience any similar issues, it’s been working as expected when I last checked a week ago, so this leads me to believe that that this issue could be something environmental to your setup here.

Do let me know if there is any change after re-installing the driver and swapping out the USB cable.

Thanks,
Noris

Hi @noris,

Thank you for analysing the logs. The cable is the same cable that was supplied by Chord with the Hugo TT and I haven’t been bending/twisting it in any way. That said, it doesn’t mean that the cable is not damaged. I have purchased a new cable and I can test it out tomorrow.

I will be grateful to hear how your own tests in the lab fare with your Hugo TT.

Thanks.

Hi @Framgeld,

I have been listening to my Hugo TT on a Windows x64 machine (16GB RAM, SSD, Ryzen 7 CPU) using the ASIO 1.04 driver for the last 4 hours in upsampled DSD128 without any issues. I have been playing TIDAL tracks and upsampling to the DSD rate and it’s all been working flawlessly with no pauses or breaks.

I am one windows update behind though, I will get that aspect updated and continue testing this weekend, but I suspect that this is an environmental issue regarding your setup. Please do let me know if there is any change with the new USB cable.

If there isn’t any change perhaps another good data point here will be to see if the same behavior occurs if you host the Roon core temporarily on another machine, switching between Cores is a fairly easy process and only requires you to un-authroize the previous Core and authorize the new one.

Thanks,
Noris

Hi @noris,

I have tried the new cable… same issue. I have uninstalled all of the Chord drivers and re-installed the latest driver… same issue.

Playback stopped at 11:03am.

Unfortunately, I don’t have another PC to install Roon Core on.

Please can you check the issue that occurred at 11:03am and confirm if it is the same issue? If it is, I will raise a support ticket with Chord also (if you can provide me with the details regarding the driver crash).

Thanks.

Hi @noris,

I believe the crash at 11:03am is because my Hugo TT was set as the default audio device for Windows. Music was playing through Roon, and I launched Steam. A sound tried to play through the default audio device (which Roon was using via ASIO), and some form of conflict occurred.

Now this is where things get weird: I thought ASIO controlled the device exclusively. What actually happened was the audio being played via Roon started to stutter for a second while Windows tried to play audio to the locked audio device. After a second, Roon stops playing audio.

While I understand that the default Windows audio device shouldn’t be the same as the ASIO device that Roon is using, it would seem that some software (be it Roon, the Chord driver, or Windows itself) is not behaving correctly when the default Windows audio device cannot be used.

Hello @Framgeld,

Sorry to hear that the same issue occurs even with the new cable in place and the drivers re-installed.

The sound you heard is strange, I am not sure why the conflict would occur like that, maybe it could be caused by some kind of software like ASIO4ALL if this is active at the same time?

As for the main issue at hand, I have a few other ideas here to narrow it down even further. Can you check to see if this issue occurs when using the TIDAL app to stream to the Hugo? Does this same behavior occur if you set Roon’s output to “System Output” and enable exclusive mode in Roon? As before, if you experience these issues in the Roon app please list the timestamp.

Thanks,
Noris

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.