<div dir="ltr"><div>I've updated the code to add playback. This should help understand the use cases a bit more. In the example I playback two square waves of the same frequency, timing the second wave to cancel the first without clicks. The main use case is for rhythm-action style synchronization of spatial sources with music.</div>
<div><br></div><div>Feedback sounds good, some further comments on this below.</div><div><br></div>* Output frequency - indeed I think this could disappear from the return as it's relatively non volatile. However I'd like to leave the option to get samples rather than time as it makes the code easier to use. Adding a get time rather than samples as per latency makes sense though for some cases.<div>
<br></div><div>* Output Sample Count - yes, now I realise this is non-volatile I'll remove it, and move it to a alcGetIntegerv if it's not already.</div><div><br></div><div>* Play functions - these make sense, I used a parameter for now as it made it easier to write the prototype. It may still be necessary to have a get for this, as otherwise the 'length' of the sample makes no sense if developers are writing code which keeps all state in OpenAL.</div>
<div><br></div><div>Please be as mean as you can with the code, even though it's just a prototype to show this can work. Meanwhile I'll look into the proposed changes and clean up the example a bit. I'm trying to stay away from using SDL for now to reduce dependencies with the example I wrote hence the slight repeat of code.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 January 2014 19:43, 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/27/2014 09:24 AM, Doug Binks wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AL_SAMPLE_OFFSET_DEVICE_CLOCK_<u></u>SOFT returns source offset, output<br>
sample count, output frequency, and output update size.<br>
</blockquote>
><br>
> AL_SAMPLE_OFFSET_LATENCY_<u></u>DEVICE_CLOCK_SOFT returns source offset in<br>
> 32.32 format as per AL_SAMPLE_OFFSET_LATENCY along with latency,<br>
> output sample count, output frequency and output update size.<br>
<br></div>
It shouldn't be necessary to return the output frequency here. Returning the output sample count and output update size as a micro- or nanosecond time value removes the need for it. It also makes more sense for the update time to be a separate device-level (alcGetIntegerv) query... it's a relatively non-volatile value that doesn't need to be retrieved with the others, as it can only change during alcCreateContext.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
These should be sufficient for deciding when to play a source with the<br>
new (not implemented yet) AL_PLAY_ON_DEVICE_CLOCK_SOFT timing.<br>
</blockquote>
<br></div>
I think functions would be better than a property.<br>
<br>
void alSourcePlayTimeSOFT(<u></u>ALuint64SOFT time, ALuint id);<br>
void alSourcePlayTimevSOFT(<u></u>ALuint64SOFT time, ALsizei count,<br>
                           const ALuint *ids);<br>
<br>
This makes more sense to me, for the same reason you'd use alSourcePlay instead of setting the AL_SOURCE_STATE property to AL_PLAYING.<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>