Intermittent playback dropouts with Gustard A26 after update (ref#AIUGHW)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· **Intermittent playback dropouts with Gustard A26 / Roon Bridge after recent updates**

Hi Roon Support,

Since updating Roon and the Roon Bridge installation on my Gustard A26 yesterday, I have been experiencing frequent short audio dropouts.

The same setup worked reliably before the updates. I occasionally experienced a short dropout shortly after startup in the past, but this normally settled quickly. The current behaviour is different: the dropouts can continue repeatedly during playback.

**System**

* Roon / Roon Server: 2.73 build 1694
* Roon Bridge on Gustard: 2.71 build 1689
* DAC/endpoint: Gustard A26
* Gustarender firmware: 1.43
* Gustard A26 connected by Ethernet directly to the modem/router
* Roon Server running on a Windows PC
* PC currently connected to the network via Wi-Fi
* Playback to the A26 via RAAT

**What I have tested**

I have compared several playback methods:

* Tidal through Roon → Gustard A26: appears stable; I was able to play multiple tracks without audible dropouts.
* Qobuz through Roon → Gustard A26: repeated short dropouts, across several consecutive tracks.
* Roon Live Radio → Gustard A26: repeated dropouts on multiple different radio stations.
* Tidal through BubbleUPnP → Gustard A26: stable, with no dropouts during testing.

I initially suspected an internet-streaming/buffering problem, but the RoonServer logs don't appear to support that explanation.

**Reproducible Qobuz example**

On September 25 at approximately **11:41 local time (CEST)** I heard a clear dropout while playing:

The Verve – *Bitter Sweet Symphony (Remastered 2016)*
Qobuz, 16/44 FLAC

Immediately before the audible dropout, Roon reported:

`[100% buf] [PLAYING]`

At **11:41:27** the RoonServer log then recorded:

`Warn: [dac] [zoneplayer/raat] long rtt sync DAC-A26`

with:

`rtt=62495us`

The next RAAT sync at 11:41:30 was back to approximately 762 µs.

The Qobuz track had already been downloaded/cached well before this event, so the dropout does not appear to correspond to an empty Qobuz playback buffer.

**Other RAAT events**

During the problematic Qobuz session I also see multiple `long rtt sync DAC-A26` events, including approximately:

* 306 ms
* 213 ms
* 37 ms
* 263 ms
* 216 ms
* 61 ms
* 62.5 ms

Most of these occurred while Roon continued reporting a full playback buffer.

During Live Radio playback I saw similar behaviour, including much larger RTT excursions in the hundreds of milliseconds. The radio playback buffer also remained populated during at least some of the audible interruptions.

Interestingly, during my later Tidal-through-Roon test, playback was subjectively stable.

Because Tidal via BubbleUPnP to the same Gustard is also stable, I am wondering whether this could involve the RAAT/Roon Bridge path rather than the DAC's general network streaming capability.

**Timing**

The problem became clearly noticeable immediately after the recent Roon/Roon Bridge updates. I don't want to assume that the update itself is necessarily the cause, but the timing makes it worth investigating.

I have retained the RoonServer log containing the 11:41 event and can provide the complete log if useful.

Could you please check whether the diagnostics/logs indicate a RAAT synchronisation issue between Roon Server and Roon Bridge on the Gustard A26, and whether there are any known issues relevant to build 1694 / Roon Bridge build 1689?

I can reproduce the problem and provide exact timestamps for additional dropouts if required.

Thanks!
Peter

Tell us about your home network

· My Roon Server runs on a Windows PC connected to my modem/router via Wi-Fi.

The Gustard A26 is connected directly to the same modem/router via Ethernet.

Network path for Roon playback:

Windows PC / Roon Server → Wi-Fi → modem/router → Ethernet → Gustard A26 / Gustarender.

There are no additional switches or powerline adapters in the audio network path.

The Gustard A26 itself does not use Wi-Fi.

2

Hello @Peter_Alderden

We pulled a set of logs from your server and read the sync figures ourselves. Your numbers were accurate: 347 long round trip events, a median of 0.7 ms against a worst case of 584 ms. On a local network that gap is the whole story. We also see 52 dropouts reported by the Gustard itself, with the number of samples it lost each time.

This is a network problem, and two things in your report point away from where you were looking.

The dropouts are not specific to Qobuz. Fourteen happened during Qobuz and thirty six during other material.

The BubbleUPnP test does not isolate RAAT either. In that setup the Gustard fetches the stream itself, so your PC and its Wi-Fi link are not in the audio path at all. With Roon they are.

So the first thing to change is the Wi-Fi. Please connect the Windows PC to your router by Ethernet and retest. Our guidance is that a Roon Server should always be wired, and with round trips reaching half a second we would want that ruled out before anything else:

3

Do NOT update the Gustard A26, R26, etc, RoonBridge to 2.71 via Roon. The devices are not compatible with 2,71 and will not receive an update as the comms board in them is no longer supported. Frequent dropouts is the main issue. Gustard have told me that there is only one fix available and that is to revert back to the Gustard v1.43 firmware. For me that meant re-flashing the firmware via a direct PC USB connection.

4

Same happened to me with Gustard R26. Frequent audio dropouts after latest updates.

5

Just a quick update on what I’ve tested since my last post.

I connected my Cambridge Audio MXN10 to the same wired network and used it as the Roon endpoint instead of the Gustard A26. With the MXN10 playing directly, I had no dropouts at all.

I then connected the digital coax output of the MXN10 to the coax input of the Gustard A26. So the current chain is:

Roon Server → Ethernet → MXN10 → coax → Gustard A26 → amplifier

This has also been playing without any dropouts so far. The A26 works normally as the DAC, correctly shows the changing sample rates when I switch between tracks, and everything from its coax input onwards seems to be working perfectly.

If I switch back to using the A26 directly as the Roon endpoint over Ethernet, the dropouts return.

So at this point it seems increasingly likely that the problem is somewhere in the A26’s internal network/streaming path (Gustarender/Roon Bridge), rather than the DAC section itself or my general network connection.

I also noticed another R26 owner here reporting frequent dropouts after the latest updates, which sounds very similar to what I’m experiencing.

For now I’ll keep using the MXN10 as the Roon endpoint and the A26 as the DAC, as this setup is stable.

6

Bonjour Peter,

Mes soucis m’apparaissent similaires aux tiens avec mon Audalytic AH90 Roon Server étant hébergé sur un Nuc. J’ai testé Roon via mon Mac et j’ai le même souci. Je pense également depuis les dernières maj. Propre aux Gustard?

7

Hi Roon Support,

I would like to add another Gustard R26 case to this thread. Another R26 owner has now reported similar frequent dropouts after the recent updates, and I have performed a rollback test which produced a significant result.

My setup is: Gustard R26 with Gustarender v1.43., Roon Server is 2.73 build 1696 running on Windows 11 Pro 25H2, Intel Pentium Silver J5005 with 8 GB RAM.

The network is completely wired: Roon Server → Ethernet → Linksys WRT1900AC → Ethernet → Gustard R26. There is no Wi-Fi anywhere in the Server-to-R26 path.

With Roon Bridge 2.71 build 1689 running on the R26, I was experiencing short audible dropouts approximately 3-5 times during a three-hour TIDAL listening session. Rebooting the Roon Server and completely power-cycling the R26 did not resolve the problem.

I checked the Roon logs around one clearly audible dropout. At approximately 03:23:50 the RAAT client for the R26 reported “status: Dropout”. Around the same event there were repeated “long rtt” warnings. RTT is normally below 1 ms on my wired LAN, but around the dropout I saw approximately 51 ms, 34 ms, 36 ms, 42 ms, 32 ms and 65 ms. Shortly afterwards there was another spike of approximately 444 ms. Roon was reporting 100% playback buffer around the dropout.

Today at approximately 18:30 I reflashed the R26 using Gustard’s official Gustarender v1.43 firmware. This restored the bundled Roon Bridge 1.8 build 1125. Roon immediately offers to update it again, but I have deliberately not installed the update.

I then continued playing TIDAL through Roon with exactly the same hardware and network configuration.

After approximately two hours of continuous TIDAL playback with Roon Bridge 1.8 build 1125, there have been ZERO audible dropouts. With 2.71/1689, dropouts would normally already have occurred during this period.

Nothing else was changed. Same R26, same Gustarender v1.43, same Roon Server, same Windows installation, same router, same Ethernet connections and same TIDAL source.

The relevant change was simply:

Roon Bridge 2.71 build 1689 → Roon Bridge 1.8 build 1125

I understand that one A/B test does not conclusively establish the root cause. However, combined with the A26 report in this thread and now another R26 owner reporting similar behaviour after the update, I think a possible regression or compatibility issue between Roon Bridge 2.71/1689 and the Gustard A26/R26 platform deserves investigation.

Could Roon Support please confirm whether this issue is currently being investigated?

Also, is there a supported way to install Roon Bridge 2.70? That was the last version that worked reliably on my R26.

If a regression is confirmed, is a corrected Roon Bridge build planned?

I am happy to provide the relevant Roon logs and exact timestamps if required.

Thank you.

8

Hello @Chris_Causey,

We checked the logs from your Nucleus Titan, and the iPad did connect to it on the morning of October 3, briefly, three times. We have not seen it connect since. Is the iPad working now, or is it still stuck on “Looking for your Roon Server” when you open Roon?

If it is still stuck, please open the iPad’s Settings app, select Roon, and make sure Local Network is turned on:

If that was already on, please toggle it off and back on again.

9

The iPad you’re seeing connected briefly on 10/3 was a different iPad that is working effectively with Roon.

The iPad in question is still stuck.

Local Network was on. Toggling off and back on again as well as closing and relaunching Roon yields the same result. Still searching…

10

@support Any update on this?

My R26 is still running without dropouts after rolling Roon Bridge back from 2.71/1689 to 1.8/1125. The system and fully wired network are otherwise unchanged.

There are now multiple A26/R26 reports in this thread pointing to the same issue. Could you please confirm whether Roon is investigating a possible regression in Bridge 2.71/1689?

11

The problem is a Gustard problem. Their gustardrender board does not have the ability to run the required .net libraries that RoonBridge 2.71 requires. As this board is no longer supported by Gustard there is only one option and that is to keep/reflash the Gustard to v1.43 and ignore the RoonBridge update request within Roon. Roon can’t fix this problem.

12

This is a Roon Ready device that was purchased only a few years ago. It has worked perfectly with Roon for years, and the problem only appeared after the latest Roon Bridge update.

If the hardware is no longer capable of running the latest Roon Bridge version reliably, then Roon should simply not offer that update to this platform. It should remain on the last stable and compatible version.

Nobody is asking for new features or indefinite hardware support. We are asking for an existing, advertised and previously working Roon Ready functionality not to be broken by an incompatible software update.

In my opinion, this is not a Gustard hardware problem. The hardware has not changed. Roon Bridge did.

13

I probably agree with you, the update prompt in Roon probably shouldn’t be there but Roon does not know which devices have RoonBridge installed. Roon provides this package for hardware manufacturers to use if they choose not to add the hardware/firmware required for Roon Ready certification. Raspberry Pi’s use RoonBridge as well and they required software changes by the Linux op system suppliers. Gustard devices have never been Roon Ready certified as they do not have the necessary prerequisites to get certified. Gustard tried to bypass this by putting in a 3rd party board that could run RoonBridge. This board (GustardRender) is no longer supported by the 3rd party and no longer used in their newer products like the R30. And Gustard have told me that they have tried to tell their customers to never upgrade RoonBridge via Roon and to stay on their last firmware release v1.43. So the only solution available to those people that have updated RoonBridge to 2.71 is to reflash the Gustard firmware back to 1.43. I’ve done that and all problems have disappeared. Maybe Roon could offer an update back to RoonBridge 1.8 to affected RoonBridge hardware customers.

14

I really hope the Roon team will fix it soon by reverting to an earlier version of Gustarender for the affected models. I would prefer not to have to revert to an ancient version by reflashing the firmware, which is rather inconvienient.

15

Issue resolved. It was a networking problem and not a Roon issue. ChatGPT walked me through the fix.

16

Hey @Chris_Causey,

That’s great to hear that you were able to both identify and fix the networking issue that caused this. Thank you for sharing that.

I was wondering if there are any updates or more information that those potentially still affected might provide (@Peter_Alderden, @Peter_Randell, @Danil_S, @Regis_MARTIN, @Soma_Wagner).

We’d love to hear from you if this is still an issue, especially since without a reply this request may automatically close.

Thank you :blush:

17

Was able to get AI to solve. Here are the instructions:

That points to a network-access problem on the affected iPad, rather than a Roon update or installation issue. Let’s compare its connection with the working iPad.

  1. On both iPads, open Settings → Wi-Fi → ⓘ beside the connected network.

  2. Compare the network name, and under IPv4 Address, note:

    • IP Address

    • Subnet Mask

    • Router

The iPads should have different IP addresses, but ordinarily the same Router and Subnet Mask. With a subnet mask of 255.255.255.0, the first three parts of their IP addresses should match—for example, 192.168.1.20 and 192.168.1.35. Roon requires the devices to share the appropriate local network.

Next, on the affected iPad, tap Forget This Network, then reconnect to the exact network used by the working iPad. Have your Wi-Fi password available. Retest the server’s http:// address in Safari.

18

Hey @Chris_Causey,

Thank you for sharing these steps with us and the entire community. :raising_hands: We’re glad it worked for you and we trust it will help others as well. :smiling_face:

19

Pour moi seul le retour à la version 1.43s GustardRender résoud momentanément le problème. Merci à l’équipe Roon de nous fournir une solution adaptée qui ne consiste pas à downgrader des éléments afin d’éviter des déconvenues.

Translation
For me, only reverting to version 1.43s of GustardRender temporarily resolves the issue. Thanks to the Roon team for providing a suitable solution that doesn’t involve downgrading components to avoid further problems.

20

I solved the issue by flashing custom firmware (PureOS / PureGus) instead of downgrading. Works perfectly in RAAT mode and also sounds much better.