One solution for Chrome stopping Audio in playing Symbols when changing Scene - Instant (OR NOT)

Just a small tip.

I have an audio stream playing in a symbol which I need to keep playing when the user transitions from one scene to another. The transition needs to be instant.

The problem I found was that in Chrome and Edge the sound stopped playing when using instant.
This as far as I know comes under a known issue when using instant transitions.

rather than add or a on scene load/symbol load action to start the playing ( if originally playing )

I opted to put the transitions in as cross fades. But put the duration as 0s.
This gives you the instant effect and the sound continues.

It is not perfect, there is a small break in the sound but this is better than nothing.

Safari and Firefox do not have this issue.

Update: pleas see below…


How are you playing the audio? And to clarify, this is for a Persistent Symbol?

I’d imagine this wouldn’t be a problem with Hype’s built-in audio (and in fact it isn’t tied to a symbol), but if you’re using an <audio> element I can see that a persistent symbol has to move that from one scene to the new one and that could cause an issue. I’m frankly surprised that instant vs. the non instant transitions have a bearing on it though!

Nice find!


It is actually a radio station stream. It has it’s own script that builds a div out into a HTML5 audio and yes a Persistent Symbol.

It is funny that Safari and Firefox do not have the issue. I assumed its down to web engine.

You where right,

I have moved this from Tips & tricks…

It worked for me for all of one day… but I changed some things and now seems to no matter what I do it does not work. It may be I have more things going on during sceneload.

So have had to revert to using a slide on to scene to simulate changing scene. Not really what I wanted but I need to have the music continue in Chrome + Edge as it does in Safari & firefox.

It is funny that Safari & Firefox have no issue with the Audio continuing even if the Symbol is being moved in the DOM.

There must be a way to do it in the other Browsers is what I keep telling myself…???

It makes some sense that if an <audio> element is detached from the document it would stop playing. Is putting the widget in an element outside of the Hype DOM structure with a high z-index and then On Scene Load visually placing it above a “shadow” Hype element an option?

Hmm not sure. I will check if that could work It may be hard as the whole site is built with Hype…
Loads of JS inside etc. But I actually had to insert the streams js after load using a hype function to get it at the end of the body (document.body.appendChild(playerScript);) to work so having it outside may work for the better.

Do you know why it works if Safari and FF, I would expect it to be the same for all of them.

On aside ; The site is a radio station for my Bro. He wanted something that looked like


So I gave him something that suited what he wanted but a little different. Not 100% happy with it and I will slowly change it up to be more polished but to just get him up and running it will do. literally just gone live…

The Ticker Tape is from my example I posted up on forum and it actually uses a google sheet which he can edit to get new messages in the ticker within 30s-ish and he does not need to mess about with text files and format.

The is even a drop down in the sheet so he can control an ‘LIVE’ icon pop up

You will see that the player moves about depending on scroll. And it was the player I wanted to move to another scene ‘About’. But alas that has become a roll on to scene effect.

I can see some browsers being smart about this; I'd be curious if older Chrome (before it forked from WebKit) had this issue and the problem is a regression or if it is newer behavior from Safari. Probably worth filing a bug against Chrome.

Probably it did not have the problem.. I will file a bug report as I think this is something that should really work.

If anyone else is interested in getting a citrus3 radio broadcast stream working in Hype let me know and I will try to put up the steps I took. Their site is not very helpful and their own streams for demo stall ?. but they are the one people seem to choose to broadcast with. One tip straight a way is you do not need to use there skins. The Audio can be set to stream in html5 even though that is not obviouse in the streamers control panel or there docs. This means you can use the normal controls for audio and your own interface.

Hey @jonathan,

So I put this in the Head file.

<script type="text/javascript"> function myCallback(hypeDocument, element, event){ 
  console.log( 'sceneload =  window.jpIsPlaying'  + window.jpIsPlaying );
  if (window.jpIsPlaying){
	}, 1);

if("HYPE_eventListeners" in window === false) {
window.HYPE_eventListeners = Array();

window.HYPE_eventListeners.push({"type":"HypeSceneLoad", "callback":myCallback});

window.jpIsPlaying is a Bool that is set when the play button is toggled to start playing or pause.

So on each scene load this code is run to start the player playing again. I was hoping to avoid this but I was running into the issue even in Layouts since they are scenes.

Notice the interesting thing. I have only given the timeout 1ms. That just nuts but seems to be working on layouts and instant transitions to scenes.

The other interesting thing is it seems something in Chrome is calling a pause on the audio player.

I got this on some of the longer timeouts I tried ( sorry did not note the times)

Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause().
_html_clearMedia @ jquery.jplayer.js:98
clearMedia @ jquery.jplayer.js:67
(anonymous) @ jquery.jplayer.js:1
each @ jquery.min.js:2
each @ jquery.min.js:2
b.fn.jPlayer @ jquery.jplayer.js:1
pause @ player.js:17
dispatch @ jquery.min.js:2
u @ jquery.min.js:2
trigger @ jquery.min.js:2
(anonymous) @ jquery.min.js:2
each @ jquery.min.js:2
each @ jquery.min.js:2
trigger @ jquery.min.js:2
_trigger @ jquery.jplayer.js:53
(anonymous) @ jquery.jplayer.js:43
pause (async)
gh @ HYPE-608.thin.min.js:55
d @ HYPE-608.thin.min.js:78
ke @ HYPE-608.thin.min.js:83
Yb @ HYPE-608.thin.min.js:88
(anonymous) @ HYPE-608.thin.min.js:100

I was not calling any pause() in my code.

I think this is being triggered by the Hype runtime looking at the backtrace. Hype does in fact pause any HTML <video> elements in the previous scene when making a scene change. I guess they are using video instead of audio. I need to look further to verify if this happens for video in persistent symbols that will be on the next scene (or maybe even if not?); if so I'd count that as a bug.

I'm surprised though that it says The play() request was interrupted by a call to pause() . Hype's pausing of videos happens well before the HypeSceneLoad event is called. So the play should always follow the pause.

This is part of the player their js constructs in the div/rect I provide in Hype.

<audio id="jp_audio_0" preload="none" src="" title="our music radio"></audio>

Unless you mean they are pushing video down into a audio player which would be odd for a radio stream but possible.

just put the stream url into vlc on the premise that if it was an mp4 or other video it would play as such.
I just get audio.

VLC info on the stream.

Huh, that’s odd. I think our only pause is for video tags. Do you mind running this terminal command:

defaults write com.tumult.Hype2 UseFullHypeJSTemplate -bool YES 

And then relaunch and re-export/preview and get the backtrace again?

It may be this is a red-herring too.

I cannot reproduce it… bloody odd. You maybe right and it is a red herring. I did have pause, play at one point. But removed the pause later on. roughly when I first got the error.

But I was still getting it after.
I am wondering if Chrome had some sort of cache going on with the player. I really am at a loss.

I notice this in the trace I posted above which explains what the error is at least.

And on my Mac even if I set the timeout to 0 it does not pause. Need to see what PC’s do