More Annotation on Queueing

NoteAnnotation (No Queue Copying)
 

The current queue of a source could be copied to another source, as repetition and traversal parameters are stored unless the queue entry is unqueued, or the queue is replaced using AL_BUFFER. Copying a queue is a special case of copying Source state in one sense, and a special case of a synching problem in another. Due to these unresolved issues no such command is included in the current specification. To share queues, the application can keep buffer names and the selected attributes that define the queue entries in an array or other lookup table.

NoteAnnotation (Unqueueing shared buffers)
 

For each buffer that is shared among several sources, the application has to save the Source for which the buffer was scheduled last. This only works for groups of Sources that are neither PAUSED nor STOPPED.

NoteAnnotation (No Explicit QueueClear)
 

alSource( sname, AL_BUFFER, NONE ) serves the same purpose. The operation is also redundant with respect to Unqueue for a STOPPED Source.

NoteAnnotation (Queueing vs. AppendData):
 

Buffer queueing does not solve the synchronization and timing issues raised by possible underflow, as these are inherent to application-driven (pushed) streaming. However, it turns an internal AL error condition (offset exceeds valid data) into an audible artifact (Source stops). Its main advantage is that it allows the application coder to operate at a scale of her own choice, selecting the number and size of buffers used for caching the stream, and to schedule buffer refill and queueing according to preferences and constraints. Queueing effectively moves all problems related to replacing or appending Buffer data to the scale of entire arrays istead of single samples and indices.

NoteAnnotation (Multiple Sources on a stream)
 

Queueing allows for the application to determine how much of a backlog of the data stream is preserved. The application can keep buffers, and queue them with other Sources after they have been used already by the original Souce. Unlike the mechanism for appending data to a buffer, the backlog is visible to the application and under its control, and no synchronization of Sources using the stream is required.

NoteAnnotation (Queue Looping and Unqueue):
 

To avoid issues arising from possible manipulation of a pending queue (queue entries not yet used), infinite looping of an entire queue is not supported. Neither is finite repetition of an entire queue. If necessary, this could be added later, as long as it is not possible to unqueue entries from an active Source that will repeatedly traverse the queue.

NoteAnnotation (Loop Points and Compressed Data)
 

For compressed data, uncompression by the application might be impossible or undesireable. In consequence, splitting the sample into several buffers is not possible without explicit support by the API. Buffer-Buffer operations will be added as needed, for the time being applications should not try to use compressed samples if more than full looping is required.

NoteAnnotation (No multi-argument Queue command)
 

There is no

            QueueBuffer( uint sname, uint bname, enum loopdir, uint rep );
          

command because no matter how many arguments we add to the signature, we might be missing one. In other words, even if the current specification does not include scheduling a GAIN or PITCH along with the buffer, it is possible that a later revision will.

NoteAnnotation (No Explicit Queue Objects)
 

Explicit Queue objects have been considered and rejected, as they introduce another producer-consumer dependency with another level of indirection. Further, e.g. QUEUE would also require deprecating BUFFER (breaking backwards compatibility) as an alSource argument, or would introduce a confusing set of precedence and overide rules if both are used in sequence. However, in the absence of explicit queue objects the application will be forced to keep track where buffers have been queued in case it intends to unqueue them for refill or deletion. If several sources use the same buffers (e.g. for synchronous or asynchronous streaming) the buffer will have to be unqueued from each single one.

NoteAnnotation (Queue no Display List)
 

A n interface resembling OpenGL display-lists has been considered and rejected. The problem with this approach is that not only commands would have to be prohibited (similarly, not all GL calls are legal within a display list), but also parameters (enumerations). In particular, only a small set of operations is meant to be legal for a queue at this point, and appending to a queue has to be possible at any time. Within a hypothetical AL display list, only relative timing/conditionals are allowed as arguments. This might necessitate to have multiple forms for deferred commands, or to not allow for absolute timing. Example:

         // lock this queue for overwriting/appending
         alBeginQueue( qname, APPEND | REPLACE );  

         // queue a buffer in sequence, with parameters
         // boolean: never skip? never bail?
         alQueue( AL_BUFFER, bid, loopdir, repetitions );
         ...

         // end lock. 
         // Existing  queue content will be replaced
         //  or appended at this point.
         alEndQueue();