[openal] Synchronizing 3D sources

[Doug Binks]

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.

Feedback sounds good, some further comments on this below.

* 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.

* 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.

* 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.

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.


On 27 January 2014 19:43, Chris Robinson <chris.kcat at gmail.com> wrote:

> On 01/27/2014 09:24 AM, Doug Binks wrote:
>
>> AL_SAMPLE_OFFSET_DEVICE_CLOCK_SOFT returns source offset, output
>> sample count, output frequency, and output update size.
>>
> >
> > 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.
>
> 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.
>
>
>  These should be sufficient for deciding when to play a source with the
>> new (not implemented yet) AL_PLAY_ON_DEVICE_CLOCK_SOFT timing.
>>
>
> I think functions would be better than a property.
>
> void alSourcePlayTimeSOFT(ALuint64SOFT time, ALuint id);
> void alSourcePlayTimevSOFT(ALuint64SOFT time, ALsizei count,
>                            const ALuint *ids);
>
> 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.
>
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20140127/640e6999/attachment.html>