<div dir="ltr">Sounds good - presumably there are no current plans to add a device output frequency change to the spec, but can always change the code at that point if needed.</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 24 January 2014 13:44, 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 04:34 AM, Doug Binks wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Makes sense. Since this needs new code for atomically getting a device<br>
timer etc., also adding code for this shouldn't be too much of an extra<br>
problem although it does add to device maintenance costs.<br>
</blockquote>
<br></div>
It should be fine to just add another field to ALCdevice, something like<br>
ALuint64 SamplesMixed;<br>
which would be initialized to 0 and incremented in aluMixData. Then when the clock time is queried, convert it using the device frequency.<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>