Thank you again for performing these tests so thoroughly and sharing your findings.
Based on the results, please next build a grouped Zone with 8-7-6-1-3-2-4-5 (in that order) and keep all DSP disable in MUSE. Play content starting at 44.1KHzand build up to 96KHz.
Let us know the approximate time of any stoppages.
Thank you!
Hi @connor .
Been testing with NO DSP whatsoever in that configuration and it is almost impossible for any song to pause and skip. I think it only occurred once but I could not track the moment.
As soon as I reintroduce any DSP the problem starts happening again (the more DSP the more frequent)
What specific DSP filters are you enabling that cause the dropout frequency to increase?
Are you applying any upsampling?
As a test, try adding only parametric EQ, for instance, (nothing else) in MUSE to the same grouped Zone and seeing if you can reproduce the dropouts.
Thank you again.
Hi @connor
Tested with: only convolution, only upsampling (to 96khz) - it seems any DSP will bring back the problems. It seems more frequent with more heavy-duty ones such as convolution equalizersā¦
Thanks for the update @Marcelo_Bulgueroni and for your ongoing patience. The crux of our investigation is whether processing limitations or network limitations are causing the issues you encounter with DSP enabled. Unfortunately, weāll still require a test with only parametric EQ and no filters that result in a larger file size (like upsampling and convolution); otherwise, weāre not positioned to make the distinction between network and processing.
The most recent round of testing showed the same results weād encountered before. The buffer is dropping chunks when DSP is upsampling the file to 96Khz.
We see sample loss in the logs again for your headphone RAAT Zone:
09/29 22:48:17 Trace: [RAAT::Fones de Ouvido Externos] [lua@0xa3e43c008] [127.0.0.1:49680] SENT [115] {"samples":53499,"status":"Dropout"}
09/30 00:01:02 Trace: [RAAT::Fones de Ouvido Externos] [lua@0xa3e43c008] [127.0.0.1:49680] SENT [126] {"samples":44582,"status":"Dropout"}
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23164843 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23168939 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 725 samples at 23173035 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23173760 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23177856 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 724 samples at 23181952 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23182676 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23186772 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 724 samples at 23190868 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23191592 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23195688 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 725 samples at 23199784 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23200509 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 4096 samples at 23204605 [2]
09/30 00:01:02 Warn: [RAAT::Fones de Ouvido Externos] dropout of 724 samples at 23208701 [2We also see upstream discovery (recommendations, etc) failing for the RoonServer itself. At times, the machine doesnāt seem to have a reliable internet connection, or addresses are at least failing to resolve.
Please try disabling HQPlayer and all DSP and playing low-resolution files from streaming services to your grouped Zone in the configuration that prevented clocking issues. Once you have all DSP disabled, add a simple parametric EQ filter to the chain. Please share a screenshot of the Signal Path here.
Weāll watch for your response. Thanks!
Dear @connor ,
Thanks again. I decided to review my network again and found that my roon server was connecting though ethernet not directly to the tp-link switch (as was my memory), but through an older d-link gigabit switch. This d-link switch was on a different location than that of the āmainā switch and I forgot I set it up on the past. Still needing a switch in that place, I replaced it with another, more modern tp-link switch. That d-link switch was one of the first gigabit made by d-linkā¦ maybe it did not play along well with my tp-link environment?
This instantly improved things. Tests on the hardwired endpoints started performing almost perfectly no matter what kind of DSP I throw at it (sometimes playing would stop but on a different pattern than the one we are investigating).
When I added the wi-fi endpoints to the group the problem happens, but also less frequently. But I am now running more tests having all mesh decos plugged to ethernet (so I avoid backhaul pollution through the network). Before one of the mesh decos was connecting to the main one through wi-fi while the other two used ethernet, and researching on tp-link forums I found that having mixed backhaul is not a very good thing on deco networks.
I am running tests nonstop now, since modifying this some days ago. Maybe you can look at the logs and see if this really improved things as it seems. As soon as I find a pattern of the skips (hope not!) I will update here.
Thanks again!
Hello @Marcelo_Bulgueroni ,
Glad to hear that replacing this switch helped with the issue! I took a look over your latest logs and I noticed that the Zorloo still had 3 dropouts, but much less than before. And it looks like the BCM Headphones zone had 2 dropouts as well. Other than these instances, it does look like playback has been much more solid 
.
Hi @noris thanks!
It is indeed MUCH more solid. It just played the whole group with DSP for 13 hours straight without skipping and pausing, which just occurred now at 07:30 / 07:32 PM . This is after I forced all Decos to use ethernet backhaul which seems to improve things.
That would be not even remotely possible before. Iāll keep on with the tests but if this situation persists the endpoints will be functional again.
Hi @Marcelo_Bulgueroni ,
Thanks for keeping us updated on your testing. If playback worked for 13 hours, it does sound like the issue has been resolved and it was all due to that outdated switch 
.
Iāll go ahead and mark your case as solved, but should you encounter any issues, feel free to uncheck the solution box or open a new thread. Thanks and happy listening!
I think we can close it. However I still have issues with non Ethernet endpoints. I will test with the new setup (new router coming today) and if needed Iāll shout here.
Thank you for your patience and kindness throughout all this! Greatly appreciate it.
Well @noris , just to let you knowā¦ set up the new network, rebooted everything, started testing with the group I would work with (three wifi endpoints and two ethernet), and the problem is happening all the timeā¦ ethernet is better but feels like Iām back to stage zero on this. All mesh points connected through ethernet, stronger signal throughout the houseā¦ but the issue consistently repeats itself on wi-fi endpointsā¦ think iāll give up and assume chromecast audio is the only way. Thanks anyway for all the help.