[Openal-devel] Another extension..

[Chris Robinson]

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).