2219 | Network Session - 2 clients, iOS26 client skipping timestamps or lagging

AnthonyB

Not the news I wanted to be delivering, nor you seeing, after the network protocol change in 2219. Sorry!

Big caveat - I'm finding that some of the issues I'm seeing are inconsistent (worse than a consistent issue!) the more testing I do. One consistent observation is that it is my iOS26 client behaving 'oddly' while my older iOS16 client hasn't displayed any issues.

ST4 Build: 2219
Device & iOS Version: Host/Client1: iPad 9th Gen, iOS 26.1.0, Client2: iPad 5th Gen, iOS 16.7.12

Issue Description:
Network Session setup. 1 Host and 2 connected Clients.
What I'm observing is:

The iOS26 will sometimes be 1-2 seconds behind the Host right from the start of playback, i.e. it isn't losing sync, it starts out of sync (the iOS16 client is not doing same).
The iOS26 client, when there are multiple timestamps in quick succession, is sometimes skipping a timestamp (the iOS16 client is not doing same)

Sometimes, the iOS26 client appears to receive song start at the same time, but then seems to 'wait' for about 1-2 sec before playing. The elapsed time sits on 0:00 for those 1-2 seconds while 'waiting'. It then plays perfectly in sync, just always about 1-2 sec behind the Host. It doesn't try to catch up, it doesn't skip timestamps, or lag on timestamps, it is just always perfectly 1-2 seconds behind the Host.

I've even tried closing apps and rebooting all 3 devices in my test setup, the behaviour persisted... until it didn't (very annoying). So I've yet to find a way to force the issue to reliably re-occur 🙁

Steps to Reproduce:

Setup a Host
Connect 2+ clients (in my case it was iOS16 and iOS26 iPads)
Start playback on Host

Expected Behavior:
All clients should play in sync with Host

Actual Behavior:
Inconsistently:

The iOS26 will sometimes be 1-2 seconds behind the Host right from the start of playback, i.e. it isn't losing sync, it starts out of sync (the iOS16 client is not doing same).
The iOS26 client, when there are multiple timestamps in quick succession, is sometimes skipping a timestamp (the iOS16 client is not doing same)

This is an example of the timestamps lyrics where I would often (but not always) observe the skipping.
It was the 2nd last line that would always be skipped, and it would catch up on the last line. When this is occurring, it is not just at that particular timestamp, it was the same line in every chorus (twice per chorus, 3 choruses in song, 6 times in total) where there is the same time difference between time stamps.

[00:45.88]{c:green}(Bb){c} Oh what you waiting
[00:46.97]What you {c:green}(Dm){c} waiting
[00:47.82]What you waiting
[00:48.73]What you {c:green}(Gm riff){c} waiting
[00:49.57]What you waiting for?

peter

Can you send me the logs of the 3 devices?

Clients have a network delay compensation and my guess is that this kicks in on your iPad26. The delay is displayed in the network dialog on your client. Could you take check if that is in the same range that the playback is delayed?

AnthonyB

Thanks @peter - just emailed a set of logs over to you.

peter The delay is displayed in the network dialog on your client.

Do you mean the latency value it shows in the Connected Session section?
I'll make a point of checking the network dialog on the client the next time I encounter the issue.

I've been trying to repro the issue and it is sporadic. I did manage to get my iOS 16 iPad to display the 2nd issue (skipping some timestamps when multiple in quick succession) with the same song I provided a sample of above. The logs showed nothing. There was LyricsView:636 [b] Executing scroll event for each timestamp in the lyric sheet, and on the screen, the highlighting would often pause and then it would jump 2-3 timestamps forward to catch up.
I know the timestamping is reasonably quick, but ST3 and ST4 have never had an issue to date.

peter

So after quite a bit of testing, I do not see the delayed playback issue but the latencies I see in my network are most of the time 4ms with occasional peaks to roughly 50ms with 4 devices connected. Anyway, I will disable the latency compensation in the next build as it is pointless anyway with such a low latency in the local network. And then we will see how that goes.

But I see the issue with the skipped lyrics timecodes when I setup rapid timecodes with roughly 0.5 seconds between them. I don't think this is connected to the TCP changes. @Sharonzaz reported similar issues a week ago with the old code.

AnthonyB

Thanks Peter!

peter

This was a really hard issue to find. Hours of debugging and in the end it only needed a change in a single line of code. The lyrics highlighting bug is now fixed in build 2229. It has nothing to do with the TCP change from yesterday. It was present from day 1 of the beta.

Regarding the 1 second late position updates, we will have to find a way to make this occur reproducibly.

AnthonyB

peter Thank you Peter!

..and yes, until I can get some sort of repro for the 'client playing delay' issue, or someone else flags the same issue, let's put this on the backburner.

AnthonyB

I've been re-testing with 2229 for the last hour, just running some playlists and observing the 3 devices.
No repro of the 'delayed client' behaviour and that line skipping with short timestamp intervals also hasn't re-occurred 🙂

One interesting observation, and this may just be the case since the switch from UDP to TCP, or it may be consistent since we first started testing ST4, is the Client Session latency difference between 'old' hardware and 'new(er)' hardware.

My Host device is a 9th Gen iPad, iOS 26.1.0, running no other audio apps/plugins.
My Client devices (for testing) are a 9th Gen iPad, iOS 26.1.0 and 5th Gen iPad, iOS 16.7.12
My songs have timestamped lyrics and audio regions which the Client is displaying.

The 9th Gen iPad regularly operates at 3-6ms session latency with maybe the odd spike up to 30-40ms.
The 5th Gen iPad regularly operates at 90-110ms, occasionally dropping down to 40-50ms or spiking up to 180-190ms.

I've tried a number of things to see if it changes the behaviour of the 5th Gen iPad:

tested with it being only client (i.e. is it 'losing' to a more powerful device in network session slot allocation/priority)
tested with the 5th Gen iPad connecting to Host first, and 9th Gen device second (i.e. is the any connection 'favouritism' based on who connects first)
...but nothing seemed to change it.

is this expected behaviour? Does this highlight the (potential) value of having better performing client devices if using ST in a Network Session setup? I know, I know... is 100ms lyric highlighting 'lag' really noticeable? Probably not for most people in most setups. 🙂

peter

To be honest, I have no idea why some clients seem to have higher latencies on the same network. The value you see is just an averaged measurement of how long packets need to reach the client.

AnthonyB

I have core band rehearsal on Monday and one of the guys had an iPad Pro and the other has a 5th gen iPad so I'll be curious to check the session latency on those devices to see if I see a similar pattern.

peter

Don't put too much emphasis on the displayed latency. Check it primarily if there is a heavy lag on one of the devices. If there is lag it would be interesting to see if it corresponds to the displayed latency.

AnthonyB

Will do. I'll also try and remember to grab logs from any device that displays the issue.

Sharonzaz

Had a duo gig last night and aside from one single dropout on the client iPad it ran flawlessly. Apple router for connectivity. I think I’m on the latest build but not sure. The dropout could have been because we both were using 5g and 2.4G guitar units and in ears (3x 5g and one 2.4)

The client iPad was a fraction “ahead” of mine lyrics scrolling. Ahead or late, as long as it is a fraction of a second it’s all good 👍🏻