20

I am currently working in using the HTML5 audio player to provide a audio stream (24/7 radio stream) via the (mobile) browser. Loading in the stream and playing it works fine.

The major problem is that the HTML5 <audio> tag will keep downloading (buffering) content even when its not active. This could be a major issue for mobile users since most of them pay for data use. So far I have not been able to find a decent solutions that works cross browser to prevent this.

I tried so far:

  1. Unload the source when pause is pressed. < This does not work cross browser
  2. Remove the audio player element and load a new one. This works but lets be honest, this is a very hacky way of performing an extremely simple task.

I was simply wondering if there is something I'm overlooking in this whole issue since I am convinced I'm not the only one with this issue.

Kevin Brown-Silva
  • 40,873
  • 40
  • 203
  • 237
Ruben
  • 1,427
  • 3
  • 17
  • 25
  • 1
    I have edited your title. Please see, "[Should questions include “tags” in their titles?](http://meta.stackexchange.com/questions/19190/)", where the consensus is "no, they should not". – John Saunders Nov 06 '12 at 02:32
  • 3
    I just noticed that removing the element from the DOM doesn't always detach the resource. Meaning that the stream is still being downloaded. – Ruben Nov 06 '12 at 03:55
  • @Ruben totally yes, even if the current DOM is only showing 1 player, the browser is still caching resources. I've test that just now, implementing an Ajax shoutcast player wich did load my stream more than 10 times because the preload & ajax. If you won't use the "preload". the better if you don't include the audio tag unless you click something, in example, a little player button ;) – m3nda Jun 03 '16 at 18:20

3 Answers3

16

The <audio> element includes a preload attribute. This can be set to "none" or "metadata" which should prevent the audio preloading.

Source: https://developer.mozilla.org/en/docs/Web/HTML/Element/audio

Alistair Chisholm
  • 608
  • 6
  • 20
  • 2
    This is the most elegant solution. Setting to "none" downloaded no data and setting to "metadata" downloaded 517kb of data. My test was for a voscast stream. – tim-phillips May 09 '16 at 20:24
  • 1
    It's not only elegant, it's the way to do it. I was triying to set it to "false" like a noob :), setting it to "none" did worked. U can set it to "auto" too. You'll get lof ot problems if you have stream sources and ajax pages. The audio objects are being cached by browser, and you'll grow your bandwith usage with every load. – m3nda Jun 03 '16 at 18:13
2

I found a workable solution for the problem described above. A detail description can be found here: https://stackoverflow.com/a/13302599/1580615

Community
  • 1
  • 1
Ruben
  • 1,427
  • 3
  • 17
  • 25
1

You can do the following to stop buffering load without errors:

var blob = new Blob([], {type: "audio/mp3"});
var url = URL.createObjectURL(blob);
audio.src = _url;

or, shortened up:

audio.src = URL.createObjectURL(new Blob([], {type:"audio/mp3"});

Now you're not loading a "" which is a bad url for the audio tag to try and load. You're instead loading an actual url made from a Blob that just contains no data for the audio to playback.

Gery Teague
  • 27
  • 2
  • 1
    err in firefox: "Media resource blob:http://localhost:4200/c68c796c-5af0-5343-a68d-9043c4c9b9a2 could not be decoded." err chrome: "GET blob:http://localhost:4200/fec774b7-7680-48a9-927e-1926685da447 416 (Requested Range Not Satisfiable)" when using type: "video/mp4" – Petr Marek Apr 16 '17 at 16:44