[vorbis-dev] Thread issues: clarification

[Jeff Squyres]

On Fri, 26 Jan 2001, Monty wrote:

> > However, I think I must have misunderstood, because in reading the code
> > from vorbis_analysis_blockout() and the functions that it calls, it
> > appears that there are writers of the vorbis_dsp_state (or, more to the
> > point, writers to some of the subsidiary data structures).
>
> None of the libvorbis/libvorbisfile functions are safely reentrant for
> a given single instance of a data structure.  Even the functions that
> just look like they read data are modifying state.

Gotcha.  So I'm assuming that this means, by implication, that
vorbis_dsp_state instances cannot share a common vorbis_info.

(just gotta get that memory model clear...)

> [snipped]
> It's designed that way.  With my obligations to beta 4 mostly handled,
> I'll be spending time this week on docs.  Actually, you're just about
> qualified at this point to do it too :-)

Hah!  Unlikely.  :-)

> > Did you intend that vorbis_dsp_state instances can be shared between
> > threads?  Or are vorbis_dsp_state instances now just stateless, in that
> > one can encode vorbis_blocks on different vorbis_dsp_state instances and
> > still get continuous audio output? (I don't know how to put that any
> > differently; did that make sense?)
>
> vorbis_blocks are standalone but not stateless (you may have several
> pointing to one vorbis_dsp_state and each one in parallel with the
> others so long as the vorbis_dsp_state is still valid; the reference
> to the vorbis_dsp_state is actually readonly).  vorbis_dsp_state
> structs are definately not stateless.  Every call that takes a
> vorbis_dsp_state, even ones that look trivial, may change the state.

My choice of the word "stateless" was a poor one.  What I meant was that
multiple, [potentially non-sequential] vorbis_blocks can use the same
vorbis_dsp_state (in serial) without problems.  My model is to do
something like the following (I've briefly discussed this before, so this
is just so that we're on the same sheet of paper):

- thread 1 dequeues 50 sets of input samples
  - thread 1 creates a vorbis_info and vorbis_dsp_state for these 50
    samples
  - thread 1 loops over these 50 sets of input samples
    - thread 1 calls vorbis_analysis_wrote() on each input sample set
    - thread 1 loops over calls vorbis_analysis_blockout(), potentially
      generating a vorbis_block
      - if a vorbis_block was generated, thread 1 calls vorbis_analysis(),
        generating an ogg_packet
      - thread 1 loops back up to _blockout() as necessary
    - thread 1 loops back up to finish all 50 input samples
  - thread 1 enqueues all the resulting ogg_packets to the output thread
    (destruction of the vorbis_info and vorbis_dsp_state is delayed until
     the ogg_packets are actually output, much later)
  - thread 1 loops back up to get 50 more input samples

Other threads are doing exactly the same thing in parallel with thread 1.
However, they'll have their own vorbis_dsp_state (and assumedly their own
vorbis_info).  So all accesses to vorbis_dsp_state will be in serial,
never conurrent, and therefore safe.

My question is about the overall plan -- to create vorbis_dsp_state
instances on the fly.  So if I look at 100 input audio samples:

        0 ... 49 50 ... 99

they'll likely be processed by two different threads.  0-49 will have its
own vorbis_dsp_state and 50-99 will have its own vorbis_dsp_state.  Now
As I understand it, you have told me that this is ok -- the .ogg audio
output won't create a "click" or other discontinuity in the output between
the ogg_packets that were generated for 0-49 and 50-99.  Indeed, that's
one of the Big Things that was just put on the main CVS branch -- the
short-vs-long block issue is now decided independantly, not as a result
prior blocks.

Did I get that right?  Did I get the terminology more-or-less correct?  Is
that a valid scheme?

If so, I think that I know what I need to do, but I'm a little confused by
your statements:

- "the reference to the vorbis_dsp_state is actually readonly"
- "Every call that takes a vorbis_dsp_state ... may change the state"

These two statements seem to contradict each other...?

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.