Frequent Playback Interruptions in Roon ARC with Qudelix 5K (ref#3FAJ4B)

Support
1

What’s happening?

· I'm having trouble with Roon ARC

What best describes your issue with ARC

· Other

Describe the issue

Frequent Playback Interruptions in Roon ARC with Qudelix 5k

Basically a copy of https://community.roonlabs.com/t/frequent-playback-interruptions-in-roon-arc-with-qudelix-5k-ref-tiyp66/283616 - except for RoonServer hardware that is now supported, eg. no virtualization.

Playback stopped at 15:36, 15:37, 15:50, 16:00, 16:08, 16:13, 16:16, sometimes it restarted when Roon ARC was brought into foreground, sometimes not.

Describe your network setup

1GBit optical connection, router Sagemcom, RoonServer on Debian on 64GB AMD Ryzen 7940HS ethernet connected, no virtualization. Phone is Xperia 1 V, unlimited 5G, DAC is Qudelix 5k.

3

Hi @Rp1984,

Thank you for your post.

We’ve taken a look at diagnostics around the timestamps you submitted to illuminate ARC and RoonServer’s connectivity states and the status of the audio engine. Here’s what we’ve found:

  1. ARC experiences a period of poor connectivity and the buffer from Tidal’s servers begins to struggle during playback. ARC doesn’t always recover - in at least one case, the packet loss was sufficient for ARC to stop the playback stream, having never received corrected packets.

  2. ARC additionally reports dropouts in the Bluetooth connection to the Qudelix DAC itself. These too accumulate sufficiently to kill the audio stream.

Perhaps it would help to describe how you are connecting to this DAC. If you were in an urban environment with a large number of other cell and Bluetooth signals, it’s possible interference played a role in this experience. If you were driving in a rural area, then patchy cell service might have been sufficient cause.

Can you please describe more about your surroundings and the physical setup with which you were using this DAC? If we identify a change we can make to improve this experience, we’ll work with development to put a fix in the pipeline. However, we can’t always predict how well ARC will recover from conditions of true connectivity loss or interference. Either way, we’ll watch for your response and do our best to assist.

1 Like
4

Hi @connor , thanks for looking.

I was walking in an urban environment around 15:36 (it was quite crowded), around 16:00 I believe it was underground transport (so again, crowded, but we have cell reception there) and around 16:10 this was an area without any crowd in the suburbs, but still an urban area.

Not sure what to say about the physical setup - phone was in the left pocket, DAC in a right pocket, DAC connected using BT to Android phone, playing through wired headphones. The codec between Phone and DAC is LDAC, it usually select 990kbps but is adaptive, I’ve never seen it less than 660kbps.

I read somewhere on the forums that ARC buffers Tidal streams quite aggressively, getting the whole song if possible. Today I have not tried, but usually, when I have an interruption, in roughly the same areas I run speed test and seeing like 150Mbits downstream is not uncommon - I mean those are areas with quite good signal reception. So I am wondering how much aggressively ARC buffers, or is allowed to buffer - can it buffer only currently playing song, or can it buffer some songs forward? Can it perhaps provide adaptive stream quality so it will start with flac and go down if needed? The fact that I perceive Tidal as stable and that I even don’t remember when it interrupted playing is really fishy, there has to be some significant difference that makes or breaks the experience, even though both apps are using the same quality setting and both are streaming, no offline content. It more and more feels like an unfair fight.

5

Today I’ve come up with an experiment to find out why do I think that Tidal works when I am not using it and the same way do I perceive Roon ARC as faulty when it works most of the time: whenever there will be an interruption, I’ll note the time and switch to the other application that is setup to use streaming only and the same audio quality (CD quality). When it will interrupt the playback, I’ll switch back to the previous application. This way, if the interruption is caused by interference with 5G or BT, the other application will also have issues, as I’ll switch when the interference is making the playback impossible. And keeping the application I’ve switched to in use for longer should rule out some luck it could had and due to some periodical events in my life, I’ll end up running both applications at the same areas and at the same times sooner or later. And the results will be easily understandable without any statistics as I’ll simply know what I use.

So I’ve cleared Tidal storage and cache and what happened during my trip to the city was that Roon ARC lasted 10 minutes, the playback interrupted on the escalators on my way to underground transport, understandable but rules are rules, so I’ve switched to Tidal application for audio streaming. The transport was more crowded than yesterday as it runs in limited regime during the weekends. And I did not encounter another interruption ever since and all the time I was in the city center or taking transport in roughly in the same area as yesterday.

What was new and happened twice was a crack during the playback, which I assume was due to Tidal trying to not interrupt the playback no matter what. As I’ve never heard this crack with Roon ARC, I assume it interrupts the playback before the crack has a chance to happen. It is quite soon to say, but I think the experiment show that streaming implementation that is less susceptible to interference or bad network conditions is achievable without lowering the requested sound quality (and raises a question what, if anything, gets compromised, perhaps if the sound quality reported by Tidal is real).

What do you think about this experiment, do you see any flaws in my logic?

6

Hey @Rp1984,

While it certainly makes sense, it’s difficult to compare TIdal and Arc, as they function a bit differently. Do you ever get an interruption with Arc outside of urban environments?

Can you test out a hardwire connection from your phone to the DAC?

Do you ever experience issues when playing downloaded tracks in Arc using the DAC?

Thanks for your continued troubleshooting!

7

For the case of Tidal streaming, the stream goes from Tidal servers directly to the mobile phone for both applications, right? Alas with the bluetooth connection to the DAC, how differently would this work? As far as for the playback interruption causing events, they both are exposed to the same environment, it is not like one is hard-wired and other is using BT. I understand Roon does much more, don’t worry. Yet anyone who will come from streaming world will hit the issues they are not used to.

Outside of urban environments it usually is fine. I mostly listen in car and there I can see that I am on Edge or without the signal completely, so the issues are expected. This is different from interruptions in an urban area where if I check if internet works, it does.

On Friday I’ve used hard-wired connection to DAC. Got interruptions, too:

  1. 18:04 (and also 18:02 - this one was right after I’ve left the cinema, so like first song played after few hours and I kind of ignored it as one of a kind, yet it was just a beginning)

  2. 18:21 (this was interesting as next song was stuck at time 0 when I brought ARC to foreground to resume playback, not sure if there is some connection to Roon Server required at each new song, eg. for loudness data?)

What I think can be useful for more experiments is that I’ve managed to identify a spot in the city that has high interference (18:04), the initial interruptions in this ticket were from that place, too. What is really unfortunate when playback interruption happens is that to resume the playback, one has to take phone out of the pocket and unlock it, now if one is in a very crowded place after dark, one has to think about who is around as one does not want to lose the phone, right… so when that happens, one is looking for a safe place that is a bit shielded, fix the playback, and in few minutes, one is in a need of a safe place again, so it is, and becomes, very distracting.

I’ve than switched to Tidal + BT connection to DAC, no issues afterwards.

Did not have a chance yet. My use case is mainly streaming, I don’t own a lot of downloaded tracks, but I’ll try to test that on that “place of interference”.

Thanks, I am hoping ARC will get more stable for everyone, Roon is wonderful software overall.

8

Hi @Rp1984,

When you experience interruptions, has ARC been open on this phone in the background for an extended period of time?

What do you have set for playback quality in the ARC settings page? This will determine how ARC handles the balance between file format and network connectivity.

If you’re referring to the Tidal app here, it has an entirely separate downloading, buffering, and distribution mechanism from ARC, which is based on Roon/RAAT. The apps have different priorities.

Both apps have adaptive buffering. Both can respond to fluctuations in cellular connectivity by adjusting playback quality. They differ in how and when they do so. Tidal’s priority tends to be uninterrupted streaming experience. Roon/ARC’s priority is transparency to source (sound quality). ARC relies heavily on large buffers and caching to enable uninterrupted playback of large files. If you’re hearing interruptions with Tidal content in ARC, it means the download from Tidal’s servers has already timed out or failed to return missing packets for some time.

The DAC is also caching content as it receives it via Bluetooth. Let’s simplify this signal path.

Disable all DSP and play to local headphones or the system output of the phone rather than the DAC.

9

Probably yes, as I am not stopping it explicitly. With the AndroidAuto troubleshooting, if ARC was in the background or not did not make a difference, only force stopping it did.

Normally I have cellular and wifi connections set both to “CD quality”.

Yes, I am comparing ARC to mobile Tidal application. Perhaps I am mistaken, but I clearly see connection transferring 10mb or so from Tidal servers directly to the phone - I assume it is audio content. This does not timeout for Tidal in any way - or - Tidal adaptively changes the stream quality. Outside of lab or some precise listening environment this sounds like a reasonable thing to do, but that is subjective, of course.

Today, at like 20:20, I’ve finally got ARC 312. So that means there was no long-lived ARC instance in the background. I’ve disabled all DSP except for sample rate conversion. Used wired headphones connected to the phone. Started with “CD quality” setting. The times are times when interruption happened.

While waited for public transport in not very crowded urban area:

20:25 - 2x
20:26
20:27

Entered public transport, quite crowded.
Decided to switch to “balanced quality”.

20:29

Decided to switch to “automatically pick best quality”.

20:34

Left public transport, no longer listening.

11

Thanks for the update @Rp1984,

At this time, we unfortunately don’t have any additional troubleshooting steps for you to try. You could test out removing all DSP including sample rate conversion, but either way, we have a ticket in with our Arc dev team for further investigation.

Progress will likely be slower on this, so I appreciate your continued patience while the team takes a closer look. Thank you! :raised_hands:

13

Hi @Rp1984,

If you have a second Bluetooth DAC, try to reproduce the same connectivity issues.

Do you have any unique permissions in Settings → Apps or elsewhere on this Andorid device that might restricting the interaction between the Android OS and the DAC’s firmware?

We can see the audio transport throwing errors while this DAC is connected, but they may be a downstream result of connectivity issues.

If this is specific to the ARC / Android audio output handling with this device, it will require a device-specific fix from development; this is why we want to taper expectations about a quick resolution time. We will, however, continue to investigate the cause.

15

Hi @connor , thanks for the update, unfortunately Qudelix is my first portable Bluetooth DAC. Checked the settings and nothing stands out.

I’ve tried to remove sample rate conversion as that was also one of the recommendation and have some interesting results: no matter what I select in sample rate conversion screen, it always ends up as 48khz. In device setup screen, the DAC shows it supports just 48khz and Qudelix app will report 48khz as a sampling rate (no matter if used through USB, with beta driver or without, or through Bluetooth).

With USB Audio Player Pro and with DAC in USB mode, Qudelix app reports the sampling rate as the audio is in, eg. for 88khz flac it will show 88khz. Yet with Bluetooth, Qudelix app always reports the highest enabled sampling rate by the LDAC codec which by default is 96khz. I found this as I realized that I am after CD quality anyway so 96khz does not make much sense, but 48 does not as well so I tried to get rid of it and that turned out impossible! :slight_smile: So for USB, it looks like ARC does not see the DAC the same way as Audio Player Pro. Yet generally, is it somehow possible to get rid of this resampling for compatibility to 48khz in Muse? It seems the DAC is not properly recognized by ARC (or Android limitations in audio domain do not allow for it to be properly recognized, not trying to point the fingers here, just stating what I saw).

Along the way, something funny happened:
On Sunday at 23:11, I was using BT with DAC, the output name was Android Auto, yet I was already at home for at least an hour. Force stopped ARC, at 23:12, the output name was correctly shown as Qudelix-5k. Not sure if this is purely cosmetic as in both cases the playback was audible through headphones.

I’ve written a comment on Thursday or so that everything works with Bluetooth and locally downloaded files, but turned out it is not true, I’ve got interruptions on Friday at 19:34 and 19:36, but I guess it is now clear there is something going on with the DAC.

16

Thanks for the additional report!

We don’t have any next steps or updates at this time - development has a ticket in their queue for additional investigation, so we’ll update with any new information that is presented.

Thanks for your patience in the meantime! :raised_hands:

17

Sometimes, patience and hope is all what is left.

18

Hi @Rp1984,

The logging we’ve investigated supports two possible causes here:

  1. This is specific to the interaction between the device and the Android framework API in use, which will require a device-specific fix from ARC developers to address the Qudelix 5k on Android

OR

  1. This particular digital chain just exposes cellular connectivity issues from which ARC would otherwise recover through buffering

The ARC team is constantly iterating on connectivity stability - I recommend you try out the latest Early Access release to help reduce the potential for issue #2 above.

Concerning the first possibility, we should have a more precise answer from Development shortly.

19

Thanks for the update. So far it seems that in ARC 100326, streaming is much more stable. In two days I’ve had only one major issue and one minor one, both on Friday (with Qudelix and BT):

  1. 14:37 - short cracking sound artifact while leaving the subway, so there could have been some 5g reconnect - heard for the first time with Roon ARC. Mentioning this only if you would be interested in logs of some situation that recovered correctly without playback getting interrupted and that is great
  2. 20:20 - playback stopped, had to bring ARC to foreground and manually start the playback. I am not sure if I left ARC in the foreground or not, it actually seemed like it was starting again but I am not 100% sure about that now

I would like to give it a few more days as an opportunity to test during festive season with all the crowds does not come every day, but so far it appears that the changes made a huge difference for streaming stability.

20

Hi @Rp1984,

We’re adding more verbose logging to the RAAT level in ARC so we can identify any particular failures here. Thank you again for your patience and ongoing help. We should have more information soon.

21

Thanks, so I guess I’ll wait for an update and report something again then.

22

We’ll make sure the thread remains open in the interim. Once Development has reached a conclusive next step we’ll promptly share it here. Thank you again for your patience.

24

Thanks. Today I’ve verified for a third time there seem to be a small issue with the change of networks: if playback of the whole album is started on WiFi, then second song will not start playing if mobile switches to 5G (use-case: one starts playback home and leaves). When connection is 5g and playback is restarted, it continues without issues. So it seems the activation of a different network interface is the culprit. It also suggests that when next song is about to play, a working connection is required to continue the playback - if that is so, in “occasionally connected” system it is hard to guarantee. Those times mark when the issue happened:

1/3/2005 - 15:06
1/6/2005 - 19:26

25

Thank you @Rp1984. At this time, development is adding more verbose logging that will illuminate the interaction between Android and ARC during the precise conditions you’ve just elaborated. However, this will require us to ask for your ongoing patience, as this logging won’t take effect until the next Roon release.

Once that happens, we should be equipped to quickly resolve to this problem. Thank you again.