[BUG] stuttering audio

[hgw77]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I’m experiencing intermittent stuttering audio when using Webtop. This occurs on different clients (both Windows and Linux-based) using Chromium. When I check the statistics on the Selkies Dashboard, I notice that the audio buffer constantly fluctuates between 0 and 6 or 7, then drops back to 0. I suspect that when the buffer reaches 0, it causes the stuttering.

My experience with Webtop audio is quite inconsistent — sometimes it runs smoothly, while at other times there is stuttering. I’ve tested different server hardware and client machines, as well as both WLAN and wired connections, but these factors do not seem to be the cause.

Maybe there is a sync issue with frame rate and Audio?

I also noticed more stuttering when I open the selkies dashboard and keep it open for a little time.

Expected Behavior

Option to change the audio buffer size or the possibility to choose a more lazy method for audio streaming on client side?

Steps To Reproduce

1. Play for instance a Video in Youtube
2. Open selkies dashboard and keep it open
3. Check the statistics for Audio in the Selkies Dashboard

Environment

- OS:
- How docker service was installed:

Docker creation

-

Container logs

-

[ne0YT]

on the kasm dockers it was good. here sadly not. maybe possible to port that back?

[hgw77]

I dug a little deeper because sometimes it was working for me and sometimes not. It seemed random at first, but now I think I’ve identified the culprit. In my case, it was a WLAN router that had been running for ages. When my laptop was connected to that hotspot (via WLAN or LAN), I experienced stuttering audio. However, when I connected the laptop directly to the LAN where the server is running, everything went smoothly, and I noticed the audio buffer stayed stable around 2 or 3. After restarting the WLAN router, the situation improved, but the stuttering hasn’t disappeared completely. It seems the audio is quite sensitive, and any small lag can cause the stuttering to occur. So I guess on weak connections this is still a thing......

[thelamer]

Check for dropped packets https://packetlosstest.com/

I have said it before but I cannot replicate this, I have been full timing a server in Finland from North Carolina for a couple days now it just works outside of some back pressure incidents.
(I use spotube to listen to music all day in a tab)

[hgw77]

Yes, it seems to me that sometimes, when there are packet drops, the audio experiences problems. In that case, would it be possible to add an option to the Selkies dashboard for something like “lazy audio,” where the buffer is larger and synchronization less strict?

This would result in slightly out-of-sync audio, but that wouldn’t matter when playing only audio. For example, in Kaasm I had an issue where, when I played music and pressed the stop button, the audio continued for one to two seconds before stopping. But that didn't bother me

[ne0YT]

Yes, it seems to me that sometimes, when there are packet drops, the audio experiences problems. In that case, would it be possible to add an option to the Selkies dashboard for something like “lazy audio,” where the buffer is larger and synchronization less strict?

This would result in slightly out-of-sync audio, but that wouldn’t matter when playing only audio. For example, in Kaasm I had an issue where, when I played music and pressed the stop button, the audio continued for one to two seconds before stopping. But that didn't bother me

exactly the same for me.

[hgw77]

From my side, we can consider this issue resolved. It seems that when the network connection is poor and packet loss is high, it causes audio stuttering. I'm not sure if there’s a way to make the audio streaming more tolerant, but I suppose that with excessive packet loss, stuttering is unavoidable.

[thelamer]

I cannot work around packet loss, FEC would be overkill in this stack.

[ne0YT]

I cannot work around packet loss, FEC would be overkill in this stack.

I can just say that on your kasm implementation with the audio solution there , I don't have the issue.