"Roon lost control of the audio device." too often lately [JPlay] [SOLVED]

Thank you for your suggestions. As you know there are zillion combinations to try and recently I am not such a diligent person. For example, JPlay is not a simple nor a robust creature and it offers so many variations to try.

My original intention to post this support request was to let Roon team know that there is one more guy out there who is experiencing the same or similar and again recent symptom as a few others have on this forum. Rather my point was that however simple or complex one’s music chain is, the same symptoms seem to persist.

Please note that I did not mean to highlight my music chain. I put it there just for the completeness sake (because Roon team surely will be asking me this if I have not).

Coming back to your last suggestion, since I am using S/PDIF, my Audio PC has visibility only up to the Filter3. Filter 2 and Filter 3 are kinda one-body-together piece. Filter1, the Uptone Regen is probably not a culprit. BTW Filter2, Acousence USB module is driven by XMOS-USB-Audio-(v3.34.0). No WASAPI. Kernel streaming only on the Audio PC.

At the moment I would be content if Roon team can step in and get a diagnostic data on their end on my account. Trying every possible combination methodically is not a do-able thing for me at the moment.

Hi @shinyc - Thank you for the report and sharing your feedback with us. The insight is always appreciated!

Before we go about gathering time stamps and collecting diagnostics I would like to try and isolate some variables here to see if we can determine where the issue is occurring. I agree with the approach @Rugby has suggested: remove complexity from the chain of communication and then add “links” back in one at a time to see where things fail (:+1:).

Being as you have already verified that this issue did not occur with the Yggy mounted directly to the RoonServer PC indicates to me that the error is being introduced somewhere further up stream. While diagnostics can give us an idea of what is occurring with Roon when the error is noticed it is important to remember that this is not always an “exact science”. For example, if I see “dropout” warnings in log traces. The error is noted but the cause is ambiguous, so the only approach is to look at the setup and all the devices involved.

The point being is the more variable(s) we can isolate with testing the more likely it will be that we can pinpoint to the cause of the problem. In my most humble, and honest opinion, the tests that should be considered are the following:

Initial testing:

RoonServer MacMini > “filter 1” > DAC

RoonServer MacMini > “filter 2” + “filter 3” > DAC

RoonServer MacMini > “filter 1” > “filter 2” + “filter 3” > DAC

[Note: starting with a direct connection to the MacMini is a good base because that device is not running any other processes on it (i.e HQPlayer, JPlay, Audio Optimizer2.20beta , Fidelizer Pro 8.0)]

If the issues does NOT appear when the above tests are performed…

Audio PC > “filter 1” > DAC

Audio PC > “filter 2” + “filter 3” > DAC

Audio PC > “filter 1” > “filter 2” + “filter 3” > DAC


Hi Eric,

Thank you for getting to this issue. The following are some of the results:

RoonServer MacMini > “filter 1” > DAC

No problem. Uptone Regen is transparent in transport-sense. RoonServer running on my x86 laptop works fine too.

RoonServer MacMini > “filter 2” + “filter 3” > DAC

No problem.

RoonServer MacMini > “filter 1” > “filter 2” + “filter 3” > DAC

No problem

Audio PC > “filter 1” > DAC

This setup involves Schiit USB driver installation for WS2016. I will test this configuration ASAP and let you know the result.

Audio PC > “filter 2” + “filter 3” > DAC

Same problem.

Audio PC > “filter 1” > “filter 2” + “filter 3” > DAC

Same problem.

Eric, as I mentioned in my 1st post in this topic, if I use NAA (by Signalyst) instead of JPlay as a network transport between the Control PC and Audio PC, I do not have the problem. This situation naturally points blame (or at least a partial suspicion) on the JPlay. And I had similar suspicion before creating this topic myself. But I did not want to get involved with JPlay mess (no disrespect to JPlay. It sounds better than NAA transport in my case.) such as interaction mechanism between HQPlayer and JPlay ASIO driver, JPlay streamer network transport, various JPlay settings like DAC Link, PC Buffer, etc. Then, I saw recent posts mentioning similar problem by other users who do not use JPlay. If you search support tickets with the search string “random #support after:2018-02-01”, you will see similar issues like “Roon stops randombly”. So I was hoping that I can learn from your resolutions for the issues other users experienced. BTW my exact configuration was running 98% OK a few tens of days ago.

Another consistent (98% of the time) behavior I am observing related to this recent issue is that with over Approx. 80% chance, music will not start the 1st time I press the play button. The 2nd time, 50% chance it will start. On 3rd press of the play button, 95% of the time music starts. During those unsuccessful 1st and 2nd press, I have to wait for each attempt to timeout which is not very convenient. And that is half of the issue. The other half is the random stopping of music play.

And I will test one more thing. Turning off the Fidelizer Pro on the Audio PC.

Any guess?


Thank you for touching base with me @shinyc and sharing the observations made during the proposed troubleshooting exercises :+1::microscope: The information is appreciated!

Continuing forward, if I had to guess the issue is occurring somewhere between the “control PC” and the “Audio PC” as you mentioned it in your latest, there is no issue when HQPLayer is used as transport between the two devices.

However, after some searching on Google for any known HQPlayer + JPlay issues I came across your JPlay thread here, where you mentioned the following:

How did the test go when you turned off Fidelizer Pro on the “audio PC”? Just curious what kind of result that yielded.


Hi Eric,

I fiddled with Fidelizer Pro(FP) settings. I was running a copy of FP on the Audio PC and the symptom kinda developed about the time I installed FP. So FP was a prime suspect but I was hoping that symptom stemmed from someplace else (for other users complained about the similar symptoms). After changing the “OS Timer Resolution” setting in FP (from 0.5ms default to 15.6ms), music started much more reliably. Now the failure rate of music starting on the first click reduced from 90% to 10% (Approx.). Music stopping randomly still persisted. I am not certain if the stop frequency got any better since. I was very encouraged by this fact and I purchased another copy of FP to put on the Control PC. So I did and the result was not conclusive until one setting came about (which I am still keeping as I type this) last night. The music played all night long (Roon radio) without a stop. It did stop a couple of times today but at this kind of frequency I am not complaining at all.

I set the OS Timer Resolution of FP on both Audio PC and Control PC to 15.6ms. FP program says 0.5ms is good for <> low latency application and longer resolutions for high buffering applications. I also recall reading the following quote on the Fidelizer website. Maybe @WindowsX can chime in please.

Adjustable OS Timer Resolution – Since developing Fidelizer, I firmly believed having 0.5ms OS Timer resolution will always bring better results. But lately I find some devices with high buffer design performing better or have less issues with 5.0ms or 15.6ms so it’s adjustable now.

I also fiddled with HQPlayer’s buffer time. And I also tried to run Diract Audio Processor on the Control PC but it introduced another problem. Now HQPlayer freezes when the music stops. As soon as Dirac process is killed (or output candidates rescanned in the DAP), the control of HQPlayer came back. And a new symptom was observed. All higher sampling tracks are not playing at all. 44.1 and 48khz were playing fine. 172, 192khz no. But at this very moment I am not observing this symptom.

JPlay might be at fault as well and you know there are many many setting to deal with in JPlay and the program is quite fragile, too (again no disrespect to JPlay).

I am not setting my next move for now. This is not what I hoped for. But I guess I dragged myself into this. Maybe I should have been a bit more patient. Or it might turn out to be a good move on my part after all. Who knows.

Eric, thank you for your continued support.

A few more observations.

Higher sampling rate files stop playing at 8 second, 23 second or 33 second mark with some consistency. This symptom is consistent across different JPlay setting so maybe I can acquit JPlay. 44.1khz files also stop quite early like 3min to 5 min. These symtoms are on and off affairs, not consistent and this is very frustrating. Music starting behavior seems to have improved (not corrected) since I set the OS timer interval to a longer setting than 0.5ms via Fidelizer Pro.

Might be totally coincidental, but, when I started using Roon, years ago, I ran into a similar issue with ASIO4ALL. It would play and then consistently stop at a certain point into a track, I’m thinking around 13 sec, I’d have to dig up the old posts. Anyway, the point was the ASIO driver was acting badly. I ditched that ASIO driver and never had the issue again.

I hope it is not a coincident. JPlay provides JPLAY asio driver interface to HQPlayer. There is no WASAPI counterpart. So I am stuck with asio. Maybe I should do away with JPlay and come back to NAA. Whip out the mRendu.

Maybe you can set DAC Link to 20Hz and PC Buffer at 0.5 with Classic engine without any filter installed and see if it works better.


Hi Keetakawee,

Thanks for chiming in. Tried your recommendation and everything is fine now. Thank you very much. If my memory serves right, those values (20hz/0.5sec) are JPlay defaults, right? Anyway, it turns out that more important thing is staying away from the Ultrastream in JPlay. If I choose Classic, not only no more hanging but also I am free to choose different dac link / PC buffer combination. My current setting is at 170hz for the PC link and 0.02 sec for the PC buffer. It has better high in my system. No more hesitance to start, no more random stop of music playing, no more stall during switching between different sample rates and sounding great too. Only thing that is still not working (a minor one) is stopping still occurs if I let HQPlay convert DSD material to PCM (I have an Yggy and I have to convert everything to PCM.), music chain gets broken. So I am doing the DSD/PCM conversion is Roon.

After switching to the Classic mode, the OS Timer Resolution in FP did not matter. So I set it back to 0.5ms. I am glad.

@Marcin_gps Can you help me run my setup in the Ultrastream mode as well? I was able to run this setup in the Ultrastream mode quasi reliably for about a month and something hit me (or my system).

I hate to drag everyone in but hey @jussi_laako, can you skim through this thread and let us know any issue you are aware of interacting with JPlay, Fidelizer, asio drivers, Dirac, etc. together with Roon?

Thanks, everyone.

I don’t see the point in using JPlay with HQPlayer.

Stock Win10 works fine.

I’ve heard reports that Dirac works, but it severely limits output capabilities, so I’d rather use something like Acourate, Audiolense or REW to create correction filters for HQPlayer’s convolution engine instead.

If you want to have optimized OS, you can try download bootable image of HQPlayer Embedded.

Hi Jussi,

Are you suggesting that I do Embedded HQPlayer (Linux I presume) + REW + NAA? Then I can do away with JPlay, AO, WS2016 and Dirac altogether and problem solved.

I am not sure what you mean by this. Are you suggesting that I should do away with HQPlayer or JPlay? I could collapse the RoonServer PC with the Control PC into 1 machine and in doing that remove either the HQPlayer(replaced by roon) or the JPlay(replaced by NAA) from the chain. Did I get it right? Partially?

REW or those other tools is needed only for measuring and creating the room correction filter which is then run by HQPlayer. Problem with Dirac is that it doesn’t allow exporting the correction filter and it unnecessarily mixes correction filter design with processing the filter. (Well, technically you can still extract the filter from Dirac, but it requires somewhat complex extra hassle)

What purpose is JPlay serving in the picture, what is the new functionality it brings into the picture? HQPlayer and Roon can be in same or different machine. Output can be in same or different (NAA) machine.

Of course if you don’t need HQPlayer’s DSP functionality you can remove that too.

Agree but understandingly so. It stems from human nature I suppose if you know what I mean.

Are you saying “theoretically it can be done” or “it can actually be done with some chore”? If it is the latter, you would be doing a lot of good to many Dirac users if you can provide the detail. Or is it too tall an order?

I am acknowledging the fact that the JPlay is contributing to better sound. JPlay does not interface well with Roon directly (I read in another topic that JPlay folks are not responsive to Roon’s engineering team for cooperation.). That is one reason I am using the HQPlayer (to bridge between Roon and JPlay). Another is HQPlayer contributes to better sound. BTW I don’t use any HQPlayer filter (i.e. none / none) at all. I know a few other members who have Yggy do that. I suppose HQPlayer has a function of reducing jitter or some sort. My preference for the sound quality in configuring the Audio PC is: JPlay > NAA on x86 > NAA on mRendu (in descending order).

I dearly hope that @Marcin_gps gets involved with this issue since he states that his product works with roon, hqplayer. Based on knowledge gathered so far, let me reduce the problem to “how to use the ultrastream feature offered by JPlay so that no random music play interruption occurs provided one wishes to use Roon and HQPlayer to hand music signal to JPlay streamer (Control PC) and to JPlay (Audio PC)”.

The latter one, but since it is a bit of effort it is not really convenient. Essentially you play a Dirac pulse through it, capture the output (in digital domain) and then determine beginning and end of the impulse response and then store it in a WAV for processing in any convolution engine.

Well, it doesn’t with HQPlayer either. I just didn’t bother to block it like JRiver did.

You are just wasting entire HQPlayer and my 20 years of work… I don’t see any point in chaining as many components as possible in the audio chain that don’t do anything.

So now JPlay got cornered, Dirac got cornered. I feel like I am cornered, too.


That is where got me interested in playing with “no fiter” and/or JPlay in the first place. Jussi, I wonder what made you turn against JPlay specifically.

I have no problem with Dirac for room correction, since it serves a clear purpose. It just imposes limitations and I feel there are better alternatives (explained earlier), but if your DAC cannot do anything higher than 192k PCM you don’t have much problem with Dirac either. It would be best to run Dirac at highest rate it supports, nowadays 192k, so upsample everything to 192/32 in HQPlayer before sending it to Dirac. However, it imposes similar limitations to HQPlayer as JPlay, hiding information about the DAC.

I run my DACs at DSD256 or DSD512 and also want room correction for DSD content without converting to low rate PCM so that rules out Dirac on signal path (except if the filter is extracted and run inside HQPlayer instead).

JPlay in my opinion doesn’t serve any purpose, causes problems and hides necessary information from HQPlayer so it cannot perform at it’s best. It hides information and limits functionality.

For HQPlayer to perform at it’s best it needs to have as direct and low level access to the DAC as possible. For example, if you boot my NAA image, it can get that regardless if you run HQPlayer on Windows, Mac or Linux.

Thank you for your kind and informative comments, Jussi. I love Dirac so much I run 3 copies of it. It does an amazing job on my setup in my office, desktop very near field setup. No way it can sound good the way they are physically placed but Dirac pulls it out. It is so near field(1.2m apart, 40cm in front) setup you can literally reach out and touch someone.On my main system it does more harm than good. Actually very little harm and very little good. So I do not use it. Waiting for an upgraded version. Dirac gives you an idea about what a flat sounds like. Flat equals neutral equals natural equals not artificial equals real equals aha moment.

I posted a support request on the JPlay forum. I will be giving you an update hopefully soon.

@eric, please consider this issue closed. Kinda self-closed it per below:

I hope it is ok to post this link here.


1 Like