2 <chapter id="oal-operation">
3 <title>&OAL; Operation</title>
6 <title>&OAL; Fundamentals</title>
8 &OAL; (henceforth, the "&AL;") is concerned only with rendering audio
10 and primarily meant for spatialized audio.
11 There is no support for reading audio input from buffers at this
12 time, and no support for MIDI and other components usually
13 associated with audio hardware. Programmers must relay on other
14 mechanisms to obtain audio (e.g. voice) input or generate music.
17 The &AL; has three fundamental primitives or objects -- Buffers, Sources,
18 and a single Listener. Each object can be changed independently,
19 the setting of one object does not affect the setting of others.
20 The application can also set modes that affect processing. Modes
21 are set, objects specified, and other &AL; operations performed
22 by sending commands in the form of function or procedure calls.
24 Sources store locations, directions, and other attributes of an object in 3D
25 space and have a buffer associated with them for playback. There are
26 normally far more sources defined than buffers. When the program wants to play
27 a sound, it controls execution through a source object. Sources are
28 processed independently from each other.
30 Buffers store compressed or un-compressed audio data. It is common to
31 initialize a large set of buffers when the program first starts (or at
32 non-critical times during execution -- between levels in a game, for instance).
33 Buffers are referred to by Sources. Data (audio sample data) is associated
36 There is only one listener (per audio context). The listener attributes are
37 similar to source attributes, but are used to represent where the user is
38 hearing the audio from. The influence of all the sources from the
39 perspective of the listener is mixed and played for the user.
43 <note id="rfc-bk000926-03"><title>RFC: Data Binding</title><para>
44 Have to specifiy when pointer arguments are dereferenced.
48 <title>Primitive Types</title>
50 As &AL; is meant to allow for seamless integration with &OGL; code
51 if needed, the &AL; primitive (scalar) data types mimic the
52 &OGL; data types. Guaranteed minimum sizes are stated for &OGL;
53 data types (see table 2.2 of the &OGL; 1.2 Specification), but
54 the actual choice of C datatype is left to the implementation.
55 All implementations on a given binary architecture, however, must
56 use a common definition of these datatypes.
60 <note><title>RFC/000507:</title><para>
61 ALlong/ALulong are omitted from the Linux OpenGL Base ABI,
62 and the GL specification. Do we want to go ahead on this,
63 or trail GL? Do we include non-i386 architectures to list
64 sizes explicitely. I.e. do we make the ABI part of our
70 Note that this table uses explicit AL prefixes for clarity,
71 while they might be omitted from the rest of the document
72 for brevity. GCC equivalents are given for IA32, i.e. a
73 portable and widely available compiler on the most common
76 <title>&AL; Primitive Data Types</title>
77 <tgroup cols="4" align="left" colsep=1 rowsep=1>
85 <entry>GCC IA32</entry>
90 <entry> ALboolean </entry>
91 <entry> 8-bit boolean </entry>
92 <entry> GLboolean </entry>
93 <entry> unsigned char </entry>
96 <entry> ALbyte </entry>
97 <entry> signed 8-bit 2's-complement integer </entry>
98 <entry> GLbyte </entry>
99 <entry> signed char </entry>
102 <entry> ALubyte </entry>
103 <entry> unsigned 8-bit integer </entry>
104 <entry> GLubyte </entry>
105 <entry> unsigned char </entry>
108 <entry> ALshort </entry>
109 <entry> signed 16-bit 2's-complement integer </entry>
110 <entry> GLshort </entry>
111 <entry> short </entry>
114 <entry> ALushort </entry>
115 <entry> unsigned 16-bit integer </entry>
116 <entry> GLushort </entry>
117 <entry> unsigned short </entry>
120 <entry> ALint </entry>
121 <entry> signed 32-bit 2's-complement integer </entry>
122 <entry> GLint </entry>
126 <entry> ALuint </entry>
127 <entry> unsigned 32-bit integer </entry>
128 <entry> GLuint </entry>
129 <entry> unsigned int </entry>
133 <entry> ALlong </entry>
134 <entry> signed 64-bit 2's-complement integer </entry>
136 <entry> long long </entry>
139 <entry> ALulong </entry>
140 <entry> unsigned 64-bit integer </entry>
142 <entry> unsigned long long </entry>
146 <entry> ALsizei </entry>
147 <entry> non-negative 32-bit binary integer size </entry>
148 <entry> GLsizei </entry>
152 <entry> ALenum </entry>
153 <entry> enumerated 32-bit value </entry>
154 <entry> GLenum </entry>
155 <entry> unsigned int </entry>
158 <entry> ALbitfield </entry>
159 <entry> 32 bit bitfield </entry>
160 <entry> GLbitfield </entry>
161 <entry> unsigned int </entry>
164 <entry> ALfloat </entry>
165 <entry> 32-bit IEEE754 floating-point </entry>
166 <entry> GLfloat </entry>
167 <entry> float </entry>
170 <entry> ALclampf </entry>
171 <entry> Same as ALfloat, but in range [0, 1] </entry>
172 <entry> GLclampf </entry>
173 <entry> float </entry>
176 <entry> ALdouble </entry>
177 <entry> 64-bit IEEE754 floating-point </entry>
178 <entry> GLdouble </entry>
179 <entry> double </entry>
182 <entry> ALclampd </entry>
183 <entry> Same as ALdouble, but in range [0, 1] </entry>
184 <entry> GLclampd </entry>
185 <entry> double </entry>
195 <note><title>Annotation on Type Sizes</title><para>
196 It would be desirable to guarantee the bit size of &AL; data
197 types, but this might affect the mapping to &OGL; types
198 for which the &OGL; specification only guarantees a minimum
201 <note><title>Annotation on 64bit integral</title><para>
202 It would be desirable to define ulong and long, but again
203 we defer to &OGL; in this decision.
205 <note><title>Annotation on Enumeration</title><para>
206 &enum; is not a C or C++ enumeration, but implemented as
207 C preprocesor defines. This makes it easier to handle
208 extensions to the &AL; namespace, in particular in
209 dealing with delays in distributing updated reference
215 <title>Floating-Point Computation</title>
217 Any representable floating-point value is legal as input
218 to a &AL; command that requires floating point data.
219 The result of providing a value that is not a floating
220 point number to such a command is unspecified, but must not
221 lead to &AL; interruption or termination. In IEEE arithmetic,
222 for example, providing a negative zero or a denormalized
223 number to a GL command yields predictable results, while
224 providing an NaN or infinity yields unspecified results.
226 Some calculations require division. In such cases (including
227 implied divisions required by vector normalizations), a
228 division by zero produces an unspecified result but must
229 not lead to GL interruption or termination.
235 <title>AL State</title>
237 The &AL; maintains considerable state. This documents enumerates
238 each state variable and describes how each variable can be
239 changed. For purposes of discussion, state variables are
240 categorized somewhat arbitrarily by their function. For example,
241 although we describe operations that the &AL; performs on the
242 implied output buffer, the outbut buffer is not part of the
243 &AL; state. Certain states of &AL; objects (e.g. buffer states
244 with respect to queueing) are introduced for discussion purposes,
245 but not exposed through the API.
250 <title>AL Command Syntax</title>
252 &AL; commands are functions or procedures. Various groups of
253 commands perform the same operation but differ in how
254 arguments are supplied to them. To conveniently accomodate
255 this variation, we adopt the &OGL; nnotation for describing
256 commands and their arguments.
260 <note><title>Annotation (Not all types supported yet)</title><para>
261 At this time &AL; does not support the full flexibility that
262 &OGL; offers. Certain entry points are supported only for
263 some data types. In general, &AL; tends to use less entry
264 points, using setter commands that use the same tokens
265 as the matching query commands.
272 <title>Basic AL Operation</title>
274 &AL; can be used for a variety of audio playback tasks, and is an
275 excellent complement to &OGL; for real-time rendering. A programmer who is
276 familiar with &OGL; will immediately notice the similarities between the
277 two APIs in that they describe their 3D environments using similar methods.
280 For an &OGL;/&AL; program, most of the audio programming will be in two
281 places in the code: initialization of the program, and the rendering loop.
282 An &OGL;/&AL; program will typically contain a section where the graphics and
283 audio systems are initialized, although it may be spread into multiple functions.
284 For OpenAL, initialization normally consists of creating a context, creating
285 the initial set of buffers, loading the buffers with sample data, creating
286 sources, attaching buffers to sources, setting locations and directions for
287 the listener and sources, and setting the initial values for state global
292 <title>Initialization Example</title>
302 <title>Initialization Example</title>
310 The audio update within
311 the rendering loop normally consists of telling &AL; the current locations
312 of the sources and listener, updating the environment settings, and managing
318 <title>Processing Loop</title>
320 // PlaceCamera -- places OpenGL camera and updates OpenAL listener position and source state
321 void 3DEnvironemnt:PlaceCamera()
323 // update OpenGL camera position
324 glMatrixMode(GL_PROJECTION);
326 glFrustum(-0.1333, 0.1333, -0.1, 0.1, 0.2, 50.0);
328 gluLookAt(listenerPos[0], listenerPos[1], listenerPos[2],
329 (listenerPos[0] + sin(listenerAngle)), listenerPos[1], (listenerPos[2] - cos(listenerAngle)),
333 // place listener at camera
334 alListener3f(AL_POSITION, listenerPos[0], listenerPos[1], listenerPos[2]);
335 float directionvect[6];
336 directionvect[0] = (float) sin(listenerAngle);
337 directionvect[1] = 0;
338 directionvect[2] = (float) cos(listenerAngle);
339 directionvect[3] = 0;
340 directionvect[4] = 1;
341 directionvect[5] = 0;
342 alListenerfv(AL_ORIENTATION, directionvect);
344 // play phasor if in range, else stop playback
347 alSourcePlay(source[1]);
350 alSourceStop(source[1]);
360 <title>AL Errors</title>
362 The AL detects only a subset of those conditions that could be
363 considered errors. This is because in many cases error checking
364 would adversely impact the performance of an error-free program.
366 <funcsynopsis><funcprototype>
367 <funcdef> &enum; <function> GetError </function></funcdef>
369 </funcprototype></funcsynopsis>
370 is used to obtain error information. Each detectable error is
371 assigned a numeric code. When an error is detected by AL,
372 a flag is set and the error code is recorded. Further errors,
373 if they occur, do not affect this recorded code. When GetError
374 is called, the code is returned and the flag is cleared, so that
375 a further error will again record its code. If a call to GetError
376 returns NO_ERROR then there has been no detectable error since
377 the last call to GetError (or since the AL was initialized).
381 <note id="rfc-bk000926-04"><title>RFC: GL distributed error </title><para>
382 To allow for distributed implementations there may be several
383 flag/code pairs. In this case, after a call to GetError returns a
384 value other than NO_ERROR each subsequent call returns the
385 non-NO_ERROR code of another distinct flag-code pair (in
386 unspecified order), until all NO_ERROR codes have been returned.
387 When there are no more non-NO_ERROR codes, all flags be reset.
388 The initial state of all flags is cleared and the initial value
389 of all codes is NO_ERROR.
391 <note><title>Annotation (Looping GetError)</title><para>
392 &AL; applications are advised to loop calls of GetError to
393 make sure that all flags are reset. Only the first error
394 occurence for each flag/code pair is recorded, subsequent
395 errors are ignored. The result of a repeated GetError call
396 is not a stack trace or LIFO sequence. All error handling
404 <note><title>Annotation (Only First Error)</title><para>
405 Like &OGL; &AL; will ignore subsequent errors once an
406 error conditation has been encountered.
411 Error codes can be mapped to strings. The GetString function
412 returns a pointer to a constant (literal) string that is
413 identical to the identifier used for the enumeration value,
414 as defined in the specification.
418 <note><title>Annotation/ Verbose Error String</title><para>
419 There is no need to maintain a separate GetErrorString
420 function (inspired by the proposed gluGetErrorStrings)
421 as the existing GetString entry point can be used.
428 <title>Error Conditions</title>
429 <tgroup cols="2" align="left" colsep=1 rowsep=1>
435 <entry>Description</>
441 <entry>"No Error" token.</>
444 <entry>INVALID_NAME</>
445 <entry>Invalid Name parameter.</>
448 <entry>INVALID_ENUM</>
449 <entry>Invalid parameter.</>
452 <entry>INVALID_VALUE</>
453 <entry>Invalid enum parameter value.</>
456 <entry>INVALID_OPERATION</>
457 <entry>Illegal call.</>
460 <entry>OUT_OF_MEMORY</>
461 <entry>Unable to allocate memory.</>
466 The table summarizes the AL errors. Currently, when an error flag
467 is set, results of AL operations are undefined only if OUT_OF_MEMORY
468 has occured. In other cases, the command generating the error is
469 ignored so that it has no effect on AL state or output buffer
470 contents. If the error generating command returns a value,
471 it returns zero. If the generating command modifies values
472 through a pointer argument, no change is made to these values.
473 These error semantics apply only to AL errors, not to system errors
474 such as memory access errors.
477 Several error generation conditions are implicit in the description
478 of the various AL commands. First, if a command that requires
479 an enumerated value is passed a value that is not one of those
480 specified as allowable for that command, the error INVALID_ENUM
481 results. This is the case even if the argument is a pointer to
482 a symbolic constant if that value is not allowable for the given
484 This will occur whether the value is allowable for other functions,
485 or an invalid integer value.
488 Integer parameters that are used as names for &AL; objects
489 such as Buffers and Sources are checked for validity. If an invalid
490 name parameter is specified in an &AL; command, an
491 INVALID_NAME error will be generated, and the command is ignored.
494 If a negative integer is provided where an argument of type
495 &sizei; is specified, the error INVALID_VALUE results. The same
496 error will result from attempts to set integral and floating
497 point values for attributes exceeding the legal range for
498 these. The specification does not guarantee that the implementation
499 emits INVALID_VALUE if a &NaN; or &Infty; value is
500 passed in for a &float; or &double; argument (as the specification
501 does not enforce possibly expensive testing of floating point
506 Commands can be invalid. For example, certain commands might not be
507 applicable to a given object. There are also illegal combinations
508 of tokens and values as arguments to a command. &AL; responds to any
509 such illegal command with an INVALID_OPERATION error.
514 No longer true except for extensions. To be avoided
516 mutually exclusive commands operating on similar objects.
517 One example is treating a streaming buffer as a
518 non-streaming buffer, another is appending data to a
519 non-streaming buffer.
524 If memory is exhausted as a side effect of the execution of an
525 AL command, either on system level or by exhausting the allocated
526 resources at AL's internal disposal, the error OUT_OF_MEMORY
527 may be generated. This can also happen independent of recent
528 commands if &AL; has to request memory for an internal task
529 and fails to allocate the required memory from the operating
533 Otherwise errors are generated only for conditions that are
534 explicitely described in this specification.
539 <note id="rfc-bk000807-01"><title>RFC: INVALID_SIZE?</title><para>
540 Specific error case in which the size argument is
541 negative, or mismatches internal conditions for a getter?
547 <note id="rfc-bk000802-03"><title>RFC: INVALID_POINTER?</title><para>
548 GL seemingly does not specify a response to NULL pointer
549 destinations, and does not assign an error case. INVALID_VALUE
550 could be used, also we could introduce a separate INVALID_POINTER.
551 Is there a good reason not to catch these cases?
561 <title>Controlling AL Execution</title>
563 The application can temporarily disable certain AL capabilities
564 on a per Context basis. This allows the driver implementation
565 to optimize for certain subsets of operations.
566 Enabling and disabling capabilities is handled using a function
568 <funcsynopsis><funcprototype>
569 <funcdef> &void; <function> Enable </function></funcdef>
570 <paramdef> &enum; <parameter> target </parameter></paramdef>
571 </funcprototype></funcsynopsis>
572 <funcsynopsis><funcprototype>
573 <funcdef> &void; <function> Disable </function></funcdef>
574 <paramdef> &enum; <parameter> target </parameter></paramdef>
575 </funcprototype></funcsynopsis>
576 The application can also query whether a given capability is
577 currently enabled or not.
578 <funcsynopsis><funcprototype>
579 <funcdef> &bool; <function> IsEnabled </function></funcdef>
580 <paramdef> &enum; <parameter> target </parameter></paramdef>
581 </funcprototype></funcsynopsis>
582 If the token used to specify target is not legal,
583 an INVALID_ENUM error will be generated.
586 At this time, this mechanism is not used. There are no valid
590 <note><title>Annotation (Enable/Disable)</title><para>
591 Currently, &AL; is controlled exploiting existing
592 commands. For example, to disable sound output but
593 not processing, the Listener can be muted setting
594 GAIN to zero. Selecting NONE as the distance model
595 disables distance attenuation. Setting DOPPLER_FACTOR
596 to zero disables the Doppler Effect. A redundant
597 mechanism to accomplish the same is not needed.
604 <title>Object Paradigm</title>
606 &AL; is an object-oriented API, but it does not expose classes, structs,
607 or other explicit data structures to the application.
611 <sect2 id="object-overview-categories">
612 <title>Object Categories</title>
614 &AL; has three primary categories of Objects:
618 one unique Listener per Context
623 multiple Buffers shared among Contexts
628 multiple Sources, each local to a Context
632 In the following, "{Object}" will stand for either Source,
637 <sect2 id="object-overview-dynamic">
638 <title>Static vs. Dynamic Objects</title>
640 The vast majority of &AL; objects are dynamic, and will be created
641 on application demand. There are also &AL; objects that do not have
642 to be created, and can not be created, on application demand.
643 Currently, the Listener is the only such static object in &AL;.
649 <title>Object Names</title>
651 Dynamic Objects are manipulated using an integer, which in
652 analogy to &OGL; is referred to as the object's "name". These
653 are of type unsigned integer (uint). Names can be valid
654 beyond the lifetime of the context they were requested
655 if the objects in question can be shared among contexts.
656 No guarantees or assumptions are
657 made in the specification about the precise values or their distribution
658 over the lifetime of the application. As objects might be shared,
659 Names are guaranteed to be
660 unique within a class of &AL; objects, but no guarantees are made
661 across different classes of objects. Objects that are unique
662 (singletons), like the Listener, do not require and do not have
669 <title>Requesting Object Names</title>
671 &AL; provides calls to obtain Object Names. The application requests
672 a number of Objects of a given category using Gen{Object}s.
673 If the number n of Objects requested is negative,
674 an INVALID_VALUE error will caused. The actual values of the
675 Names returned are implementation dependent. No guarantees on
676 range or value are made. Unlike &OGL; &OAL does not offer alternative
677 means to define (bind) a Name.
680 Allocation of Object Names does not imply immediate allocation of
681 resources or creation of Objects: the implementation is free to
682 defer this until a given Object is actually used in mutator calls.
683 The Names are written at the memory location specified by the caller.
684 <funcsynopsis><funcprototype>
685 <funcdef> void <function> Gen{Object}s </function></funcdef>
686 <paramdef> &sizei; <parameter> n </parameter></paramdef>
687 <paramdef> &uint;* <parameter> objectNames </parameter></paramdef>
688 </funcprototype></funcsynopsis>
691 Requesting zero names is a legal NOP. Requesting a negative
692 number of names causes an INVALID_VALUE error.
693 &AL; will respond with an OUT_OF_MEMORY if the application
694 requests too many objects. The specification does not guarantee
695 that the &AL; implementation will allocate all resources
696 needed for the actual objects at the time the names are
697 reserved. In many cases (Buffers) this could only be
698 implemented by worst case estimation. Allocation of names
699 does not guarantee that all the named objects can actually
706 We do not re-use Names under any circumstance. Do we require
707 implementations throwing OUT_OF_MERMORY errors on allocation of
708 Names? No - we don't even specify buffer sizes. Ambiguity - could
709 an implementation throw OOM because of no names, or OOM because
710 of a (worst case) estimate of object sizes? Do we need OUT_OF_NAMES?
717 The current headers include a sizei return parameter:
718 "Returns the number of ids actually allocated."
719 This violates the "failed commands are NOPs" design
720 and introduces ambiguity in error handling, and has
721 thus been changed breaking backwards compatibility.
726 <note><title>Annotation (No application selected Names)</title><para>
727 Unlike GL, applications are not free to choose Names; all
728 Names have to be requested. Aside from possible benefits for
729 the implementation, and avoidance of errors in projects
730 that have many modules using the AL implementation (a problem
731 encountered in GL, when the two generation mechanisms are
732 mixed), this also leaves open the door to feed different
733 kinds of objects by Name through the same API entry points.
738 <note><title>Annotate (Negative/zero sizei)</title><para>
739 The specification does not guarantee that sizei is an
740 unsigned integer, but legal values have to be non-negative.
741 However, requesting zero names is a legal NOP.
746 <note id=rfc-bk000626-02><title>RFC: Resource Release Hint</title><para>
747 Do we need a hint that resource release has to be done on DeleteXXX,
748 instead of leaving this housekeeping to &AL;?
750 <note id=rfc-bk000626-03><title>RFC: Zero Name</title><para>
751 Do we reserve the name "0"? &OGL; provides an alternative mechanism
752 which lets the application pick texture names, which we discarded
753 because it is prone to create error conditions when mixing both
754 approaches. As all our names are generated using GenXXXX, there
755 is no real need to treat "0" special.
763 <title>Releasing Object Names</title>
765 &AL; provides calls to the application to release Object Names
766 using Delete{Object}s, implicitly requesting deletion of the
767 Objects associated with the Names released. If the number n of Objects named
768 is negative, an INVALID_VALUE error will be caused.
769 If one or more of the specified Names is not valid, an INVALID_NAME
770 error will be caused. Implementation behavior following any error
774 Once deleted (even if an error occured on deletion), the Names are
775 no longer valid for use with any &AL; function calls including
776 calls to Delete{Objects}s. Any such use will cause an INVALID_NAME
780 The &AL; implementation is free to defer actual release of
781 resources. Ideally, resources should be released as soon as
782 possible, but no guarantees are made.
783 <funcsynopsis><funcprototype>
784 <funcdef>&void;<function>Delete{Object}s</function></funcdef>
785 <paramdef>&sizei;<parameter>n</parameter></paramdef>
786 <paramdef>&uint;*<parameter>objectNames</parameter></paramdef>
787 </funcprototype></funcsynopsis>
791 <note><title>Annotation</title><para>
792 GenXXX and DeleteXXX can not reasonably be expected to be used
793 for controlling driver-side resource management from the
794 application. A driver might never release a Source once allocated
795 during the lifetime of the application.
800 <note id="rfc-bk000724-18"><title>RFC: Deletion Errors</title><para>
802 What happens if an active source (or its associated buffer) is deleted?
803 The source should be stopped? Or the delete operation is invalid?
811 <title>Validating an Object Name</title>
813 &AL; provides calls to validate the Name of an Object.
814 The application can verify whether an Object Name is valid
815 using the Is{Object} query. There is no vector (array)
816 version of this function as it defeats the purpose of
817 unambiguous (in)valdiation. Returns &TRUE; if id is a
818 valid Object Name, and &FALSE; otherwise. Object Names are
819 valid between request (Gen{Object}s) and release (Delete{Object}s).
820 Is{Object} does not distinguish between invalid and deleted Names.
821 <funcsynopsis><funcprototype>
822 <funcdef>&bool;<function>Is{Object}</function></funcdef>
823 <paramdef>&uint;<parameter>objectName</parameter></paramdef>
824 </funcprototype></funcsynopsis>
827 <note><title>RFC/bk000504:</title><para>
828 If zero is a valid name, this function will have to accept
829 it without an actyual object (or only an internal dummy)
830 being associated with it. I recommend that implementations
831 never return "0" as an object name.
838 <title>Setting Object Attributes</title>
840 For &AL; Objects, calls to control their attributes are provided.
841 These depend on the actual properties of a given Object
842 Category. The precise API is discussed for each category,
843 below. Each &AL; command affecting the state of
844 a named Object is usually of the form
845 <funcsynopsis><funcprototype>
846 <funcdef> void <function> {Object}{n}{sifd}{v} </function></funcdef>
847 <paramdef> &uint; <parameter> objectName </parameter></paramdef>
848 <paramdef> &enum; <parameter> paramName </parameter></paramdef>
849 <paramdef> &type; <parameter> values </parameter></paramdef>
850 </funcprototype></funcsynopsis>
851 In the case of unnamed (unique) Objects, the (integer) objectName
852 is omitted, as it is implied by the {Object} part of function name:
853 <funcsynopsis><funcprototype>
854 <funcdef> void <function> {Object}{n}{sifd}{v} </function></funcdef>
855 <paramdef> &enum; <parameter> paramName </parameter></paramdef>
856 <paramdef> &type; <parameter> values </parameter></paramdef>
857 </funcprototype></funcsynopsis>
858 For example, the Listener3d command would not require an (integer)
862 The objectName specifies the &AL; object affected by this call.
863 Use of an invalid Name will cause an INVALID_NAME error.
866 The Object's Attribute to be affected has to be named
867 as paramName. &AL; parameters applicable to one category
868 of Objects are not necessarily legal for another catetgory
869 of &AL; Objects. Specification of a parameter illegal for
870 a given object will cause an INVALID_OPERATION error.
873 Not all possible values for a type will be legal for a
874 given objectName and parameterName. Use of an illegal value
875 or a NULL value pointer will cause an INVALID_VALUE error.
878 Any command that causes an error is a NOP.
883 <title>Querying Object Attributes</title>
885 For named and for unique &AL; Objects, calls to query their
886 current attributes are provided.
887 These depend on the actual properties of a given Object
888 Category. The performance of such queries is implementation
889 dependent, no performance guarantees are made. The valid values for the
890 parameter paramName are identical to the ones legal for the complementing
891 attribute setting function.
892 <funcsynopsis><funcprototype>
893 <funcdef> void <function> Get{Object}{n}{sifd}{v} </function></funcdef>
894 <paramdef> &uint; <parameter> objectName </parameter></paramdef>
895 <paramdef> &enum; <parameter> paramName </parameter></paramdef>
896 <paramdef> &type;* <parameter> destination </parameter></paramdef>
897 </funcprototype></funcsynopsis>
898 For unnamed unique Objects, the objectName is omitted as it is
899 implied by the function name:
900 <funcsynopsis><funcprototype>
901 <funcdef> void <function> Get{Object}{n}{sifd}{v} </function></funcdef>
902 <paramdef> &enum; <parameter> paramName </parameter></paramdef>
903 <paramdef> &type;* <parameter> destination </parameter></paramdef>
904 </funcprototype></funcsynopsis>
907 The precise API is discussed for each category separately, below.
908 Unlike their matching mutators, Query functions for non-scalar
909 properties (vectors etc.) are only available in array form.
912 Use of an invalid Name will cause an INVALID_NAME error.
913 Specification of an illegal parameter type (token) will cause
914 an INVALID_ENUM error. A call with a destination
915 NULL pointer will be quietly ignored. The &AL; state will not
916 be affected by errors. In case of errors, destination memory
923 <title>Object Attributes</title>
926 Attributes affecting the processing of sounds can be set for various
927 &AL; Object categories, or might change as an effect of &AL; calls.
928 The vast majority of these Object properties are specific to the
929 &AL; Object category, in question, but some are applicable to two
930 or more categories, and are listed separately.
933 The general form in which this document describes parameters is
935 <title>{Object} Parameters</title>
936 <tgroup cols="4" align="left" colsep=1 rowsep=1>
953 <entry> range or set </>
954 <entry> scalar or n-tuple </>
960 The description specifies additional restrictions and details.
961 paramName is given as the &AL; enum defined as its name.
962 T can be a list of legal signatures, usually the array form
963 as well as the flat (unfolded) form.
968 <note id="rfc-bk000626-04"><title>RFC: Initial (Default) State</title><para>
969 The default state of objects will have to be specified here.
970 There will be no commands that allow the application to set