[openal] Synchronizing 3D sources

[Doug Binks]

The latest code at
https://github.com/dougbinks/openal-soft/commits/Device_Clock moves to a
nanosecond based clock as requested. I did add an error accumulator to
reduce drift, but this can be removed if we don't need sample accuracy over
long periods.

The changes now cope with aligning sources with different frequencies than
the device.

In order for a developer to correctly align sources, they need the actual
frequency of the source. I have thus added an alcGetDoublevSOFTX function
which can be used (as in the example program) to convert a frequency into
the actual frequency as resampled into the output. This seemed a better
approach than exposing the interval computations.

If you think this is looking like something you'd be interested in
including, I can do any further changes needed along with a spec and some
documentation.




On 31 January 2014 11:12, Doug Binks <doug at enkisoftware.com> wrote:

> It makes a lot of sense not to encumber the library with any features
> which would prevent forward progress on other more important aspects.
>
> I'll see if I can get some feedback on whether 'almost' sample
> accurate would do.
>
> The square wave test isn't something I think can be made to
> generically work in all circumstances, but it's certainly one which
> shows any errors up well.
>
> On 31 January 2014 02:18, Chris Robinson <chris.kcat at gmail.com> wrote:
> > On 01/30/2014 11:01 AM, Doug Binks wrote:
> >>
> >> The problem is that even with nanosecond precision, the drift will
> >> equal one sample after a few hundred seconds.
> >>
> >> The important objective I (and the other use case I'm aware of) is
> >> trying to achieve is to get per-sample synchronization with two or
> >> more samples being played. We don't care (in this context) about the
> >> absolute timing, so drift of any backend or hardware doesn't matter to
> >> us so long as the mixing is accurate to the sample level.
> >
> >
> > I'm not sure sample-perfect timing should be a reliable feature. The
> problem
> > is when the audio clock isn't directly derived from the number of
> processed
> > samples, but rather, the number of samples processed is derived from the
> > audio clock. Or if the returned clock time and source offsets are
> > interpolated in some way.
> >
> > Granted this isn't much of an issue for OpenAL Soft right now since the
> > clock would be based on the number of samples and not be interpolated.
> But
> > I'm not sure if that will always be the case, or if other implementations
> > might want to do it differently. I actually have some pretty ambitious
> (if
> > long-term) plans for the mixer that would decouple it from property
> > processing, making it completely lockless and perhaps getting really low
> > latencies, which would require rethinking how timing works. Though even
> if
> > it doesn't go that far, the way timing works could still change to give
> > better granularity than the 20+ms it currently has.
> >
> > So all said, I'm not sure your example of being able to play one square
> > wave, then time-start another square wave so that they perfectly cancel
> out,
> > would be able to reliably work.
> >
> >
> > Though if anyone else wants to weigh in on the issue, please do. Right
> now
> > I'm mainly working with hypotheticals, trying to avoid making guarantees
> > that could prevent future internal improvements.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20140131/298c9fd8/attachment.html>