Before posting, please read: When to use this forum, when to submit a help ticket

Author Topic: Optimizing screen share speed and robustness  (Read 2831 times)

Ahiru

  • Senior Member
  • ****
  • Posts: 97
  • Karma: +4/-0
Optimizing screen share speed and robustness
« on: July 07, 2021, 07:35:55 AM »
Looking for info and advice on screen sharing with iOS (iPads)... in recent rehearsals broadcast screen sharing (app 4.2.14 on iOS 14.6) was so slow or failing to refresh it was almost unusable, whereas in the past it has been working fine (tolerable lags in updates from the main to secondary iPad).
(Our iPads are 6th generation aka 7,5 positioned only about 6 feet from each other)

Coincidentally I saw these release notes for your latest release 4.2.15 has some improvements for screen sharing, and we look forward to trying this update (probably at a gig later this week):
- Improved the transmission of screen sharing images from slow lead devices, and updated following devices to show whatever they receive of an incomplete image to indicate that the connection is still active.
- Updated the screen sharing function to resend the first screen image after an iOS device connects since it often skips the first image.

So, looking for general information to understand improve screen sharing:
- Can you elaborate on the 4.2.15 updates... were they necessary due to some change in iOS?
- In general has something changed over the last month or so in iOS or BH to make this less reliable?
- For broadcast screen sharing, any pointers to understanding the underlying mechanism, e.g. to understand is it better to disable BT if not in use, is it UDP-like or does it retransmit on failure, etc.?
- Any best practices for improving speed/reliability?
- Would it be faster / more robust if we switched from 'Display Screen' method to 'Follow Actions' method?  (Does that also use the same underlying transport as the screen broadcast?  Could it be worse, if some key event like 'start song' is dropped and thus no recovery opportunity until the next song?)

Thanks!

arlo

  • Administrator
  • Senior Member
  • *****
  • Posts: 5071
  • Karma: +116/-3
Re: Optimizing screen share speed and robustness
« Reply #1 on: July 07, 2021, 09:15:20 AM »
I got a small wave of bug reports about unreliable screen sharing in the last month. Because of the pandemic stopping a lot of band activity, it's hard to know what to attribute that to, but I'm guessing it's related to the app rewrites released in March (BandHelper) and May (Set List Maker) and is showing up now because more bands are starting to perform again. The networking approach hasn't changed, but it seems to run more slowly in the newer programming language, or be less tolerant of slow devices.

Of the bug reports I received, all involved using a lead device that was at least 4 and up to 8 years old, and all but one were using the latest iOS version, which means the devices were already somewhat burdened with running an iOS version much newer than the hardware. In my testing, I saw a clear improvement when using a 9 year old device, then a 7 year old device, then a 4 year old device. Some users have confirmed that switching devices around so the newest device was the lead device made a big improvement.

Both forms of Live Sharing (screen sharing and remote control) use the same networking approach on iOS and Android (multicast DNS for discovery, and socket connections for data transfer), but this is somewhat abstracted by the operating system and I don't directly control how devices connect to each other. iOS especially makes a point of abstracting whether wi-fi or Bluetooth is used. In an initial test, I found that turning off wi-fi to force Bluetooth was more reliable for screen sharing, but I didn't try again after my optimizations because those seemed to address the problem. In general I think the best advice is to leave both available and let iOS use whatever it thinks is best for the situation.

Remote control is generally faster and more reliable because it requires sending a tiny fraction of the data that screen sharing requires. Neither function verifies what data has been received or retransmits data that was not received. I could put that on my wish list, but it wouldn't be very useful other than for song selections since all the other data changes pretty quickly.

BTW, this post isn't asking about device discovery, but for future reference, the most common issue with that is a router configured to block intranet traffic. Also, iOS 14 introduced a privacy setting for Local Networking that the app offers to turn on when it first runs. If you decline this or turn it off later, device discovery won't work, and the app can't detect whether it has been turned off so it won't show an error message.

Ahiru

  • Senior Member
  • ****
  • Posts: 97
  • Karma: +4/-0
Re: Optimizing screen share speed and robustness
« Reply #2 on: July 07, 2021, 11:07:01 AM »
Thanks Arlo, this is a big help!  Indeed we've only rehearsed with sharing screens a couple of times in the last month, and our first gig since last year is this Friday ;-)  So this helps us understand it is not something else in our overall wireless environment.

Remote control is generally faster and more reliable because it requires sending a tiny fraction of the data that screen sharing requires. Neither function verifies what data has been received or retransmits data that was not received. I could put that on my wish list, but it wouldn't be very useful other than for song selections since all the other data changes pretty quickly.
I can imagine this could be tricky to add, but for our use case (everything automated) seems like just having guaranteed delivery for first and second song select should be enough to allow the following device to play a song independently and roughly in sync with the lead device.

BTW, this post isn't asking about device discovery, but for future reference, the most common issue with that is a router configured to block intranet traffic. Also, iOS 14 introduced a privacy setting for Local Networking that the app offers to turn on when it first runs. If you decline this or turn it off later, device discovery won't work, and the app can't detect whether it has been turned off so it won't show an error message.
Thanks... we haven't had any discovery issues; just lost broadcast screens.

arlo

  • Administrator
  • Senior Member
  • *****
  • Posts: 5071
  • Karma: +116/-3
Re: Optimizing screen share speed and robustness
« Reply #3 on: July 07, 2021, 02:53:41 PM »
I can put that on my wish list, but if you end up using that workflow, please let me know if it is ever actually a problem (i.e., if the song selection message ever gets lost).

Bill Malchow

  • Regular Member
  • ***
  • Posts: 6
  • Karma: +0/-0
Re: Optimizing screen share speed and robustness
« Reply #4 on: August 28, 2022, 10:30:43 AM »
user full info here.  thanks arlo for being so descriptive.

 

anything