JoJoBond / 3LAS

Low Latency Live Audio Streaming
GNU General Public License v2.0
90 stars 23 forks source link

Android WebRTC terminates audio after screen-off in less than 5 mins #24

Closed RuhanSA079 closed 1 year ago

RuhanSA079 commented 1 year ago

Hello,

It seems that I have found another issue, this time on Android. Seems like that after my Android phone's screen goes off, the WebRTC stream seems to stop after a few minutes. Tested on Android 12, and Android 11 (Nothing Phone 1 and OnePlus 6T). Also, there's no MediaControls anywhere on the lockscreen/notification-bar, like on iOS. I suspect that a MediaSession is missing or something? I think this is something that needs to be added to the webpage, in order to keep the audio stream alive?

Been listening to webradio on my OnePlus phone for an hour now, still works. How could we fix this?

Just to add some more details, seems like that battery plays a factor here, when on the charger, it seems to not suspend.

JoJoBond commented 1 year ago

Not much I can do about how the phone/browser app handles WebRTC after screen off. This is one case where Apple does it right... Have you tried with latest Chrome browser app or Firefox? The 'default' browser app is often quite old and may have bugs that have been fixed long ago. I was able to find these topics that discuss essentially the same problem: https://bugs.chromium.org/p/chromium/issues/detail?id=513633 https://bugs.chromium.org/p/chromium/issues/detail?id=951418 The later suggesting to have a looping audio element running in the background to keep the tab alive. Though I would prefer not to implement such workarounds when possible.

RuhanSA079 commented 1 year ago

Ah, bugger. I am running the latest Chrome browser release. It seems to happen on Firefox as well. Maybe thought that something can be done about this as a quick-fix, but does seem to be a widespread issue for Android users, with no apparent solution yet.

In my case, I'll host two servers then, one snapcast webserver (using some real-time audio protocol written by badaix, seems to be running well on Chrome for Android, even with screen-off.) and then your 3LAS system for iOS for the WebRTC implementation.

Really sad that it has to be this way, but kinda desperate to get a "universal" system going ASAP. Will be putting up all the resources and code on my Git, should anyone follow my example.

Closing issue, as nothing can be done about the suspend on Android. (I doubt that changing the audio tag to a video tag will not improve the situation)

JoJoBond commented 1 year ago

I will try to check tomorrow if I find a workaround. I don't know if I can reproduce the issue on my phone, but I will try.

JoJoBond commented 1 year ago

You can try to force the fallback mode on android with some code changes. There should be an isAndroid global variable you can use. Just skip the init of this.WebRTC in 3las.js/ts and it should try to use fallback mp3/wav.

RuhanSA079 commented 1 year ago

You can try to force the fallback mode on android with some code changes. There should be an isAndroid global variable you can use. Just skip the init of this.WebRTC in 3las.js/ts and it should try to use fallback mp3/wav.

Thanks, I will try it tomorrow when I can get to it again.

RuhanSA079 commented 1 year ago

From the event log on my Android phone, I can see that the fallback is initialized, audio/mpeg. Is this correct? Tested it, but still the same cutting off of audio after a minute or two with the screen off.

JoJoBond commented 1 year ago

Yes that is correct. Too bad that's not working either. My next best approach would be to prevent the phone from going into sleep mode. There is e.g. the wake lock api, and other means to do that: https://stackoverflow.com/questions/6106747/can-i-prevent-phone-from-sleep-on-a-webpage

RuhanSA079 commented 1 year ago

Would it be better to use NoSleepJS, not to re-invent the wheel? https://github.com/richtr/NoSleep.js

JoJoBond commented 1 year ago

For some simple testing you could use NoSleep.js. But for 3LAS I like to have TypeScript implementations. So I would rather rewrite in TypeScript and discard all the things I don't need as well.

JoJoBond commented 1 year ago

I tested it again today and can confirm the issue with the screen going to sleep on Android. I tried several methods to mitigate the problem. The only working solution was to play a small video on loop to prevent the screen from going into sleep. This way I was able to stream for 10 minutes and more. I will work on some code on the coming days, probably on Friday (no promises though).

JoJoBond commented 1 year ago

Can you please test commit 886c2390a90738515618f9125e9e5acfbd869408 ?

RuhanSA079 commented 1 year ago

Can you please test commit 886c239 ?

Hello, seems that commit fixes the "Screen-off" with a video-wakelock. Been listening to a music stream for over ten mins now, seems stable. I also saw that you implemented a "dim-screen" feature? Seems that the lightbulb tap does not always register, or is it double-tap to disable the "dimming"? EDIT: Apologies, had installed the setup at the local church last week, seems to work stably with a Pi3 with OverlayFS enabled, to minimise SD-card corruption, had not the time since then to look at your commit message.

JoJoBond commented 1 year ago

Seems that the lightbulb tap does not always register, or is it double-tap to disable the "dimming"?

It should be single tap for enable and double tap for disable. I know it can be finicky, but it's workaround anyway :).