mServe Documentation

Thread Communications

  1. Condition Variables
  2. The decode_ctx Condition Variable
  3. Playback State (Pause, Resume, Stop, Skip)
  4. Seeking
Condition Variables
Top
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 decode_ctx Condition Variable
Top
The possible reasons for the decode_ctx condition variable to be signalled are:
  • 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
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.
Playback State
Top
Pause and Resume
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.

Aborting Playback
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.
Seeking
Top
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.