<div dir="ltr">I'll have a think - this would accumulate a small amount of error but it should be OK. Another potential would be to recalculate the number of samples when the frequency is changed into the new sample rate.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On 24 January 2014 14:22, Chris Robinson <span dir="ltr"><<a href="mailto:chris.kcat@gmail.com" target="_blank">chris.kcat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 01/24/2014 05:14 AM, Doug Binks wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sounds good - presumably there are no current plans to add a device output<br>
frequency change to the spec, but can always change the code at that point<br>
if needed.<br>
</blockquote>
<br></div>
Hmm, that's a good point, actually. The playback frequency can change if a new context is created and specifies an ALC_FREQUENCY attribute.<br>
<br>
In that case, a better option would be to store the clock time in the device, instead of the samples mixed. Then you'd increase the clock time in aluMixData by converting the number of samples to mix into a time increment.<div class="HOEnZb">
<div class="h5"><br>
______________________________<u></u>_________________<br>
openal mailing list<br>
<a href="mailto:openal@openal.org" target="_blank">openal@openal.org</a><br>
<a href="http://openal.org/mailman/listinfo/openal" target="_blank">http://openal.org/mailman/<u></u>listinfo/openal</a><br>
</div></div></blockquote></div><br></div>