Hi,
I experience rare dropouts when using Roon core with Sonore Microrendu with following error messages in Roon core log:
10/16 19:42:37 Trace: RAAT endpoint is having trouble keeping up. Setting rate limit to 20000000 10/16 19:42:37 Trace: [raat/audiosource] got NAK (15 seqs, 15 satisfied is_max=True) 10/16 19:42:37 Trace: [transport/raatclient] GOT [69] {"status":"Dropout","samples":3760} 10/16 19:42:37 Trace: [transport/raatclient] GOT [69] {"status":"Dropout","samples":4410} ...
Are such errors are related to some network issue or this is a Microrendu issue? Any help?
Here is my setup:
- Roon Core 1.2 (build 161) on Mac OS X 10.11.4, Mac Mini 2011 Core i7 2.7 Hz, 8Gb RAM, SSD drive, 4337 tracks.
- Sonore Microrendu 2.3
- Apple Airport Extreme A 1408 router with firmware 7.6.5, standard Cat 5e ethernet cables.
Interesting. Out of curiosity, grepped today’s log, and found lots of NAKs while playing one of the few 192/24 PCM albums in my collection.
- Roon Core 1.2 (161) on Intel i5 (8Gb memory, 220GB SSD) with Ubuntu 16.04.1
- Library on Synology DS216+II, DSM 6.0.2
- Cat 6 networking between all the items, switched with Netgear GS108E (1Gb)
- microRendu with 2.3 software
- Schiit Bifrost Multibit DAC
Wondering the microRendu is getting a bit overloaded by 192/24 PCM. Logs have no NAKs when playing lower rate PCM. @Jesus_Rodriguez
I was playing 44/24 album at the moment of dropout
Looked at my logs, found 7 of those RAAT “trouble” warnings for the microRendu:
2 x 192/24 (Oct 16)
1 x 88.2/24 (Oct 15)
2 x 192/24 (Oct 14)
2 x 96/24 (Oct 7)
However, I don’t recall hearing dropouts any of those cases, which would be really noticeable because the microRendu connects to a headphone system.
One puzzling thing is that I also have a Sonicorbiter SE downstairs, much longer run of Cat 6 from the same switch, play much of the same music there, and there are no “trouble” warnings for it. The main router that links to my cable modem at the end of that run, but everything to do with Roon (NAS and NUC) is here upstairs. Next thing I’m doing is trying a different Ethernet cable for the microRendu to see if there’s a difference in the logs, but I really doubt.
10/16 19:42:37 Trace: RAAT endpoint is having trouble keeping up. Setting rate limit to 20000000
This is not an error, or an indication of any trouble.
RAAT uses UDP to transmit audio. Since UDP doesn’t have flow control built in, we have to do that ourselves. Our flow control system is based on feedback from the endpoint about packet loss. In other words, if packets are being dropped, we need to slow down the rate of outgoing traffic until the level of packet loss is more tolerable.
If you’re thinking “but doesn’t the audio stream’s bitrate determine the rate of packets going out over the network?”, the answer is: when you first start playback, RAAT fills an initial buffer on the endpoint as quickly as possible prior to the start of playback, and only starts playback once that buffer is at an acceptable level.
The difference between the best case and worst case scenarios for filling that buffer span a couple of orders of magnitude, depending on the performance of your network, the performance of the networking hardware on the Core and Endpoint devices, and the performance of the CPU on the core and endpoint devices. If we spray a fire-hose at the wrong time, nothing good happens, but that same fire-hose produces nearly instantaneous playback in many other situations.
The flow control algorithm is working out the appropriate playback rate on the fly based on information about lost packets (which are, of course, then resent to avoid dropouts). Those trace messages just note points in time when the algorithm makes decisions. Almost everyone’s logs will have some of them, as the Core re-calculates the appropriate buffer fill rates for each endpoint each time the endpoint and Core connect and begin playback for the first time.
Ok, that was the technical explanation of the logs…moving onto the actual issue.
My thoughts:
- The microRendu is fairly powerful. Certainly more than powerful enough to handle 192k playback, and it has a good track record for doing so, so I don’t think this is a matter of the CPU being overloaded on that device.
- Core performance can sometimes impact this sort of thing, but neither of you are running underpowered hardware, so that seems unlikely, unless the systems are totally overloaded for some other reason.
- This leaves the network as the most likely culprit.
@support should be along to help troubleshoot along these lines.
1 Like
Thank you very much for your reply, looks that I should consider buying a switch…
I had lots of issues going to the mR till I added a good quality unmanaged switch. Internet modem plugs into switch. All wired devices on network plug into switch.
Switch solved the problems. Now just a very occasional split second drop out.
I don’t like even split second dropout 
Can I be sure that simple unmanaged switch like Netgear GS 605 will solve my issue?
Nothing is for sure. Decent chance it will work. Doesn’t cost a lot to try.
Installed Netgear GS 205 switch and it completely cured the issue. I’m listening microrendu for more than week and there are no audible dropouts. Log files are also free from NAK messages. The only thing that I noticed once was a short pause between two gapless tracks. It was not logged as dropout and I was not able to reproduce it more times. Question to @brian: I already seen old reports about rare pauses between gapless tracks on the board, but it seems to be fixed in Roon for a while. Do you have any pending issue tickets regarding gapless playback? Is it possible to catch such issue in Roon logs?
I haven’t heard a report like that for a long time. There are no issues like that open.
@support, have you guys heard anything?
@brian and @vladimirkl ---- I have not heard anything as of recent. I am familiar with the thread that is being referenced and we tested media in house if memory servers correctly and reported no issues back to the user.
-Eric
@brian, @support - sorry, but I’m sure that Roon has a problem with gapless - at least for me. Got another random pause between gapless tracks on another album. The whole album is just one long song splitted to 7 tracks. Total length is about 40 minutes of 44/16 audio. I’ve got a pause before last track but all previous track transitions were correct. Was not able to reproduce issue again. Please let me know how you can solve my issue and what I should provide to help diagnose it. Unfortunately issue is not specific for single album and no easy way to reproduce it. I can send you tracks but not sure that you will get same issue again. Is there some debug mode that may help to catch this issue in log? I can switch it on and play on mute several different albums for a long time.
Yeah, I believe you’re having a problem–was just answering your question directly by saying we aren’t currently tracking this issue.
The best thing to move forward would be a support package captured immediately after the issue occurs. @support can provide some resources for how to do that.
1 Like
Hi @vladimirkl ----- Thank you for the feedback. I will be following up with you momentarily via PM to grab a set of logs from you so our developers can have a closer look into this issue.
-Eric
Having the same problem with MicroRendu…dropout every 15 seconds or so…mr is run off cable connection to Airport time capsule with MacMini core also connected to that…will try netgear switch next week when I can get hold of one. Problem seeks worse than when I installed mR a few days ago, and also seems to be getting worse daily so it should be called frequent rather than occasional dropouts now
Hi @diw ------ Thank you for the report, my apologies for the troubles here. To help aide in my evaluation of this issue you are experiencing may I kindly ask you to please provide the following:
-
An expanded description of your current setup as seen here. The more detailed you can be, the better
-
An expanded description of your network configuration / topology as well as some insight into any networking hardware you may be implementing in your setup. I would like to understand how your devices are communicating and what tools are being used to make those connections possible.
-
You mentioned…
“Problem seeks worse than when I installed mR a few days ago, and also seems to be getting worse daily so it should be called frequent rather than occasional dropouts now”
Can you please provide some insight or clarification into this statement so I have a better sense of the, lineage of this issue. Furthermore, do these dropouts seem to be worse or in less frequency depending on the codec + sample / bit rate of the media being streamed?
-Eric