Playback dropouts on new Waversa WCore (ref#5OTL63)

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

· Dropouts on playing stored media with new Waversa WCore

Tell us about your home network

· Starlink modem, Waversa WCore3 switch and server, wireworld ethernet cables

I changed from an English Electric switch and Nucleus to a Waversa WCore. I loaded my library into a drive in the Waversa. I have better sound that I really like but am getting dropouts with the stored files, more prominent than the little glitches that can happen with streaming. The dropouts in play occur in both 44 and 192. They last about a second and can occur a minute into a track or in the middle or toward the end and can be single dropouts or a couple close together. There can be a little sound in the breaks, just not all of it. Some seem larger and some smaller. In very bouncy music you may not hear them I think. They are not regular—they can be scattered over a half hour, or there can be a half hour with no problem then four dropouts in five minutes. Possibly there are more at 192 but I’m not sure. I’ve done a power cycle. I’ve had the WCore off at night with its work set for morning when I am not playing music.

2

When this happens what is the processing speed being shown?

3

Thank you! How do I find out?

4

On your now playing screen next to the transport controls to the left there will be a little coloured dot (colour depends on resolution/quality).

Click on the dot and it will show you the signal path with the processing speed near the top in the form of for example 6.5x.

Anything above 1.3x should be fine, if nothing shown then it means it is over 99x and absolutely no concern ever…lol.

As per my screenshot, no processing speed shown.

Screenshot 2026-06-21 192607
Screenshot 2026-06-21 192607879×499 100 KB

5

Thank you!
I think the problem is solved. A friend who knows this gear. Somehow the buffer was set to “off” on the app for the DAC and I am not familiar with the app. Setting it to “on” fixed it. I spent four worried days before I posted here!

6

Unfortunately it wasn’t solved. There are still dropouts, in downloads as well as streaming. I was just lucky when I tried it after turning on the buffer on the DAC. My question is whether there is a setting somewhere in Roon that I need to change. All the equipment has been here for some time and didn’t do this, and the WCore was fine as the main server for the dealer’s shop.

7

Hello @Susan_Tyler

Thank you for reaching Roon support.

I think the next step here is to enable some diagnostics on your account so our technical staff can get some more insight into what’s going on here.

However, before I enable this feature, I’d like to ask for your help ensuring we gather the right information.

First, can you please reproduce the issue once more and note the time at which the error occurs. Then respond here with that time, and I’ll make sure we review the diagnostics related to that timestamp.

8

Thank you. Australian Eastern Standard time. 11:34, 11:35, 11:35, 11:36 all in the middle of a single track. Hasn’t done quite that before. Then played for 15 minutes with no dropouts. Will check again after lunch.

Am back, first track I played, dropout at 12:34 pm, a little bit before where I got the screenshot.

Screenshot 2026-06-23 at 12.34.24 PM
Screenshot 2026-06-23 at 12.34.24 PM1326×108 2.09 KB

Played fine through the rest of that album, started different album, after a little while dropouts at 1:20, 1:23, 1:27, 1:34

Will quit now.

9

Hi @Susan_Tyler,

Thank you for the detailed timestamps. We have gone through the diagnostics and can account for all of the dropouts you reported. There are two separate issues happening at the same time, and both show up clearly in the logs.

Issue 1: Storage read stalls causing HQPlayer buffer starvation (afternoon dropouts)

Your WCore is running Roon Server and HQPlayer together. Roon sends audio from your library on the internal mSATA drive (/root/msata1/Music/) to HQPlayer, which then sends it to your DAC. The logs show that the drive produces a “short read” (returning zero bytes for a read request) approximately every 2 minutes throughout the entire session:

01:32:28 [prebuffer] short read: 0 / 38400 fill=1916135
01:37:16 [prebuffer] short read: 0 / 38400 fill=1912970
01:43:41 [prebuffer] short read: 0 / 38400 fill=1910072
02:34:17 [prebuffer] short read: 0 / 38400 fill=1873112
03:20:44 [prebuffer] short read: 0 / 38400 fill=1895401
03:24:27 [prebuffer] short read: 0 / 38400 fill=1867241

There are 58 of these events across the diagnostic period. On longer tracks this is masked by HQPlayer’s own output buffer staying full. On your short tracks (1 to 2 minutes), the buffer has no margin and drains completely at the track end.

Your 12:34 PM dropout is the clearest example. The track “Missa Mater patris: Sanctus” (2:17 long) was playing normally, then at exactly the moment of the short read at 12:34:17 AEST the HQPlayer buffer collapsed:

12:34:17 [HQP Core] [100% buf] [PLAYING @ 1:52/2:17] Sanctus
12:34:22 [HQP Core]  [50% buf] [PLAYING @ 1:58/2:17] Sanctus
12:34:28 [HQP Core]   [2% buf] [PLAYING @ 2:03/2:17] Sanctus
12:34:33 [HQP Core]   [2% buf] [PLAYING @ 2:09/2:17] Sanctus
12:34:39 [HQP Core]   [2% buf] [PLAYING @ 2:14/2:17] Sanctus

At 2% the DAC is receiving almost no data. That is the dropout you heard.

The same pattern appears at each of your other afternoon times:

  • 1:27 PM: buffer on “En douleur et tristesse” (1:31 long) went 100% to 56% to 9% to 4% in 16 seconds
  • 1:32 PM: HQPlayer reached a full PAUSED state on “Il est de bonne heure ne” with this error logged:
13:32:37 [HQP Core] [4% buf] [PAUSED @ 1:01/1:03] Odhecaton, Canti C
13:32:42 [HQP Core] BufferingTrack == NextTrack during ClearQueuedMedia,
         setting _stop_on_next_track_transition

That last one is Roon hitting an internal queue state error caused by the drive not delivering data in time during a track transition.

Issue 2: Recurring RAAT connection loss between the WCore and the iMac (morning cluster and background)

The logs show 24 separate occasions where the WCore lost its network connection to Susans-iMac-3 at 192.168.1.213:9200 and had to retry. Crucially, this happens not only during playback but also before you started playing and after you stopped:

11:10:46 [raatserver] [RaatServer Susans-iMac-3] lost client connection. Retrying(0)
11:10:56  client connection failed. Retrying in 500ms
11:11:06  client connection failed. Retrying in 750ms
11:11:17  client connection failed. Retrying in 1125ms
11:11:40  client connection failed. Giving up

The same sequence repeated at 11:16, 11:34, 11:57, and continued after you stopped listening at 13:33, 13:52, and beyond. Your 11:34 to 11:36 cluster of four dropouts on a single track corresponds directly to the WCore dropping and failing to re-establish this connection at 11:34:40 AEST, with the reconnection attempts spanning exactly the time window you described.

This is a persistent link instability between the WCore and the iMac regardless of what audio is doing.

Additional finding: Rossini DAC control connection timeouts

The Rossini DAC is logging 36 separate timeout warnings from its RoonReady control interface throughout the session, including clusters of rapid back-to-back timeouts. This points to the WCore having difficulty maintaining stable connections to multiple devices at the same time.

Summary

There are two things to address:

  1. The mSATA drive in the WCore is producing intermittent zero-byte reads roughly every two minutes. This is likely caused by the background library analysis and metadata work competing for drive I/O during playback. As a first step please go to Roon Settings then Library then turn Background Audio Analysis to Off (or Throttled). This removes the I/O competition and may resolve the afternoon dropouts entirely. If it does not, the drive itself may need to be checked for health, or Waversa support may need to look at the WCore’s I/O scheduler configuration for simultaneous playback and library work.
  2. The iMac network link to the WCore is dropping independently of playback, roughly every 15 to 25 minutes. If the iMac is on WiFi, connecting it directly via ethernet to the WCore switch is the most reliable fix. If it is already on ethernet, there may be a port negotiation or sleep/wake issue on the iMac side causing the link to drop.

A couple of questions that will help us confirm which path your audio is actually going through:

  • When a dropout happens, does the progress bar in the Roon “Now Playing” screen freeze and jump, or does it advance smoothly through the gap?
  • Is the iMac connected to the WCore switch via ethernet cable or over WiFi?
10

Thank you very much. I didn’t know you could do something like that!

The status bar continues without any sign of a problem when there is a dropout.

I will make the changes you suggest and try again. However, background audio analysis is set to “scheduled” from 5am to 11am. I didn’t play during that time. Is it different to set it to “throttled”?

From 4-6 yesterday I tried playing from the WCore straight to the Rossini and didn’t experience dropouts.

A friend suggests doing a factory reset on the LinQ so I will try that, but I haven’t yet.

The iMac is my laptop I think? Both my husband and I have a connection to Roon. Both are wifi. I don’t think I can address that since the system is across the room. Does it help to close the laptop? It was just me I think at the time of the multiple dropouts in the morning and through part of early afternoon listening. I read the booklets with it open, but sometimes it is closed.

The little marker on the progress bar does not move evenly but in tiny increments, but it moves at slight erratic speeds—sometimes a little lag and sometimes a little jump—but very small. I haven’t noticed a stop at a dropout but might easily miss it. At the one at 1:16 or :17 am pretty sure it wasn’t an obvious halt since I was staring at the progress bar. It is not I think better or worse with the “off” or “throttled” than with the scheduled from 5 to 11am. I had my laptop open and was looking at Roon some but not all of the time. When looking at Roon the screen went briefly asleep a few times and once fully dark but that was not associated with any dropout.

put “off” on analysis

dropout at 11:48 toward the end of a track

stopped playing after the one track

different album, mostly longer tracks

put “throttled” on analysis

12:47, about 3/4 through a 6:14 minute track

1:11 about 2/3 through 13:12 minute track

1:16 or 1:17 toward the beginning of a 7:33 minute track

4:22.

4:52 about a third into a track of 7:53

11

Hey @Susan_Tyler,

Thanks for the fresh timestamps and additional information!

We can now see that Turning analysis off changed nothing. The short reads are intrinsic to the WCore’s I/O path, not a side effect of analysis work.

The dropouts you’ve reported do not line up with any buffer collapses.

  • 11:48 (analysis Off): you heard a dropout. The log shows the track (a 9:55 piece) at a steady 100% buffer with no short read anywhere near. Healthy playback, audible dropout.
  • 16:22 and 16:52 (direct to Rossini, no HQPlayer): you heard dropouts. The Rossini RAAT stream shows 100% buffer, a textbook-healthy real-time stream. Nothing wrong in the logs at all.
The defining fact: dropouts occur on two completely independent audio pipelines — WCore→HQPlayer→Rossini, and WCore→RAAT→Rossini direct, and in the clean case (direct Rossini) Roon's logs show perfect health at the reported dropout time. When the audible fault is downstream of everything Roon can observe, the cause is almost certainly after the bits leave Roon: the WCore's clocking/output stage, the link from the WCore to the Rossini, or the Rossini's own input handling. Your own observations fit this exactly:
  • The progress bar advances smoothly through every dropout (no freeze/jump) the transport never stalls; only the analog/decoded output glitches.
  • "There can be a little sound in the breaks, just not all of it", partial/garbled output, characteristic of a clocking or interface-level discontinuity, not a buffer underrun (which produces clean silence).
  • Identical symptom at 44.1 and 192 kHz, irregular timing.
  • The same gear on the previous Nucleus + English Electric switch did not do this. The single variable that changed is the WCore (now acting as switch, server, and storage host).
No FLAC decode, CRC, or file-corruption errors appear anywhere in the logs, so the library files themselves are clean.

Let’s see if the following help:

  1. Isolate the WCore as the variable. The strongest test: temporarily put the Nucleus back as Roon Server (or run Roon Server on another machine) feeding the same Rossini, leaving everything else identical. If the dropouts vanish, it's the WCore.
  2. Test the WCore's network/clocking role separately from its server role: try the Rossini connected to a plain switch/router port rather than through the WCore's switch, and try the WCore feeding the Rossini over a different Ethernet cable/port (the WireWorld cables and WCore switch ports are untested variables).
  3. Loop in Waversa. Because the fault seems to be in the WCore's output/switch/clocking domain, Waversa support should review the WCore's I/O and clock configuration for simultaneous storage + switch + server duty. The persistent benign short reads on the mSATA drive are also worth their attention as a drive-health/scheduler check, even though they aren't the dropout cause.
Two questions still genuinely worth asking:
  • Whether the dropouts also occur when playing a Qobuz/streaming track straight to the Rossini (isolates local storage entirely)
  • And whether the WCore is doing DSP/upsampling in its own software outside Roon's signal path.

Thank you! :raising_hands:

12

Thank you Benjamin and Vadim, I understand that there is nothing in this problem to do with Roon software and nothing in Roon that I can alter to fix it. I will explore the experiments you suggest.

I am very relieved to know that there is nothing wrong in the library.

I should have made the DATE clearer. All dropouts listed on my last message were from my June 24th. The message before that to which Vadim responded was from June 23. The listening straight from the Rossini was on the late afternoon of June 23 only.

13

Hello @Susan_Tyler,

Thank you for the clarification on the dates, and we are glad the library is confirmed healthy!

You have summarized it perfectly - the issue is in the WCore’s domain, so Waversa support is the right next step. Please do share Benjamin’s findings with them as it should give their team a clear starting point. Wishing you the best of luck getting it resolved!

14

I should clarify a few things. I was only asked by the form for the networking details. I didn’t know you would be able to see so much so didn’t think to say that the music doesn’t go straight from the WCore to the Rossini in the way that it appears to in what you see. The WCore is attached with a Wireworld silver ethernet cable to an Aqua LinQ and it is the LinQ that has HQPlayer embedded in it. It then goes from the LinQ with an Inakustic AES cable to the Rossini.

I pressed “factory reset” on the HQPlayer module page and went into the page beyond that and reset the buffer, first to default of 0, then to 100, and I unticked the “short buffer” option, none of which helped.

I haven’t noticed that short or long tracks are worse, but it is quite variable anyway. Is it possible that it is not a problem with the WCore sending the music but with the LinQ and its HQPlayer module not asking for the music? That could be why the Rossini can play without a problem. But I can’t fathom why it would be different to how it was with the Nucleus

I did the experiment with playing with the Nucleus instead of the WCore. I don’t have other cables. The dealer did use the WCore in the shop as the server for three different systems and with directions to it coming from several different phones and an iPad over Roon and with Mosaic. So it seems robust enough to handle our single set-up. The wifi here is via a Starlink router but it worked fine with the Nucleus.

I happened to be looking at the progress bar yesterday when there was a dropout. It does seem to stall at that point, but it moves in fits and starts anyway and so there is nothing remarkable about that.

I realise that your concern is Roon and that is cleared, but I did want to follow-up.

Thank you

15

Hello @Susan_Tyler,

Thank you for the follow-up and for the additional detail - this is genuinely helpful.

To your question: yes, it is absolutely possible that the LinQ’s HQPlayer module is the side that is failing to request data correctly rather than the WCore failing to send it. HQPlayer embedded in the LinQ pulls audio from Roon over RAAT and manages its own buffering internally - if something in that request/buffering cycle is misbehaving, the WCore could be perfectly healthy on its end while the LinQ side drops the connection. This would also explain why playing directly to the Rossini via RAAT (bypassing the LinQ entirely) works without dropouts.

Regarding the Nucleus test - did you keep the LinQ in the chain when you switched back to the Nucleus, or did you connect the Nucleus to the Rossini directly? If the dropouts also occurred with Nucleus → LinQ → Rossini, that would point clearly at the LinQ or HQPlayer module rather than the WCore. If the Nucleus worked fine with the same LinQ in the chain, then the WCore remains the variable.

Either way, the most productive next step is Aqua support for the LinQ’s HQPlayer module behavior, armed with the finding that direct WCore → Rossini RAAT playback is clean while the WCore → LinQ → Rossini path is not.

16

I went through various experiments. The only thing left to try was the new AES cable that replaced an older and less good AES. I don’t now have a different AES cable so I connected the streamer to the DAC with a coax cable and then had two hours without a dropout.

I can’t understand how so much could be seen to be going wrong upstream of this cable. And the cable was tested before coming. However, it is good to identify something that seems to fix the problem!

Thank you for the help!