That link gives a good description of the problem and why Apple is doing 
this, thanks!

I'll play around with your suggestions, I think I'll the hooking to a touch 
event first via the emscripten event functions and then use EM_ASM to 
unlock the WebAudio context. I'd like to avoid to delay main() execution 
until tapped, instead I'll just let the emulator 'freeze', and if I'm 
detecting that it is in this frozen state, ask the user to "Tap to 
Unfreeze" or something.

The emulator is a bit of a special case because of thatl freeze if there's 
no audio playback, I think most other apps/games would be fine if audio 
playback is muted until the first tap.

Cheers,
-Floh.

Am Donnerstag, 8. Dezember 2016 09:11:54 UTC+1 schrieb jj:
>
> I think the example 2 from 
> https://paulbakaus.com/tutorials/html5/web-audio-on-ios/#How_do_I_know_when_my_context_is_unlocked
>  
> should be usable with fair ease, e.g. via a --pre-js, or via using the 
> emscripten/html5.h event handler registration functions. Would that work?
>
> This could be done as a runDependency (add/removeRunDependency() 
> functions) to create that kind of "tap to play" type of launcher, which 
> user would need to tap on to make the Emscripten main() actually run. (or 
> if you have another location after main() but before the render loop, that 
> might be a suitable place as well)
>
> 2016-12-06 15:16 GMT+02:00 Floh <[email protected] <javascript:>>:
>
>> Hi, 
>>
>> on iOS Safari since iOS9, WebAudio will only work if 'unlocked' from an 
>> input event handler connected to a touch input event. Apart from the fact 
>> that I think that this is completely stupid and braindead behaviour of 
>> Safari, I'm looking for advice on how to best deal with this from the 
>> emscripten side (and more specifically, emscripten's SDL Audio wrapper)?
>>
>> This behaviour has the unfortunate effect in my emulator (
>> http://floooh.github.io/virtualkc/), that the emulator simply 'freezes' 
>> on iOS a few thousand cycles into the emulation since the emulator speed is 
>> linked to the audio playback (the emulated CPU will wait for or catch up 
>> whenever a new audio buffer is requested, but those buffer requests never 
>> happen). All my other demos with sound output are completely silent.
>>
>> There is this issue thread on the topic: 
>> https://github.com/emscripten-ports/SDL2/issues/19, but this looks like 
>> a hack and is hard to integrate with my code (I'm simply using the SoLoud 
>> audio lib with the SDL backend).
>>
>> So my questions:
>>
>> - did anybody find a smaller / more elegant workaround which doen't use 
>> the SDL event system and is as non-intrusive as possible?
>>
>> - is this something that should better go into the emscripten SDL wrapper 
>> code? (for instance, all SDL code would silently appear to work on iOS 
>> without sound output until a touch event happens?)
>>
>> Thanks & Cheers,
>> -Floh.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to