2 sec stuttering at the start of stream - buffering issue?

[geekmiki]

Hi, There is a 2 sec stuttering when starting a stream, independently of the service/app I am using (Apple Music, Spotify, direct link to mp3 stream), as if there was buffering. It is inconsistent, happens maybe 10 times in a row and then once every 3 tracks. Is there a way to define a buffer level before starting to play in order to mitigate the issue?

Thanks.

[fduncanh]

please give more details of your system (e.g. desktop or r Pi etc) operating system and so on.

[geekmiki]

Thanks for your reply. I'm running Arch Linux on a laptop (Ryzen 7 5800H, 32GB RAM). The audio server is Pipewire. Is there anything else you need?

[fduncanh]

apple music is availble here for testing. please name a specific music track to listen to that you hear this on.

[geekmiki]

I don't think it's related to a particular song, it happens with any song I play. You could try "TM NETWORK - Get wild", I just played it (lossless quality) and it stuttered/distorted when it started.

I tried shairplay and the stutter is not there.

[fduncanh]

@geekmiki

Yes I hear it. (using TM NETWORK - Get Wild) and compared it with shairplay which doesn't have it.

• It only happens with the default choice "uxplay" (or "uxplay -async no"), but not with "uxplay -async"

When I use the timestamp-based synchronization option "uxplay -async" which synchronizes ALAC lossless audio with video on the iOS device (for example to keep the audio in sync with lyrics text showing on the iOS device) its not there.

The drawback of using -async option is that the iOS client delays its own video for a few seconds (I did not find a way to tell the client not to use such a long delay, which may be because it is not receiving/understanding the latency info sent by UxPlay) so there is a delay between making a pause or track-change request on the iOS device, and hearing it happen in the (delayed) audio stream.

with the default " uxplay -async no" option (equivalent to just "uxplay" with no options) , gstreamer just plays what arrives when it arrives, using a clock based on the 44.1 kHz encoding. The artifact may be due to initializing or some buffer issue.

shairplay does not have the delay. I'll look at the shairplay code to see if its doing something that uxplay has missed to communicate latency info to the iOS client.

Originally uxplay was derived from shairplay derivatives which had stripped out the ALAC loss-free music feature and replaced it with screen mirror video with AAC audio. The audio-only mode was restored many authors later: (shairplay -> AirPlay server -> rpiplay ->uxplay) in uxplay v 1.39.

[fduncanh]

• uxplay -async plays the the TM Network track correctly (like shairplay), but using this timestamped mode, one gets that 2sec (exactly) latency imposed by Apple. The plist set by the iOS client specifies max latency 88200 = 2secs in 44.1 kHz units, and min latency 11025 = 0.25 secs. Uxplay sends a request for 0.25 latency (default) which can be modified with the -al option, but the client pays no attention to this request.

https://stackoverflow.com/questions/9997882/detecting-the-airplay-latency

• apparently (rumored, see above) there is some non-public way to tell the client not to use this 2sec latency, but I havent found it.

• shairplay is using an older protocol, and somehow doesnt get the 2sec latency imposed by the client ...

[geekmiki]

All good, -async does solve the issue. Thanks for your support and the great work done on UxPlay.

[fduncanh]

Based on your input, it might be best to make -async the default for ALAC audio mode, and let the user use "-async no" if they want to switch it off.