Timed play for music streams

[kcgen]

First up - I'm enjoying the per-stream-specific music improvements. It's much easier (and clearer) to manage state now that it's performed explicitly per stream. Thank you!

This feature is similar to loops, but uses a time duration instead.

Background on this feature request: in this Dosbox migration to Mixer X, games play audio at a given sector (seek offset) for a given number of sectors (duration). That duration might only be seconds while others it can be tens of minutes.

So this feature would allow specifying a playback duration after which the stream would automatically pause itself.

• Playback duration would take precedence when looping exceeds the duration. For example, a 22-second stream is set to loop infinite (-1) times and the playback duration is set to 5 minutes. After 5 minutes, the looping track is paused.

• If someone externally pauses or halts the stream before the duration is reached, then the playback duration timer is cancelled and no further action taken: the stream simply remains in its paused or halted state.

• If the specified playback duration accidentally exceeds the actual playback length (music total length * loops), then the existing behavior remains and the track naturally stops playing after the number of specified loops is met.

Let me know what you think!

regards, Kevin

[Wohlstand]

So, you probably need the Timed play music call, right? The Chunks API had timed functions, but music lacks that, so, yeah, I'll try add that at evening.

[kcgen]

Ahh, I didn't even see that Timed channel functions! Yes, the equivalent functionality for music would be perfect.

[kcgen]

Thinking about timed play, maybe each stream (and music stream) can have a their own data consumption count-down value instead of relying on SDL timers/ticks.

Their data consumption values would be calculated once when their play function is called with the desire play duration.

The data count depends on us knowing the particular stream's sample rate, bytes per sample, and number of channels (if we support mono/5.1, etc..). So when the user opens the file/RW the first time, we'd want to query the decoder and save those properties.

Every time the callback fires, all the streams' data consumed values would be decremented by their given decoded amount of data (prior to mixing/interpolating up to a common sample rate, bit depth, and number of channel); which would allow each stream to have a unique count-down.

Once a stream's data countdown hits 0 (or less), that stream is no longer played.