Solution 1 :

Possible solutions…

(1) Use .load(); to reset the <Audio> element. This might stop the cache / over-play issues.


(2) I cannot reproduce your issue with this code setup (it might inspire your own solution) :

<!DOCTYPE html>

<audio id="streamPlayer" controls>
<source src="" type="audio/mpeg"> </audio>

<br> <br>
<button type="button" id="btn_01" onClick="do_BtnClick( 1 )"> Stream #1 </button>
<button type="button" id="btn_02" onClick="do_BtnClick( 2 )"> Stream #2 </button>
<button type="button" id="btn_03" onClick="do_BtnClick( 3 )"> Stream #3 </button>



var myAudio = document.getElementById("streamPlayer");

var stream1 = ""; //Stream Guys 1
var stream3 = ""; //Imagine Radio
var stream2 = ""; //70s/80s

function do_BtnClick ( radioNum )
    if( radioNum == 1) { myAudio.src = stream1; }
    if( radioNum == 2) { myAudio.src = stream2; }
    if( radioNum == 3) { myAudio.src = stream3; }


Problem :

I am creating a single page application that plays live audio streams using the HTML audio element. Many times I run into the issue where the browser seems to be caching audio from a stream that was previously played.

Would anyone have suggestions on how to clear the cached audio? I’d like to make it so an audio stream can get a fresh start every time the user plays it.

For example, I play audio stream #1, and then switch to audio stream #2 for a bit. When I switch back to stream #1, it tries to play the stream where I last left off and sometimes it’s mixed in with what is currently being played on stream #1.

Every time I play a new audio stream, I am just running this basic Javascript code:

if (!this.htmlAudioElement.paused) {

this.htmlAudioElement.setAttribute('src', '<streamUrl>');;

Edit 1/20/21
As was asked for, below is an example stream where I get the problem:

Request Header

GET /live.mp3 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0
Accept: video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Range: bytes=0-
Connection: keep-alive
Referer: <My IP>

Response Header

HTTP/1.1 200 OK
Content-Type: audio/mpeg
Date: Wed, 20 Jan 2021 20:14:50 GMT
icy-br: 96
ice-audio-info: bitrate=96
icy-br: 96
icy-description: NPR Program Stream
icy-genre: News and Talk
icy-name: NPR Program Stream
icy-pub: 0
Server: Icecast 2.4.0-kh10
Cache-Control: no-cache, no-store
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
Connection: Close
Expires: Mon, 26 Jul 1997 05:00:00 GMT


Comment posted by Brad

What are the stream URLs you’re using? The caching should be disabled by the server, and I’ve never seen a live audio server where this wasn’t done.

Comment posted by m1k3f

It’s from various remote URL’s (e.g. NPR live stream, etc), though I don’t think all remote streams have this problem. So you’re saying this is an issue that’s not on the client side? Is there some way on the client side to clear out cache from a specific file/URL?

Comment posted by Brad

You’ll need to provide an example so we can see specifically what you’re talking about. Show the request/response headers. It could be any number of things. As your question is now, we can’t reproduce the problem.

Comment posted by m1k3f

I’ve added an example in the original question above.

Comment posted by Brad

Caching is disabled in the response headers. I’ve never had the problem you’re speaking of, when the response headers are what you’re showing. Can you show a full example code that reproduces this problem?

Comment posted by m1k3f

I added .load() before .play() like you suggested and did a bit of testing. It seems to be working now without any of the caching issues I experienced. Thank you!