diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2023-11-14 19:31:36 -0800 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2023-11-14 19:31:36 -0800 |
commit | a44c71ba3dcd57765b112c039b48513646c9e244 (patch) | |
tree | 03febc52aeed244f4f9a2085e91f8c7c6d662155 /m4 | |
parent | b7f773ae87ab037b94582005729fc15a22340f97 (diff) |
til_stream,rkt,main: add stream audio control
Until now everything interested in audio just used a plain getter
on the stream to get at the context.
But with how things work currently, audio is always left in a
paused state until explicitly unpaused. This works fine with
modules/rkt, which manages pause/unpause explicitly. When
there's nothing like modules/rkt in charge though, the audio just
sits stuck paused. Meaning if you do some simple thing like
--module=playit, it won't ever get unpaused.
With this commit, something like modules/rkt takes control of the
stream's audio context, in a way that prevents anything else from
taking control of the same context on the same stream. That
enables having main try take control of the audio context after
creating the module contexts, then in the rendering thread ensure
the audio is unpaused if main is in control of the audio context
and something's queueing audio frames.
For now there's no mechanism for releasing control of the audio
context. It doesn't seem appropriate to make this more elaborate
than necessary. There's basically just two use cases WRT audio:
1. Something like rkt, which takes control once for the process
and stays in control until process exit.
2. Something far simpler where nothing's taking control like
rkt, and main just needs to get things unpaused when
needed because something's generating audio frames.
Diffstat (limited to 'm4')
0 files changed, 0 insertions, 0 deletions