|
»
Another extension..
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Another extension..
by Chris Robinson-5
::
Rate this Message:
Here's another extension I came up with recently to help ease issues I've been
having with a certain project using OpenAL. I'll understand if people don't think it's a good idea as a general extension, but unless there are alternative methods to updating random sections of a pre-defined playing buffer that I'm missing, I would like at least OpenAL Soft to have it.. BTW, any news on my last two proposals? Name EXT_buffer_sub_data Name Strings AL_EXT_buffer_sub_data Version 1.0 Number ?? Overview This extension allows an application to modify a section of buffered sample data while the buffer is in use. Issues Q: What is the purpose of this extension? Buffer queues are already provided to handle real-time streaming. A: It is true that streaming is handled (arguably) more effectively with buffer queues. However, this method is a departure from methods of other prominant sound APIs, and in places where OpenAL is used as one of several output backend for a higher-level API, the flexibility provided by this method can make such integration easier. Q: The new function takes offset and length parameters in sample frames. How is this handled with implementations which resample/convert sample data when loaded? A: The sample frames are assumed to be relative to the frequency passed to alBufferData. For example, if an app calls alBufferData with a frequency of 44100, an offset of 22050 is a half-second from the beginning. It's the implementation's responsibility to cleanly resample and fit the data into the resampled buffer. Q: How does this extension interact with X-RAM? A: TDB. Ideally, it should behave the same irrespective of whether a buffer is placed in system memory or in the audio device's memory. However, if updating a buffer in the audio device's memory in real-time is not very feasible, it may need to be allowed to fail there. New Procedures and Functions void alBufferSubDataEXT(ALuint buffer, ALenum format, const ALvoid *data, ALsizei offset, ALsizei length); New Tokens None. Additions to Specification To update a section of buffered sample data, call the function void alBufferSubDataEXT(ALuint buffer, ALenum format, const ALvoid *data, ALsizei offset, ALsizei length); The named <buffer> is the buffer ID which had previously been used with a call to alBufferData. Calling alBufferSubDataEXT with a <buffer> which has not been used with alBufferData results in an AL_INVALID_NAME error. <buffer> may be attached to a source (either queued or with the source's AL_BUFFER property), and the source does not need to be stopped, paused, or in an initial state to be modified. The <offset> value is the number of sample frames from the start of the original data, and <length> is the number of sample frames to modify. If either <offset> or <length> is negative, or if the sum of <offset> and <length> reaches beyond the end of the buffer, an AL_INVALID_VALUE error is generated. The specified <format> is the sample format of the passed <data>. The passed format does not need to have the same bit-depth (the implementation will be expected to convert), but the channel configuration must be the same as the format used with alBufferData, or AL_INVALID_ENUM results. Errors The error AL_INVALID_ENUM is generated if the channel configuration of <format> does not match the channel configuration of the format previously passed to alBufferData. The error AL_INVALID_NAME is generated if <buffer> was not previously used with alBufferData. The error AL_INVALID_VALUE is generated if <offset> or <length> is negative, or they specify a segment that is beyond the range of the buffer. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: Another extension..
by Jason Daly
::
Rate this Message:
Chris Robinson wrote:
> Here's another extension I came up with recently to help ease issues I've been > having with a certain project using OpenAL. I'll understand if people don't > think it's a good idea as a general extension, but unless there are > alternative methods to updating random sections of a pre-defined playing > buffer that I'm missing, I would like at least OpenAL Soft to have it.. > Would this be used with a looping buffer to provide something similar to DirectSound? If so, wouldn't you also need a way to get the current read/write cursor position? It seems like there is some basic level of protection missing. For example, how do you keep from modifying the section of buffer that's currently being read by the audio device? > BTW, any news on my last two proposals? > Not here :-) --"J" _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: Another extension..
by Chris Robinson-5
::
Rate this Message:
On Monday 03 November 2008 07:15:02 am you wrote:
> Would this be used with a looping buffer to provide something similar to > DirectSound? More or less. > If so, wouldn't you also need a way to get the current > read/write cursor position? The current read cursor position would be the sample/sec offset, properly offset if dealing with queued buffers. Sub-buffering compressed formats would just need to make sure to provide offsets/lengths that are block aligned.. eg, 65 sample frames for IMA4 (I'll add a note about this). I'm not sure how to effectively get a write cursor position, though.. the amount actually read per update isn't always static. You could fake it using whatever the update size is, but this isn't foolproof.. the write position could be inside the next "to be read" section, or it could be a bit ahead of it. And when you consider pitch changes (both via source property and calculated), it becomes a bit more difficult. AFAIK, DSound always gave a specific write cursor position. When software mixing, especially, it would put the write cursor to just behind the play cursor unless you enabled the DSBCAPS_GETCURRENTPOSITION2 flag, then it would put it something like 10 or 15ms in front of the read position. If it comes down to it, I can make a read-only source property AL_SAMPLE_RW_OFFSETS_EXT to get the read and write sample offsets (stores in two values.. first being the read offset, which is the same as AL_SAMPLE_OFFSET, and the second being whatever the write offset should be). But I don't think it would be too useful, considering.. > It seems like there is some basic level of protection missing. For > example, how do you keep from modifying the section of buffer that's > currently being read by the audio device? The same way the source or listener position doesn't get updated by the device while in the middle of being changed. :) There is an implicit lock on the library/context so that an update can't occur in the middle of a modification. An OpenAL call is basically atomic with respect to itself. If it was a lock/map and unlock/unmap like in DSound, there could be an issue.. but I don't think there is this way. > > BTW, any news on my last two proposals? > > Not here :-) Okay.. so as long as there aren't any glaring issues, I'll implement them as AL_EXTX_? The extra X meaning they're in-progress extensions that developers can play around with, but not use in production code as they will be changed/removed as the extension spec gets worked on (GL does this too, though you don't generally see them in release drivers; exceptions being the likes of GL_EXTX_framebuffer_mixed_formats and GL_NVX_conditional_render in the current nvidia drivers). _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: Another extension..
by Chris Robinson-5
::
Rate this Message:
An updated version of the spec. If there's no objections, I'll commit it to
OpenAL Soft as AL_EXTX_buffer_sub_data, making sure to note the temporary and volatile nature of it. I'll still be able to change it if more issues are brought up or rethought, until it's accepted. Name EXT_buffer_sub_data Name Strings AL_EXT_buffer_sub_data Version 1.0 Number ?? Overview This extension allows an application to modify a section of buffered sample data while the buffer is in use. Issues Q: What is the purpose of this extension? Buffer queues are already provided to handle real-time streaming. A: While streaming is arguably handled more effectively with buffer queues, this method is a departure from of other prominant sound APIs. In places where OpenAL is used as one of several output backends for a higher-level API, or used to provide the functionality of other sound APIs, the flexibility provided by this method can make such integration easier. Q: The new function takes offset and length parameters in sample frames. How is this handled with implementations which resample/convert sample data when loaded? A: The sample frames are assumed to be relative to the frequency passed to alBufferData. For example, if an app calls alBufferData with a frequency of 44100, an offset of 22050 is a half-second from the beginning. It's the implementation's responsibility to cleanly resample and fit the data into the resampled buffer. Q: How does this extension interact with X-RAM? A: TDB. Ideally, it should behave the same irrespective of whether a buffer is placed in system memory or in the audio device's memory. However, if updating a buffer in the audio device's memory in real-time is not very feasible, it may need to be allowed to fail there. Q: No method is provided to retrieve the source's "write cursor". Should there be one? A: This is likely not necessary. Like other AL functions, async updates are blocked until the call completes. It is the responsibility of the implementation to make sure an update doesn't occur while a buffer is being modified. Q: How are compressed formats handled? A: When modifying compressed data, the sample offset and length specified must be block aligned (eg. for IMA4, they must be multiples of 65). In addition, the format must be the same format the buffer was created with. Complex compressed formats, like Vorbis or MP3, may not be modified this way. New Procedures and Functions void alBufferSubDataEXT(ALuint buffer, ALenum format, const ALvoid *data, ALsizei offset, ALsizei length); New Tokens None. Additions to Specification To update a section of buffered sample data, use the function void alBufferSubDataEXT(ALuint buffer, ALenum format, const ALvoid *data, ALsizei offset, ALsizei length); The named <buffer> is one which was previously created with a call to alBufferData. Calling alBufferSubDataEXT with a <buffer> which was not previously created results in an AL_INVALID_NAME error. <buffer> may be attached to a source (either queued or by the AL_BUFFER property), and the source does not need to be stopped, paused, or in an initial state to be modified. The <offset> value is the number of sample frames from the start of the original data, and <length> is the number of sample frames to modify. If either <offset> or <length> is negative, or if the sum of <offset> and <length> reaches beyond the end of the buffer, an AL_INVALID_VALUE error is generated. For compressed formats, <length> and <offset> must be appropriately block aligned. Complex compressed formats (those with no constant compressed and uncompressed block lengths) may not be modified, and will result in an AL_INVALID_ENUM error. The specified <format> is the sample format of the passed <data>. The passed format does not need to have the same bit-depth (the implementation will be expected to convert), but the channel configuration must match the format used with alBufferData, or AL_INVALID_ENUM results. If <buffer> was created with a compressed format, the specified <format> must precisely match, or an AL_INVALID_ENUM error is generated. Errors The error AL_INVALID_ENUM is generated if the channel configuration of <format> does not match the channel configuration of the format previously passed to alBufferData. The error AL_INVALID_ENUM is generated if <buffer> was created with a compressed format and <format> does not precisely match. The error AL_INVALID_ENUM is generated if <buffer> was created with a complex compressed format. The error AL_INVALID_NAME is generated if <buffer> was not previously created with alBufferData. The error AL_INVALID_VALUE is generated if <offset> or <length> is negative, or they specify a segment that is beyond the range of the buffer. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
|
|
|
Re: Another extension..
by Erik Hofman
::
Rate this Message:
Chris Robinson wrote:
> On Thursday 06 November 2008 12:18:19 am you wrote: >> One thing that concerns me a bit is that Buffer data can be used in >> several ways internally; >> >> 1. Use the data directly for the mixer (software implementation) >> 2. Copy data to the soundcard memory and use it from there. >> >> I believe 2. is the way textures are handled in OpenGL and is >> incompatible with this extension as far as I can see. > > I don't see why it would be. In OpenGL, you have glTexSubImage?D (which > similarly updates just a subsection of a texture). Likewise, a hardware > OpenAL driver should be able to just update a portion of an on-card buffer. Ok, I see. It probably takes a bit more work for on-board samples but it will work indeed. Erik _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: Another extension..
by Daniel PEACOCK
::
Rate this Message:
Hi Chris, I'm not sure how safe this extension would be ... The same Buffer can be attached to more than one Source - which could all be playing the Buffer at different playback positions (and at different pitches). You would need to know where all the Source read (or write) cursors are in an atomic operation if you wanted to be sure to avoid glitches. In the case of hardware - when a voice needs new sample data, a kernel level interrupt is used - and you don't want to stall those waiting for a user level operation to complete. FYI ... In ALchemy (DirectSound -> OpenAL converter) I had to emulate DirectSound circular buffer streaming using OpenAL buffer queuing. I do that by creating a few small AL Buffers that are constantly unqueued, filled and re-queued using a multimedia timer. Each time a Buffer is processed, the emulated DirectSoundBuffer play cursor is incremented by the processed buffer length. Each time a new buffer is queued, the DirectSoundBuffer write cursor is incremented by the queued buffer length (these happen all in the same update so the play and write cursors maintain the same distance apart). As the application should never be writing between the play and write cursors (which would be the data contained in my Source Buffer Queue) everything works OK. Would something similar work for you? Dan Creative Labs (UK) Ltd. Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you. Chris Robinson <chris.kcat@gmail .com> To Sent by: "openal-devel@... openal-devel-boun om" ces@... <openal-devel@... eative.com om> cc 11/05/2008 10:43 Subject PM Re: [Openal-devel] Another extension.. An updated version of the spec. If there's no objections, I'll commit it to OpenAL Soft as AL_EXTX_buffer_sub_data, making sure to note the temporary and volatile nature of it. I'll still be able to change it if more issues are brought up or rethought, until it's accepted. Name EXT_buffer_sub_data Name Strings AL_EXT_buffer_sub_data Version 1.0 Number ?? Overview This extension allows an application to modify a section of buffered sample data while the buffer is in use. Issues Q: What is the purpose of this extension? Buffer queues are already provided to handle real-time streaming. A: While streaming is arguably handled more effectively with buffer queues, this method is a departure from of other prominant sound APIs. In places where OpenAL is used as one of several output backends for a higher-level API, or used to provide the functionality of other sound APIs, the flexibility provided by this method can make such integration easier. Q: The new function takes offset and length parameters in sample frames. How is this handled with implementations which resample/convert sample data when loaded? A: The sample frames are assumed to be relative to the frequency passed to alBufferData. For example, if an app calls alBufferData with a frequency of 44100, an offset of 22050 is a half-second from the beginning. It's the implementation's responsibility to cleanly resample and fit the data into the resampled buffer. Q: How does this extension interact with X-RAM? A: TDB. Ideally, it should behave the same irrespective of whether a buffer is placed in system memory or in the audio device's memory. However, if updating a buffer in the audio device's memory in real-time is not very feasible, it may need to be allowed to fail there. Q: No method is provided to retrieve the source's "write cursor". Should there be one? A: This is likely not necessary. Like other AL functions, async updates are blocked until the call completes. It is the responsibility of the implementation to make sure an update doesn't occur while a buffer is being modified. Q: How are compressed formats handled? A: When modifying compressed data, the sample offset and length specified must be block aligned (eg. for IMA4, they must be multiples of 65). In addition, the format must be the same format the buffer was created with. Complex compressed formats, like Vorbis or MP3, may not be modified this way. New Procedures and Functions void alBufferSubDataEXT(ALuint buffer, ALenum format, const ALvoid *data, ALsizei offset, ALsizei length); New Tokens None. Additions to Specification To update a section of buffered sample data, use the function void alBufferSubDataEXT(ALuint buffer, ALenum format, const ALvoid *data, ALsizei offset, ALsizei length); The named <buffer> is one which was previously created with a call to alBufferData. Calling alBufferSubDataEXT with a <buffer> which was not previously created results in an AL_INVALID_NAME error. <buffer> may be attached to a source (either queued or by the AL_BUFFER property), and the source does not need to be stopped, paused, or in an initial state to be modified. The <offset> value is the number of sample frames from the start of the original data, and <length> is the number of sample frames to modify. If either <offset> or <length> is negative, or if the sum of <offset> and <length> reaches beyond the end of the buffer, an AL_INVALID_VALUE error is generated. For compressed formats, <length> and <offset> must be appropriately block aligned. Complex compressed formats (those with no constant compressed and uncompressed block lengths) may not be modified, and will result in an AL_INVALID_ENUM error. The specified <format> is the sample format of the passed <data>. The passed format does not need to have the same bit-depth (the implementation will be expected to convert), but the channel configuration must match the format used with alBufferData, or AL_INVALID_ENUM results. If <buffer> was created with a compressed format, the specified <format> must precisely match, or an AL_INVALID_ENUM error is generated. Errors The error AL_INVALID_ENUM is generated if the channel configuration of <format> does not match the channel configuration of the format previously passed to alBufferData. The error AL_INVALID_ENUM is generated if <buffer> was created with a compressed format and <format> does not precisely match. The error AL_INVALID_ENUM is generated if <buffer> was created with a complex compressed format. The error AL_INVALID_NAME is generated if <buffer> was not previously created with alBufferData. The error AL_INVALID_VALUE is generated if <offset> or <length> is negative, or they specify a segment that is beyond the range of the buffer. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel ForwardSourceID:NT00066F62 _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: Another extension..
by Chris Robinson-5
::
Rate this Message:
On Thursday 06 November 2008 02:25:30 am you wrote:
> Hi Chris, > > I'm not sure how safe this extension would be ... > > The same Buffer can be attached to more than one Source - which could all > be playing the Buffer at different playback positions (and at different > pitches). You would need to know where all the Source read (or write) > cursors are in an atomic operation if you wanted to be sure to avoid > glitches. Wouldn't this also be the case for DirectSound, though? IDirectSound::DuplicateSoundBuffer in essence creates another source that shares the original's buffer. Locking one dsound buffer affects the other, and each dsound buffer can have its own read/write position and pitch (and have such pitch be modified by doppler). > FYI ... In ALchemy (DirectSound -> OpenAL converter) I had to emulate > DirectSound circular buffer streaming using OpenAL buffer queuing. I do > that by creating a few small AL Buffers that are constantly unqueued, > filled and re-queued using a multimedia timer. Each time a Buffer is > processed, the emulated DirectSoundBuffer play cursor is incremented by the > processed buffer length. Each time a new buffer is queued, the > DirectSoundBuffer write cursor is incremented by the queued buffer length > (these happen all in the same update so the play and write cursors maintain > the same distance apart). As the application should never be writing > between the play and write cursors (which would be the data contained in my > Source Buffer Queue) everything works OK. Would something similar work > for you? This is something I tried, but I ran into difficult issues. To be completely honest and open about this, I'm also trying to make a dsound->openal wrapper. Mostly for Wine (which with an openal dll thunk can make dsound apps work using the host system's openal lib, whichever it may be; I currently have Morrowind/Oblivion outputting full 3D surround sound via openal-soft on Linux), but also to provide a native Linux/Unix dsound lib to help with porting over Windows apps. It is working, but without an extension like this, updating the buffer is unstable. The main issues I had were: A) Actually getting a dsound buffer into streaming mode. I wouldn't trust the lack of the DSBCAPS_STATIC flag to mean the buffer would definitely be updated during play, nor does the presence of it mean it can't be updated during play. I would attach the buffer to the source on dsound buffer init so that SetCurrentPosition and other such calls would work. Because of this, on Unlock I would have to try get the source's position, stop/rewind it, detach the buffer, rebuffer the data (and hope there wasn't a duplicated buffer also using it that would prevent alBufferData from failing), reattach the buffer, then reset the source's position. One or two alBufferSubDataEXT calls would do less work than the alBufferData+reattach calls alone, as it would just update an existing section of data instead of reloading the whole thing. B) No way to keep a sane write-ahead value. Freq/refresh would come out to be somewhere around 1K for me (~4K buffer with 4 periods). 1K on 48khz output is 21ms. This is best case.. an update will take 21ms worth of data, then rest, allowing me to unqueue and requeue a buffer. Realistically I'll need at least two buffers so I can requeue one while the other is being played, but I'll likely need three or four if I want to be sure I won't miss requeues due to unexpected CPU use or thread locks, getting up to 84ms of data queued at any given time. Some games start breaking down when they get a write cursor more than 15ms in front of the read cursor (Wine had documented this; a particular game would break if the write cursor was 20ms or more ahead of the read cursor, but would be fine if it was reported as only 10 or 15ms ahead). And that's saying nothing about the added CPU cost, or extra code complexity for bugs to hide in, etc. AL_EXT_buffer_sub_data solves all of that by providing the necessary functionality cleanly. If you need a write cursor, sure.. a read-only source property AL_SAMPLE_RW_OFFSETS_EXT that returns two ints (the read and write sample offsets repsectively) is more than possible... possibly even with pairing AL_BYTE_RW_OFFSETS_EXT and AL_SEC_RW_OFFSETS_EXT. Though I'm not sure it would be too useful in this context since the difference may be larger than some apps will like. Might just be better to take the play position and move it up 10 or 15ms to use as the write position. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: Another extension..
by Chris Robinson-5
::
Rate this Message:
Added the new AL_*_RW_OFFSETS_EXT tokens, and rewrote the issue dealing with
X-RAM/hardware buffers. In particular, I'd like to make sure the new tokens don't clash with existing ones (I tried to use the next available source property values, though it's difficult to say if the values are duplicates since the existing enums in the headers aren't ordered). Any other issues? Name EXT_buffer_sub_data Name Strings AL_EXT_buffer_sub_data Version 1.0 Number ?? Overview This extension allows an application to modify a section of buffered sample data while the buffer is in use. Issues Q: What is the purpose of this extension? Buffer queues are already provided to handle real-time streaming. A: While streaming is arguably handled more effectively with buffer queues, this method is a departure from of other prominant sound APIs. In places where OpenAL is used as one of several output backends for a higher-level API, or used to provide the functionality of other sound APIs, the flexibility provided by this extension can make such integration easier. Q: The new function takes offset and length parameters in sample frames. How is this handled with implementations which resample/convert sample data when loaded? A: The sample frames are assumed to be relative to the frequency passed to alBufferData. For example, if an app calls alBufferData with a frequency of 44100, an offset of 22050 is a half-second from the beginning. It's the implementation's responsibility to cleanly resample and fit the data into the resampled buffer. Q: How are compressed formats handled? A: When modifying compressed data, the sample offset and length specified must be block aligned (eg. for IMA4, they must be multiples of 65). In addition, the format must be the same format the buffer was created with. Complex compressed formats, like Vorbis or MP3, may not be modified this way. Q: Should there be a method to retrieve the source's "write cursor"? A: Yes. When updating buffers that play on a hardware voice, it would be desireable to make sure the section currently being read by the hardware isn't modified. The section being read is given by the new AL_*_RW_OFFSETS_EXT read-only source properties. Q: How does this extension interact with hardware storage/streaming? A: Updating a buffer is allowed regardless of where it is stored. However, applications should take care to not modify the data between the reported read/write offsets, or else an asyncronous update may try to read from data that's being modified. New Procedures and Functions void alBufferSubDataEXT(ALuint buffer, ALenum format, const ALvoid *data, ALsizei offset, ALsizei length); New Tokens Accepted by the <paramName> parameter of alGetSourceiv and alGetSourcefv: AL_BYTE_RW_OFFSETS_EXT 0x1031 AL_SAMPLE_RW_OFFSETS_EXT 0x1032 AL_SEC_RW_OFFSETS_EXT 0x1033 Additions to Specification To update a section of buffered sample data, use the function void alBufferSubDataEXT(ALuint buffer, ALenum format, const ALvoid *data, ALsizei offset, ALsizei length); The named <buffer> is one which was previously defined with a call to alBufferData. Calling alBufferSubDataEXT with a <buffer> which was not previously defined results in an AL_INVALID_NAME error. <buffer> may be attached to a source (either queued or by the AL_BUFFER property), and the source does not need to be stopped, paused, or in an initial state to be modified. The <offset> value is the number of sample frames from the start of the original data, and <length> is the number of sample frames, to modify. If either <offset> or <length> is negative, or if the sum of <offset> and <length> reaches beyond the end of the buffer, an AL_INVALID_VALUE error is generated. For compressed formats, <length> and <offset> must be appropriately block aligned. Complex compressed formats (those with no constant compressed and uncompressed block lengths) may not be modified, and will result in an AL_INVALID_ENUM error. The specified <format> is the sample format of the passed <data>. The passed format does not need to have the same bit-depth (the implementation will be expected to convert), but the channel configuration must match the format used with alBufferData, or AL_INVALID_ENUM results. If <buffer> was defined with a compressed format, the specified <format> must precisely match, or an AL_INVALID_ENUM error is generated. When modifying a playing source's buffer, an application must take care to not modify the section that is currently being played. The read-only source attributes AL_BYTE_RW_OFFSETS_EXT AL_SAMPLE_RW_OFFSETS_EXT AL_SEC_RW_OFFSETS_EXT may be specified as the <paramName> parameter to alGetSourceiv and alGetSourcefv to retrieve two offset values. The first is the read offset, which is identical to the value given by AL_BYTE_OFFSET, AL_SAMPLE_OFFSET, and AL_SEC_OFFSET, respectively. The second value is the offset an application may safely write to, expressed in compressed bytes, uncompressed sample frames, and seconds, respectively. If the source is not in an AL_PLAYING state, the read and write offsets will be the identical. Behavior is undefined if an attempt is made to modify buffer data between the read and write offsets. Errors The error AL_INVALID_ENUM is generated if the channel configuration of <format> does not match the channel configuration of the format previously passed to alBufferData. The error AL_INVALID_ENUM is generated if <buffer> was created with a compressed format and <format> does not precisely match. The error AL_INVALID_ENUM is generated if <buffer> was created with a complex compressed format. The error AL_INVALID_NAME is generated if <buffer> was not previously created with alBufferData. The error AL_INVALID_VALUE is generated if <offset> or <length> is negative, or they specify a segment that is beyond the range of the buffer. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
| Free embeddable forum powered by Nabble | Forum Help |
