[Openal] Re: openal output timing

[Daniel]

openal-request at opensource.creative.com escreveu:
> Send Openal mailing list submissions to
> 	openal at opensource.creative.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://opensource.creative.com/mailman/listinfo/openal
> or, via email, send a message with subject or body 'help' to
> 	openal-request at opensource.creative.com
>
> You can reach the person managing the list at
> 	openal-owner at opensource.creative.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Openal digest..."
>
>
> Today's Topics:
>
>    1. openal output timing (Daniel)
>    2. Re: openal output timing (Chris Robinson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 28 Feb 2009 13:57:06 -0300
> From: Daniel <danflu at uninet.com.br>
> Subject: [Openal] openal output timing
> To: openal at opensource.creative.com
> Message-ID: <49A96CE2.5020607 at uninet.com.br>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> Can I use AL_SAMPLE_OFFSET to estimate the exact time the next sample I 
> put in the openal queue will  by heard in the loudspeakers ?
>
> If not, how can it be done to achieve the minimum error ?  How many 
> miliseconds is this error supposed to be ?
>
> I'm asking about AL_SAMPLE_OFFSET because AL_SEC_OFFSET  always returns 
> zero, and i think i can simply convert between samples to seconds.
>
> Thanks in advance,
> Daniel
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 28 Feb 2009 11:03:32 -0800
> From: Chris Robinson <chris.kcat at gmail.com>
> Subject: Re: [Openal] openal output timing
> To: openal at opensource.creative.com
> Message-ID: <200902281103.32408.chris.kcat at gmail.com>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On Saturday 28 February 2009 8:57:06 am Daniel wrote:
>   
>> Hi,
>>
>> Can I use AL_SAMPLE_OFFSET to estimate the exact time the next sample I
>> put in the openal queue will  by heard in the loudspeakers ?
>>
>> If not, how can it be done to achieve the minimum error ?  How many
>> miliseconds is this error supposed to be ?
>>     
>
> Hi Daniel.
>
> I think the simplest way to determine when the next sample you put into a 
> queue will be heard is by taking the total length (in samples) of the queue, 
> then subtracting the value gotten from AL_SAMPLE_OFFSET. You'll have to keep 
> track of the size of the queue yourself, but it shouldn't be too hard if each 
> buffer is a fixed size (decrease the size when you unqueue, increase when you 
> queue).
>
> This should be close enough for most purposes. There may be an additional 
> delay introduced by the sound card itself, but this likely won't exceed 20ms 
> or so. There isn't any way to measure this, unfortunately.
>   

Hi Chris,
Thank you.

My sync now is pretty better... I was estimating it the wrong way (using 
only the offset information, which now I realize doesn't make any sense...)
>   
>> I'm asking about AL_SAMPLE_OFFSET because AL_SEC_OFFSET  always returns
>> zero, and i think i can simply convert between samples to seconds.
>>     
>
> Just to note though, make sure you're retrieving the value as a float. If you 
> get it as an int, or convert it to an int, it will be truncated to the lowest 
> integer. For example, if the buffer is at 0.2 seconds (8,820 samples for 
> 44.1khz), or 0.5 seconds (22,050 samples for 44.1khz), or anything below 1 
> second, the value will get truncated to 0.
>   
Sure! You're right.
Now it works fine.

Just a last question:

What is the best way to estimate the time delay associated with the 
first input sample in the capture device?

Can I just use alcGetIntegerv(alcDevice, ALC_CAPTURE_SAMPLES, 
sizeof(ALCint),  &samples)  and convert it to seconds ? Would this work?

Thanks again,
Daniel
> ------------------------------
>
> _______________________________________________
> Openal mailing list
> Openal at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal
>
>
> End of Openal Digest, Vol 35, Issue 15
> **************************************
>
>
>