<div dir="ltr"><div>[Just an FYI, TL;DR: wait until I finish the prototype.]</div><div><br></div>I've started a prototype implementation, with temporary extension name AL_SOFT_device_clock on a branch on my github fork of OpenAL (otherwise unchanged from the main repo).<div>
<br></div><div><a href="https://github.com/dougbinks/openal-soft/commits/Device_Clock">https://github.com/dougbinks/openal-soft/commits/Device_Clock</a><br></div><div><br></div><div>Currently the functionality is just for getting the required data atomically, as per example I've added here:</div>
<div><br></div><div><a href="https://github.com/dougbinks/openal-soft/commit/6ede7493ef42eb355f52436aee8ca99cf51153f3">https://github.com/dougbinks/openal-soft/commit/6ede7493ef42eb355f52436aee8ca99cf51153f3</a></div><div>
<br></div><div>The extension add three source enums, only the first two of which work as yet:</div><div><br></div><div><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51)">
AL_SAMPLE_OFFSET_DEVICE_CLOCK_SOFT, AL_SAMPLE_OFFSET_LATENCY_DEVICE_CLOCK_SOFT and AL_PLAY_ON_DEVICE_CLOCK_SOFT.</pre><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51)">
<br></pre><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51)"><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px">
AL_SAMPLE_OFFSET_DEVICE_CLOCK_SOFT returns source offset, output sample count, output frequency, and output update size.</pre><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px">
<br></pre><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px"><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px">
AL_SAMPLE_OFFSET_LATENCY_DEVICE_CLOCK_SOFT returns source offset in 32.32 format as per AL_SAMPLE_OFFSET_LATENCY along with latency, output sample count, output frequency and output update size.</pre><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px">
<br></pre><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px">These should be sufficient for deciding when to play a source with the new (not implemented yet) AL_PLAY_ON_DEVICE_CLOCK_SOFT timing.</pre>
<pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px"><br></pre><pre class="" style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px">
After some thought the device clock is just in output samples for now. This is sufficient for the use cases I am aware of for now, and we can add a more generally applicable clock later, but we'll likely need sub-sample timing precision if we're to support synchronization of sources with different frequencies from the output clock.</pre>
</pre></pre></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 January 2014 14:39, Doug Binks <span dir="ltr"><<a href="mailto:doug@enkisoftware.com" target="_blank">doug@enkisoftware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="HOEnZb"><div class="h5">
<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>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>

<div><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>
</div></div></blockquote></div><br></div>