I've been evaluating HTML5 audio on iOS 4 and have been trying to understand its limitations. From what I can tell...
It is possible to play audio in the background
It is not possible to fire JavaScript events in the background upon track completion
It is possible to fire JavaScript events while the screen is off, but Safari must be in the foreground (before turning the screen off)
My goal for this current project is to create a dynamic playlist that will continue to fire events and move to the next track even while Safari is not in the foreground. Is this possible with the current way HTML5 audio works on iOS?
I am curious about how the chaining of JavaScript events works on iOS if anyone has additional information. It seems that you are allowed to queue back to back sounds, but it must happen shortly after a "human" function happens (for example, tapping an element). Anything else that tries to queue a sound outside of this human function is denied the ability to play.
Also...
Is it even possible to have events that fire to move a real iOS application to the next track? It seems as if the application is only allowed to finish its current audio stream and then it goes into an idle state. Just trying to figure out all the angles here!
This is quite an old question, so I'm not sure if you've found an answer already or not.
One thing I know is that an audio clip cannot be played via JavaScript on mobile Safari.
Autoplay audio files on an iPad with HTML5
The only way to make audio play, is through a click event. This wasn't the case on 3.x, but on 4.x it is. This is because Apple doesn't want the webapp to download audio on a 3g connection programmatically, so they force the user to initiate it.
I would think that if all of the tracks were started downloading (cached), then it may be possible. I would try forcing the user to start one track, and at the same time call .load() on all of the other tracks (in the same click handler). This will force the iOS device to start downloading the audio tracks, and you may be able to play the next track (not sure though).
Related
I would like to have a web page being able to act like a music player.
The user enqueues a list of audio files (hosted on the server) and they start playing. When the first audio is over, the second begins, etc, until the last one.
I was able to easily implement this functionality using an <AUDIO> element, and replacing its src attribute with Javascript by adding an event listener on the ended event.
The problem is that this does not work consistently on mobile, because once the screen is locked, the Javascript does not keep executing. It may work for one song or two, but at some point it stops "skipping" to the next audio track.
From my understanding, this behaviour is caused by the fact that mobile browsers stop the Javascript event loop after some time to save battery when the screen is locked. I am aware of the Screen Lock API, I assume keeping the screen always on would solve my problem, but I don't want to keep the screen always on.
I could delegate playing audio files to a web worker, which should theoretically keep running in the background. Still, I'm not sure it won't be stopped when the screen is locked, and most importantly I am not sure it can even play sounds.
Is there anything similar to the Screen Lock API that allows me to ask permission to keep scripts executing also when the screen is locked?
If not so, how could I overcome this problem?
After some research, I discovered that the act of killing the javascript event loop is highly browser-specific.
Chrome for Android seem to let the playback run indefintely.
Firefox for Android is stricter, and kills the event loop.
The System Wake Lock looks like a promising API for solving the above problem. At the moment, the W3C is still in process of collecting use cases in order to be able to define a new standard:
https://github.com/w3c/system-wake-lock/issues/4
Some mobile sites, like YouTube and Twitch, will pause html <video> elements if other apps (like Spotify, or a podcast player that puts media controls in the notifications) start to play audio.
Interestingly, these don't just take audio focus - they also stop playing if they can't obtain it. As an example, I'm using firefox for android, so I tried disabling its ability to take audio focus with adb:
cmd appops set org.mozilla.firefox TAKE_AUDIO_FOCUS ignore
But now, videos just immediately pause, since it can't pause the other audio source.
How do the sites detect this? I attached a debugger to my phone and looked through the docs but I didn't see anything in either place.
I'm not sure about how this specific flag "TAKE_AUDIO_FOCUS" is interpretted, but modern Android focus management is based on "requesting" (not taking) audio focus. Apps would request it and either get it immediately or listen for updates from the AudioManager as to whether they got it. Similarly they will get updates when someone else requests (and then subsequently receives) focus, and they should react accordingly (i.e. pause/duck themselves). Presumably the apps you mention have asked for audioFocus and were denied it and then hadn't received focus yet, so they just chose to stay paused rather than start playing audio/video and blare out over the app that hadn't released focus yet.
source: https://developer.android.com/guide/topics/media-apps/audio-focus
I have an html5 audio player on my page that streams from my icecast server, all working OK. However, when people block their phone there's no metadata, only the play button that iOS/Android offers.
Is there a way to show something like 'Glaciar's livestream', like when the Spotify app shows the song's title and artist? I'm using PHP and Javascript apart from HTML and CSS.
Thanks in advance!
You can use the Media Session API to customize what's been shown on the lock screen.
But it is not supported by Safari which means you can't use it to customize the lock screen on an iOS device.
I just came along the same issue. Our Webapp would not display anything on the lock screen even though audio was playing. This is what I just found out:
We are setting up an new Audio() element in javascript - within the user interaction we call audio.load(). Then we wait for the canplay event to fire and with that event handler, we call audio.play(). When the phone now gets locked, there is nothing shown on the lock screen.
However, when we add audio.play() directly after audio.load(), so it is called within the same user interaction, everything shows up fine on the lock screen. So it seems like, it matters if audio.play() is called within a user interaction.
Some more background in case someone wonders why we are not calling play within the user interaction: We usually use an audio context (that is unlocked within a user interaction) and just started to fall back to an audio element, due to numerous audio related bugs in safari.
Context
I am trying to loop several HTML5 videos one after the other. This is achieved via Javascript with an event listener listening for 'ended' - the video to end. At which point the url to the video is changed and video.play() is executed for the new URL.
For simplicity, lets say there are 2 videos that are to be (auto) played. After the second video finishes playing, it goes back to the first and plays that one (and the cycle continues). The videos will get cached on the user's device after they are first played.
TL-DR: Now what I want to achieve is to code a HTML5 video to be 'mobile friendly', in respect to mobile data plans.
I want the video to either stream when the page loads or buffer only a few seconds from after the point from where the user is watching. So if the user is 5 seconds into the video, the buffer extends to 15 seconds into the video (so 10 seconds of the video is buffered in case the network connection is weak). If the user pauses the video, the video stops buffering. Though the user won't have access to controls; they will be unable to forward, rewind or pause. I only gave the example of the user changing the point of the video to emphasise that I want control over how much the video has buffered and will buffer.
Alternatively, I want the video to stream to the user’s device. And only download that which needs to be immediately played. This is the less desirable option and is probably less desirable than leaving the video tag as it is since if the user has a dodgy connection, the video will play, stop, play, etc.
The reason for me wanting to achieve this is that I have noticed in Edge, IE, Firefox and Chrome that the video auto plays (good, that's what I want it to do) and plays while simultaneously downloading the whole video to their device (terrible). Of course this behaviour is expected, but practically, it should not do this. If users leave the site straight away, why would we want them to download a whole video they won't see?
Sort of but not entirely relevant, it doesn’t help:
HTML5 Video: Force abort of buffering
Simply put, the thread shows only hacks to hide the src and not any actual control over the buffer. I need to control the loading of the buffer in real time, relative to at what point the user is at, and not based on a 'pause' event. I would also like to know if there is a little-known supported method across most browsers (I only really need to worry about this on mobile) to achieve this, as opposed to a 'hack'.
Nevershowmyface: From what I can gather from the code, it stops the buffering every 0.5 seconds. There is no code for resuming the video? As for why this method will not work, it is not buffering relative to at what point the user is at. For all intents and purposes, it is still buffering the video in a linear fashion, without depending on a variable (the point at which the user is at). It's just doing it more slowly or 'in chunks'. If it loads another chunk just before the video runs out of video, I risk the video stopping and waiting to load again if the connection is poor.
Preload:none is useless here since the video is automatically played (notice bold auto at the top). I should have been more explicit. When the page loads, the video automatically plays. Preload loads the video before the play button is clicked on; preload:"none" does not load the video before play is clicked. But since there is no play button and the video plays once the page has loaded, it is a useless attribute.
My hopeless conclusion in regards to what should be a vital and basic feature
(not a rant)
From what I have found, there is no standardised way to achieve this and there are only ‘hacks’, as described in the post, which only serve to provide limited buffering functionality/ control in some browsers, potentially breaking other browsers and potentially having no effect in other browsers. In light of this, I’m on the verge of giving up on this task so thought I’d ask if anyone else has effectively managed to achieve this; it appears to have no support or has not even be considered in HTML5 or Javascript; I might be and hope I'm wrong – would be great to have this in Javascript.
Do other web developers not consider this when they use videos on their sites? I have spoken to other developers about this and they said the data usage from a site is not or is rarely the concern of the developer.
While I understand there are more important things to worry about, it goes without saying this would be very important for mobile users with low data plans.
Analysis:
The HTML5 audio element does not have a stop() function, nor does it
have an option where you can set the amount of data that it is allowed
to buffer, or a way of saying you want the element to stop buffering -
Don't confuse this with the 'preload' function, this only applies to
the element before the play button is clicked.
I have no clue why this is and why this functionality is not
available. If anyone can explain to me why these crucial functions are
not implemented in a standard that should make web development for
mobile phones better and more standardized I would love to know.
And before someone says the conclusion from that post was that this is currently impossible, note:
1) I am dealing with a video file, not an audio file. Slightly different context, where the file being buffered is significantly larger than an .mp3 file.
2) I am not trying to stop buffering altogether. I am trying to restrict it and keep it relative to the point of the video at which the user is at. So you could actually say I am trying to stop it but at an 'x' number of times after the point where the user's video is.
I'm developing a mobile web app using HTML5 & Javascript. The goal is to have a page with buttons that play sound after touch events, using the HTML5 audio tag. But I'm noticing a significant delay between the touch event and the sound being played, even after the audio file has been cached. I think this may be due to the way iOS Safari handles sound but I'm not sure. Are there any solutions or creative workarounds to this issue? How can I minimize the delay between the touch event and playback?
The audio delay may be because of buffering issues in iOS that are there due to cellular data charges. The user has to explicitly trigger the event in order for the content to start being downloaded.
In Safari on iOS (for all devices, including iPad), where the user may be on a cellular network and be charged per data unit, preload and autoplay are disabled. No data is loaded until the user initiates it. This means the JavaScript play() and load() methods are also inactive until the user initiates playback, unless the play() or load() method is triggered by user action. In other words, a user-initiated Play button works, but an onLoad="play()" event does not.
-https://developer.apple.com/library/safari/documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/Device-SpecificConsiderations/Device-SpecificConsiderations.html#//apple_ref/doc/uid/TP40009523-CH5-SW1
=== EDIT ===
One potential improvement is to use lower bitrate/ higher compressed audio for mobile products. The quality will, however, be significantly reduced. Use only if it is acceptable in your application.