[Openal-devel] AL_BYTE_OFFSET

[Ramy Sadek]

Thanks Garin, 

I didn't realize that buffers of different types cannot be queued into a
source. This must be an oversight on my part. Could you point me/us to
the documentation wherein this constraint is outlined? 

Thanks!

-Ramy

-----Original Message-----
From: Garin Hiebert [mailto:garinh at cheesetoast.net] 
Sent: Friday, February 10, 2006 11:31 AM
To: Ramy Sadek
Cc: openal-devel at opensource.creative.com
Subject: Re: [Openal-devel] AL_BYTE_OFFSET


> Implementing AL_BYTE_OFFSET leads me to some confusion. Consider 3 
> files FileA, FileB and FileC, which are in differing formats, MONO8, 
> MONO16 and STERO16 respectively. If these 3 files are queued into a 
> buffer, what is the meaning of calls like
>

The files can't be concatenated into the same buffer, since they are 
different formats.  If placed in three separate buffers, they can't be 
queued onto the same source, also because they are of different formats 
(source queues can only have one format).
>
>  alSourcei(source, AL_BYTE_OFFSET, num) ?
>
> Depending on the order of the files, <num> bytes represents a 
> different number of samples (and therefore different amounts of time).

>  Specifically, <num> refers to twice as many samples in the MONO8 
> FileA as it does in the 16-bit files FileB and FileC.
>

AL_BYTE_OFFSET is always in bytes, so there wouldn't be any confusion if

you could do what you describe.  Such confusion would exist with 
AL_SAMPLE_OFFSET, but since the formats can't be mixed it's not a
problem.

>  Furthermore, if implementations are using longer words to represent 
> samples internally (e.g. 32 bit float samples), the meaning of 
> AL_BYTE_OFFSET is even less clear.
>
The application can use AL_SAMPLE_OFFSET to avoid this type of issue.


Garin