Audio artifacts with Wattson Audio Emerson Digital using RAAT (ref#BFMIJ0)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· App interface looks or behaves oddly

Tell us what's going on

· Audio artifacts (clicking and skipping on pause) with Wattson Audio Emerson Digital - RAAT only

Tell us about your home network

· FRITZ Box 7530 AX, YuanLey 2,5Gbe

2

Just to add more information:

I am experiencing some frustrating audio artifacts with my Wattson Audio Emerson Digital (Roon Ready endpoint). While the sound quality is excellent, the playback behavior is inconsistent.

The Issue:

  1. Audible “Click” on track change: Every time I skip to the next track there is a distinct, annoying electronic “click/pop” sound.

  2. Skipping/Stuttering on Pause: When I press “Pause,” the audio doesn’t stop instantly. It performs a sort of “mini-jump” or repeats a fraction of a second of audio before finally going silent.

Crucial Context:

  • The issue occurs ONLY with Roon (RAAT).

  • I have tested the device using Qobuz Connect and it works perfectly. Through Qobuz native streaming, the track changes are silent and the pause function is immediate and clean.

  • This leads me to believe there is a specific integration issue between Roon’s RAAT protocol and the Wattson Audio firmware/buffer management.

I have the latest firmare: 2025.10.21.bin (2025-OCT-21)

3

Setup Details:
Roon Core: roon ROC on NUC: Version 2.1 (build 271) production

Endpoint: Wattson Audio Emerson Digital (Firmware is up to date)

Network: Connected via Ethernet (Cat 6/7)

DAC Connection: Both S/PDIF Coax and AES/EBU to Mola Mola Tambaqui DAC and TEAC VRDS 701

4

Hello @Granosalis

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.

5

Hi,
I have just reproduced the issue. Starting from 9:00 PM to approximately 9:03 PM (Italian time), I played some tracks from Qobuz, testing track changes, pause/play, and other functions to trigger the issue.
Please review the diagnostics for this specific timeframe.
Thank you!

6

Hey @Granosalis,

Thanks for the timestamp! We were able to review the times you’ve provided and saw that you’re getting dropout reports from the device immediately after resume from pause, meaning the buffer isn’t being refilled fast enough before playback restarts.

[raatclient] GOT [213764] {"status":"Dropout","samples":13501}
[raatclient] GOT [213764] {"status":"Dropout","samples":11292}

A few next troubleshooting steps for you:

  • Check Roon's "Resync Delay" setting for the Emerson endpoint. Go to Settings → Audio → click the gear icon on the Emerson → Device Setup. Try setting a resync delay of 500ms–1000ms. This forces Roon to wait before sending audio after a resume, giving the buffer time to fill.
  • What is your Volume Control setting set to with your Emerson endpoint > device settings?
Thank you! 👍
7

Hi @benjamin
Thank you for your previous suggestions. I have performed the tests as requested, but unfortunately, the issue has not been resolved.

Here are the details of my setup and the tests performed:
Volume Control: The setting for my Emerson Digital is set to Fixed.
Test Timestamps: I conducted tests today between 07:53 AM and 07:56 AM (CEST/Italian Time).
Resync Delay: I tried setting the Resync Delay to both 500ms and 1000ms, but the problem persists.
Symptoms: I am experiencing continuous dropouts not only after resuming from pause but also during play, pause, and track skipping operations.
Looking forward to your further guidance.

Best regards.
Giuseppe

8

Thanks for the update and additional information @Granosalis! A fresh Roon Server diagnostic report has shown some additional information.

The most important finding is the pause-to-stop downgrade behavior. Every single time you press Pause, this is what happens via RAAT:

15:09:56 zone Emerson PlayPause (you press pause)
15:09:56 Endpoint: Playing => Paused
15:09:56 SENT → {"request":"stop"} ← Roon sends a STOP, not a pause hold
15:09:57 GOT ← {"status":"Stopped"}
15:10:01 Endpoint: Paused => Prepared ← 5 seconds later...
15:10:01 Endpoint: Prepared => Idle
15:10:01 SENT → {"request":"end_stream"} ← Stream fully torn down
15:10:01 SENT → {"request":"teardown"}
15:10:01 zone: [no playback for 5s, suspending to release audio device]

So Roon does implement a native Pause state Playing => Paused but the Wattson Emerson responds to the stop command and then sends back an “Ended” status, which forces Roon to fully tear down the stream after 5 seconds. This is the Emerson’s firmware treating a pause-stop as a full stream termination.

When you then press Play again, Roon has to cold-start the stream from scratch: Idle → Prepared → Buffering → Ready → Playing. This full re-initialization cycle is what causes the audio stutter and the click — the DAC’s audio pipeline is re-initialized mid-session.

This is something Emerson may need to review directly. The primary issue, the stop command causing a full stream teardown instead of a true pause-hold is likely in the Emerson’s RAAT firmware implementation. The device does not appear to be preserving the audio pipeline across a pause. Roon’s side of the protocol is seeminly working correctly; it sends a proper pause-stop, but the Emerson’s response (sending “Ended” status back) forces that full teardown.

We’ll have our team get in touch with Emerson, but it may be quite useful for you to reach out to their support as well.

In the meantime, let’s see if any of the below may help:

  • Try increasing to 2000ms. The logs show wait for ready times ranging from 0ms to 332ms on stream restart. A larger resync delay gives the DAC more time to stabilize before audio output, which may reduce or eliminate the post-pause click.
  • DSP / Sample Rate Conversion: You are running Enhanced DSP upsampling (16/44 and 24/44/96 → 24/192 consistently). Try temporarily disabling upsampling to test if the click persists. Since the audio pipeline re-initialization involves a sample rate change (the upsampler needs to restart), disabling it may reduce the click even if it doesn't fix the stutter.
Lastly, your current setting is Fixed volume. This is correct for a DAC that controls its own volume, but confirm in Roon that it's set to "Device Volume" (not "Fixed" which might bypass some muting logic). Some users have found that switching between these modes affects whether Roon mutes the output before/after a stream transition.

Thank you :folded_hands:

10

I have carried out the tests you requested. I disabled the DSP (I hadn’t realized it was active during the last test, though I noticed it has no impact on the issue), increased the buffer to 2000ms, and tested the volume in both ‘Fixed’ and ‘Device Volume’ modes.

Could you please analyze the logs from today between 15:25 and 15:27? The issue persists and nothing seems to have changed.

In the interest of improving this integration, I would also like to point out that Roon’s Signal Path always displays ‘DSP Volume: 0.00dB’, whether the volume is set to Fixed or Device Volume, as shown in the attached image.

I truly hope Wattson Audio is following this thread and will work to resolve these issues; they are currently penalizing a device using Roon, that is otherwise a sonic masterpiece.

Thank you.

Giuseppe

image
image1010×903 106 KB

11

Hi @Granosalis,

Thanks for giving that a try! We’ve escalated this issue to our partners team for additional investigation.

Another test to try if you haven’t yet: test with a 44.1kHz-only Qobuz playlist (no 96kHz content). The logs show the Emerson handles the very first 44.1kHz stream cleanly (no dropouts for 5 minutes straight). Problems begin after the first stream teardown/restart. Testing exclusively with one sample rate removes any potential format-switch variable and may help to better isolate the issue.

Thank you!

12

I’ve performed the test as requested between 15:50 and 15:52 using a 16/44-only playlist. I also switched to Tidal for a further check, but the result remains the same.

13

Thanks!

Giuseppe

14

Hi @Granosalis,

Thanks for confirming. We believe we have everything we need at this point, the partners team has reached out to Wattson Audio, and once we hear back regarding next steps, we will let you know. Thanks!

1 Like