Do not autoplay audio dweets

We can detect an audio dweet if:

• It has been tagged #audio
• It contains code Audio or SpeechSynthesis or …
• (It looks like it has a compressor, and the uncompressed code contains the above) But just the hashtag would get us 99% of the way

Behaviour: An audio dweet should just start off paused. There will be a ‘Play’ button the user can click if they want to start the dweet running.

Optional extra:

• A ‘Pause’ or ‘Stop’ button that can stop all started audio. One way to achieve this might be to override the Audio and SpeechSynthesis` constructors with our own functions that call the original functions, but also keep a copy of the constructed object in a global array, so that we can stop them when the button is pressed. This might also be an advantage when someone is editing an audio dweet. When they change the dweet, our reset function can stop all the existing audio output, to provide a clean slate for the new version.

[lionleaf]

Using #audio would definitely get us pretty close, as if the author forgets to add it somebody else could. However, I worry we could then get people tagging random dweets as “#audio” as to disable autoplay.

Regex matching on the dweet would also get us pretty far, it will catch most normal audio dweets, but if somebody wants to they could always evade it.

We could override the Audio and SpeechSynthesis constructors with something that automatically mutes the sounds and presents an ‘unmute’ button somehow?

[KilledByAPixel]

Domp handles starting and stopping audio when clicked on as well as some other handy stuff.

Would it be possible to have Dwitter create an default audio context the same way it creates a canvas context? It’s basically the same thing as the canvas but for audio. This could give dwitter more control while also allowing more space for audio code.