Most mServe thread communications involve condition variables. Often, there
can be several reasons why the condition is signaled, and all possible reasons
should be checked after each signal.
The possible reasons for the decode_ctx condition variable to be signalled
- Condition Variables
- The decode_ctx Condition Variable
- Playback State (Pause, Resume, Stop, Skip)
You can distinguish between playback state signals and output buffer signals, by
storing the value of the state field of the decode_ctx prior to waiting
for signals, and then comparing it with the post-signal value.
Pause and Resume
- Playback has been paused
- Playback has been resumed
- Playback has been stopped
- Playback has completed
- Playback has been aborted due to an error
- Output buffer data has been popped
- Output buffer data has been pushed
Pausing is done by setting the decode_ctx state to DS_Paused and raising
the signal. The output thread will stop popping buffer data, causing the decoder
thread to halt waiting for buffer space.
Resuming is done by resetting the decode_ctx state to DS_Running and raising
the signal. The output thread starts popping data and the decoder resumes.
Seeking is performed by retrieving the decoder plugin info from the decode_ctx
and calling its seek function. The function is thread-safe and non-blocking, so
some time after calling seek(), the decoder thread will perform the seek and
update the status structures.
To stop playback of the current song, the decode_ctx state is set to DS_Complete
and the signal raised. The decoder and the output thread should return as soon
as they are awaken.