Repository navigation
Conversation
The third argument was parsed as nonBlocking = JS_ToInt32(ctx, &nonBlocking, ...), which stores the return code (0) instead of the value, so every call blocked. Had the flag been read, speaker boards would have played nothing: the non-blocking branch was empty. playTone() and _tone() now take a PlaybackMode like playAudioFile(), playAudioRTTTLString() and tts(). PLAYBACK_ASYNC hands the tone to the existing playback task, which does not poll the keys, so a key press during the tone is no longer eaten. Like the other players, a new tone stops whatever is still playing. Default stays PLAYBACK_BLOCKING, so existing callers are unchanged. Cardputer keeps its blocking cardputerTone(); on M5Unified boards the async mode skips the delay.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed Changes
audio.tone(freq, ms, nonBlocking)in JS always blocks:JS_ToInt32returns a status code (0 on success), so the flag is always 0. And if it had been read, speaker boards would have played nothing: theHAS_SPEAKERbranch only handles!nonBlocking.On T-Embed CC1101 one blocking
audio.tone()stops the script for ~90 ms whatever the duration (measured on 1.16.1: 6, 10, 15 and 40 ms tones all took 88-91 ms). In a 30 fps game that is three frozen frames per beep. The blocking loop also callscheck(AnyKeyPress), so a wheel step or click during the beep is consumed to cut the tone short and never reaches the script.Changes:
audio_js.cpp: read the flag withJS_ToBool; with the flag set call_tone(freq, ms, PLAYBACK_ASYNC). Without it nothing changes (still goes through thetoneCLI command).playTone()and_tone()get aPlaybackMode mode = PLAYBACK_BLOCKINGparameter, the same asplayAudioFile(),playAudioRTTTLString()andtts(). InPLAYBACK_ASYNCplayTone()hands the WAV generator to the existingstartAsyncPlayback()task. That task does not poll keys.playTone()now stops whatever async playback is still running before it starts, so two I2S outputs never fight over the same pins._tone(): Cardputer keeps its own blockingcardputerTone(); on M5Unified boardsPLAYBACK_ASYNCskips thedelay()afterM5.Speaker.tone(), which is non-blocking by itself.All existing C++ callers use the defaults and behave as before.
Types of Changes
Bugfix (JS API flag that never worked)
Verification
JS script timing
now()around the call, tone 880 Hz / 10 ms:audio.tone(880, 10)audio.tone(880, 10, true)dev)The "after" value was measured with this PR and the two other tone fixes applied (frequency and short tones, opened alongside); none of them touches the async path.
Also checked after the change: the tone is audible in async mode; a wheel step during an async tone reaches
keyboard.getNextPress(); two async tones in a row do not crash.Testing
Tested on LilyGO T-Embed CC1101 Plus (
lilygo-t-embed-cc1101). Not tested on Cardputer or M5Unified boards (the change there is limited to skippingdelay()in async mode).Linked Issues
None found.
User-Facing Change
Further Comments
Observation, not changed here: the ~90 ms per blocking tone come from tearing the I2S output down and setting it up again for every tone, plus waiting for the DMA buffer to play out. Keeping one output open between tones would fix it for good, but that is a bigger change to the audio module.