openal soft loopback query

[Michael Zucchi]

Hi there,

I was playing with the experimental openal loopback stuff in openal-soft
HEAD but came across a problem: if I drain the output too fast, the
input wont keep up and I get sections of blank space in the output. I'm
obviously trying to drain as fast as possible, but not too fast (the
output is going to a file or codec).

Is there any suggested way to approach this or some intention to provide
the needed capability?

I presume the obvious one would be to poll and wait on AL_BUFFERS_QUEUED

0, but then one would need to do this on all active sources (which

probably wouldn't be too onerous a task in my scenario). Otherwise I
presume i'd need to track this all externally somehow taking into
account sample rates and so on?

FWIW I'm not doing this for anything in particular at the moment, i'm
just experimenting.

Cheers,
Michael Z

[Chris Robinson]

Post by Michael Zucchi
Hi there,
I was playing with the experimental openal loopback stuff in openal-soft
HEAD but came across a problem: if I drain the output too fast, the
input wont keep up and I get sections of blank space in the output. I'm
obviously trying to drain as fast as possible, but not too fast (the
output is going to a file or codec).
Is there any suggested way to approach this or some intention to provide
the needed capability?

Hi.

The idea with the loopback device is that the device would be processed at a
rate similar to everything else. That is, the faster you render samples, the
faster you check and update your sources and everything. Working synchronously
would be simplest, so for example you'd do:

while(AppRuns)
{
CheckAndUpdateSources();

alcRenderSamplesSOFT(device, outbuffer, samples);
HandleOutput(outbuffer, samples);
}

As long as you don't render too many samples at once, or have short buffer
queues, this should keep up just fine and get everything out ASAP.

If you were to render samples asynchronously, then you would need to
artificially limit how fast it renders samples so the main app (what's calling
"CheckAndUpdateSources") can keep up. In such a case, the main app could
probably use a semaphore or something to tell the async thread when it's okay
to render. For example:

Thread 1:
while(AppRuns)
{
CheckAndUpdateSources();
sem_post(&RenderNow);
}

Thread 2:
while(AppRuns)
{
alcRenderSamplesSOFT(device, outbuffer, samples);
HandleOutput(outbuffer, samples);
sem_wait(&RenderNow);
}


Hope that helps. :) If you have more questions, feel free to ask.

[Michael Zucchi]

Hi Chris,

Post by Chris Robinson
Hi.
The idea with the loopback device is that the device would be processed at a
rate similar to everything else. That is, the faster you render samples, the
faster you check and update your sources and everything. Working synchronously

...

Post by Chris Robinson
As long as you don't render too many samples at once, or have short buffer
queues, this should keep up just fine and get everything out ASAP.
If you were to render samples asynchronously, then you would need to
artificially limit how fast it renders samples so the main app (what's calling
"CheckAndUpdateSources") can keep up. In such a case, the main app could
probably use a semaphore or something to tell the async thread when it's okay

Hmm, yes I had more of a think about this last night, and I was thinking
of all sorts of horrible asynchronous stuff: but I just realised my code
is all synchronous and pull-based, so there's no reason to get so
complicated. Even if I want to do threaded rendering of the source
material I can put that behind a synchronous interface easily.

Thanks for the ideas.

Cheers,
Michael