Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

failure to set audio property in Google Chrome

Has anyone seen such an error and know how to fix it? The game works on firefox and other browsers but this error shuts the game down.
I have a <<stopallaudio>> command followed by <<audio "mainloop" loop fadein>> command. I had to use stopallaudio because it kept echoing into eternity if you hit the back button then went forward repeatedly.

Comments

  • edited May 2017
    I haven't seen this error and can't reproduce it.

    Is there an error message? What do you mean by echoing into eternity?
    ...if you hit the back button then went forward repeatedly...

    I'm also not sure what you mean here. Do you mean on the UI-bar? Hitting the back button once and then forward repeatedly doesn't seem possible.
  • I would guess they mean the repeatably selected the combination of Back then Froward, which may of caused a new instance of the "mainloop" related audio to start each time.
    If that's actually possible (not sure because I have never tried doing that) then that could result in an echoing effect caused by the overlaying of multiple instances of the same audio track.
  • greyelf wrote: »
    I would guess they mean the repeatably selected the combination of Back then Froward, which may of caused a new instance of the "mainloop" related audio to start each time.
    If that's actually possible (not sure because I have never tried doing that) then that could result in an echoing effect caused by the overlaying of multiple instances of the same audio track.

    Oh, yeah, that makes sense. Odd that the problem doesn't occur in firefox; I had the same issue in both when testing that. I don't know why/how that could cause Chrome to crash either.

    Anyway, if you are using the back and forward controls, you should probably wrap the audio code in
    <<if !visited()>>...<</if>>
    

    to prevent repeating anyhow. That might help fix the other issue too. If that isn't helpful, we'll need to see more of your code. It'd also be helpful to know which version of SugarCube you're running.
  • You should always state the story format you're using and its full version, because advice will tend to vary based on that information. Specific to this case, SugarCube v1 and v2's audio subsystems are fairly different—v2 having more features and, likely, some fixes and browser workarounds that v1 does not.

    Beyond that. Which version of Chrome? Are you using <<cacheaudio>> outside of StoryInit? Are you using playlists as well?

    greyelf wrote: »
    I would guess they mean the repeatably selected the combination of Back then Froward, which may of caused a new instance of the "mainloop" related audio to start each time.
    If that's actually possible (not sure because I have never tried doing that) then that could result in an echoing effect caused by the overlaying of multiple instances of the same audio track.
    For this reply, I'm going to assume that SugarCube v2 is being used—because stop using v1.

    That should be impossible with <<audio>>. Each track registered by <<cacheaudio>> has a unique ID. If a new track is registered with an existing ID, the old track is destroyed—implied in that is ending any playback—and the new track takes its place. Furthermore, each track has exactly one audio element created for it which can either be in the playback state or not, it cannot be in the playback state multiple times—unless the browser is doing something stupid.

    Since the author mentioned using the fadein action. The fade effects, which all use the same method internally, use a single timer per track. Meaning that only one fade can be running per track and to start a new one requires cancelling the existing one. The player can reset a running fade by bouncing backward and forward in the history before it finishes, but that would only affect the fade, not the playback state.

    We're going to need more information.
Sign In or Register to comment.