summaryrefslogtreecommitdiff
path: root/src/modules/submit/submit.c
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2023-11-14 19:31:36 -0800
committerVito Caputo <vcaputo@pengaru.com>2023-11-14 19:31:36 -0800
commita44c71ba3dcd57765b112c039b48513646c9e244 (patch)
tree03febc52aeed244f4f9a2085e91f8c7c6d662155 /src/modules/submit/submit.c
parentb7f773ae87ab037b94582005729fc15a22340f97 (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 'src/modules/submit/submit.c')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved