Enhancement: Add ability to SOUND command to wait for sound playback to complete when duration is not -1
Closed this issue · 3 comments
I believe that sound playback with the SOUND command currently operates asynchronously, which is desirable for video game sound effects and music. However, for some applications, it would be useful for sound playback to be synchronous, such that the system waits for the sound playback to complete (unless the duration value is set to -1).
I'm not sure if this feature can be implemented, nor am I sure how to extend the syntax of the current SOUND command to support such a feature.
Despite what the docs suggest we don't actually yet have sound duration of -1 as a recognised parameter, but as a flip side to your own suggestion I'd very much like to see it introduced. The lack of indefinite/infinite duration sound is the main blocker to being able to do anything complex with audio.
There's a PR I made a few weeks ago that takes it to the extreme and adds basically everything that fabgl can handle, but at a minimum we need indefinite duration audio and ideally VDP commands that simply tweak volume or frequency (though at a push you could of course just issue another full indefinite duration sound command).
The reality of how the BBC BASIC SOUND command was that it was not exactly synchronous in the way that you're describing @tonedef71
On a BBC Micro, calling SOUND 1,-10,42,20 does not wait for playback to complete; it returns immediately so you can continue to do other things, such as play notes on other channels. Subsequent calls to channel 1 would still return immediately, but get queued for playback.
The VDP sound code doesn't support queueing. I'd argue that's a higher level feature, one that the BASIC interpreter could choose to support.
What the VDP sound code does support is having a channel be "busy playing a note", during which time attempts to play another note will be rejected.
The current SOUND implementation in the Agon Light's BBC BASIC respects this. Attempting to play a note on a channel that is currently busy playing a note will block the interpreter until the first sound has completed, at which time this second note will play. The sound command is not queued, so the behaviour on an Agon differs to how it works on a Beeb.
The current sound implementation in agon-vdp does not allow for indefinite note duration (-1) or for note playback to be interrupted, so it would not be possible to adjust the BASIC interpreter to support queueing and work in the way that the SOUND command does on a Beeb.
My PR #76 adds functionality to the sound system in the VDP that could allow the BASIC SOUND command to be rewritten to support operation like the Beeb.
I'm going to close this card as 'Won't Do' as the sound modules have been completely rewritten since.