OpenAL Soft performance question

[Troy Yee]

I have an application using OpenAL Soft 1.8.466 + commits to 2009-07-03.  Things work fine at startup but after some long period of time (5 + hours), audio playback practically stops - a request to play a source takes several seconds before any change in sound is observed and then things are *very* choppy - same buffers seem to get replayed even.  The application is running on SuSE Linux Enterprise 10.1 with ALSA backend.  The issue could be related to the application but there has been some evidence to suggest that it may be a problem with OpenAL.

I've noticed some ALSA related changes in the GIT repository.  Could any of the findings that resulted in those changes explain the observed behaviour? (Perhaps even the recent change regarding the thread stop condition?)

Troy.

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Subi]

> I have an application using OpenAL Soft 1.8.466 + commits to 2009-07-03.
> Things work fine at startup but after some long period of time (5 +
> hours),
> audio playback practically stops (snip)

That sounds very familier to a problem I had back in April.  I was using
OpenAL on Gentoo, and while the OSS Software driver worked fine, the ALSA
driver behaved as you describe.

Unfortunately I can't help much, because I never got around the problem,
and no-one on the Gentoo forums could help.  In the end, I had our app
use the OSS Software driver, as that was enough for our purposes (we
do all the processing internally).

(This is actually the problem I joined this list for, but I never got
around to asking the question! ;)

- Sam Brown

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

On Tuesday 06 October 2009 10:56:56 am Troy Yee wrote:
> I have an application using OpenAL Soft 1.8.466 + commits to 2009-07-03.
>  Things work fine at startup but after some long period of time (5 +
>  hours), audio playback practically stops - a request to play a source
>  takes several seconds before any change in sound is observed and then
>  things are *very* choppy - same buffers seem to get replayed even.  The
>  application is running on SuSE Linux Enterprise 10.1 with ALSA backend.
>  The issue could be related to the application but there has been some
>  evidence to suggest that it may be a problem with OpenAL.

Does it always happen after the same length of time, or is it just more likely
to happen the longer playback runs? OpenAL itself shouldn't have any issues
with prolonged playback, barring obscure bugs. It doesn't keep a counter for
total play length, or explicitly track time, or anything.. it just processes
however many samples the audio backend says to, when it says to. If there's a
problem with the lib the backend uses, that can cause issues, though.

When using ALSA, you can try disabling mmap by adding this to ~/.alsoftrc:

[alsa]
mmap = off

That should make it update the sound card in a manner similar to the OSS
backend. If that fixes it, then ALSA may have problems using mmap for long
periods of time. If it doesn't, there may be a problem deeper in ALSA.
PulseAudio's plugin for ALSA in particular has issues with mmap, if you have
that installed.

> I've noticed some ALSA related changes in the GIT repository.  Could any of
>  the findings that resulted in those changes explain the observed
>  behaviour? (Perhaps even the recent change regarding the thread stop
>  condition?)

No, that was a fix for a bug that crept in from a commit just after 1.9's
release, so that it would properly stop playback when the context was being
destroyed.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Troy Yee]

Thanks for the response Chris.

The problem seems to be time related.  It can happen when very few
sounds ever get played.  The application could potentially have the
sound devices open for that period of time with very little activity.

There doesn't seem to be a gradual degradation - one second things are
fine and the next nothing is playing (correctly).  An interesting thing
is that if the application process is suspended and then resumed,
everything starts working again.

I'm not using PulseAudio, just ALSA.

As I noted, I haven't ruled out the application being at fault.  We
seemed to have the same issue with a fairly simple test app so that is
why I posted the question.  It just takes a long time to verify it has
the same behaviour.

I'll investigate some of the things you mention.  I started a test last
night with GIT from 2009/09/27 and will see what things are like this
morning.

Troy.



_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Subi]

> As I noted, I haven't ruled out the application being at fault.  We
> seemed to have the same issue with a fairly simple test app so that is
> why I posted the question.  It just takes a long time to verify it has
> the same behaviour.

If it helps, I did something similar:  I set an app that played two
sounds simultaneously.  One was a ten second sample that looped that
was stopped and restarted after a random period of time (between 5
and 20 seconds), and one short (about half a second) that retriggered
when the previous instance of it had finished.  The app did nothing
else, although it was using OpenGL to display information.

After about 6 hours, regardless of the amount of sounds played, the
audio started corrupting, usually in the form of long periods of
silence with the occasional burst of the samples.

OpenAL wasn't returning any errors on any actions, even after the
corruption had started.  It seemed to think that the sounds had either
stopped immediately, or not stopped at all.

This was on a _very_ basic build of Gentoo, running inside a bare
X server.

Cheers,

- Sam Brown


_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Jason Daly]

Sam Brown wrote:

> If it helps, I did something similar:  I set an app that played two
> sounds simultaneously.  One was a ten second sample that looped that
> was stopped and restarted after a random period of time (between 5
> and 20 seconds), and one short (about half a second) that retriggered
> when the previous instance of it had finished.  The app did nothing
> else, although it was using OpenGL to display information.
>
> After about 6 hours, regardless of the amount of sounds played, the
> audio started corrupting, usually in the form of long periods of
> silence with the occasional burst of the samples.
>
> OpenAL wasn't returning any errors on any actions, even after the
> corruption had started.  It seemed to think that the sounds had either
> stopped immediately, or not stopped at all.
>
> This was on a _very_ basic build of Gentoo, running inside a bare
> X server.
>  

Not sure if this means anything or not, but...

6 (hours) * 3600 (sec/hour) * 48000 (samples/sec) * 2 (channels) =
2073600000

which is fairly close to 2^31 or the max for a signed 32-bit integer.  
Could there be an overflow happening somewhere?

--"J"

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

On Wednesday 07 October 2009 7:56:02 am Jason Daly wrote:
> Not sure if this means anything or not, but...
>
> 6 (hours) * 3600 (sec/hour) * 48000 (samples/sec) * 2 (channels) =
> 2073600000
>
> which is fairly close to 2^31 or the max for a signed 32-bit integer.
> Could there be an overflow happening somewhere?

And 2073600000 * 2 (bytes/sample) = 4147200000  which is pretty close to the
unsigned 32-bit int max. Interesting possibility. There's nothing in OpenAL
Soft's mixer or its ALSA backend that would have this problem, though. If I
had to guess, perhaps ALSA overflows an internal count of the total number of
bytes written, and starts believing there's no available space to write to.
That causes the device to underrun, which it takes a moment to realize, then
OpenAL Soft refills the buffer and restarts playback. The internals counters,
though, aren't reset so it keeps thinking no space is freeing up, and does it
again.

That's pure conjecture, though. I don't really see why ALSA would keep track
of the total written bytes any more than OpenAL would. Or that, even if it
does, it couldn't handle an inevitable overflow or use a 64-bit integer on
capable systems.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

On Wednesday 07 October 2009 6:44:20 am Troy Yee wrote:
> Thanks for the response Chris.
>
> The problem seems to be time related.  It can happen when very few
> sounds ever get played.  The application could potentially have the
> sound devices open for that period of time with very little activity.

Out of curiosity, are you using dmix or direct hardware? It looks
conspicuously like a problem with the total number of bytes written to the
device through ALSA causing an overflow, in which case it doesn't matter what,
if anything, is actually played with OpenAL. It keeps sending samples to the
device anyway.

Just to be sure, there are no messages printed to the console by OpenAL when
the problem occurs?
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Troy Yee]

The app uses dmix primarily (occasionally something will go to a specific hardware device).  Haven't seen any output at console and nothing is getting triggered by error return codes.

If I use aplay to play a sound when the app is in this state, the sound plays fine.  Would it make sense that the app would start working correctly after resuming from suspended state (Ctl-Z in console followed by fg) if it were an overflow issue?

Troy.

----- Original Message -----
From: Chris Robinson <chris.kcat@...>
Date: Wednesday, October 7, 2009 9:44
Subject: Re: [Openal] Re: OpenAL Soft performance question
To: openal@...

> On Wednesday 07 October 2009 6:44:20 am Troy Yee wrote:
> > Thanks for the response Chris.
> >
> > The problem seems to be time related.  It can happen when
> very few
> > sounds ever get played.  The application could
> potentially have the
> > sound devices open for that period of time with very little
> activity.
> Out of curiosity, are you using dmix or direct hardware? It
> looks
> conspicuously like a problem with the total number of bytes
> written to the
> device through ALSA causing an overflow, in which case it
> doesn't matter what,
> if anything, is actually played with OpenAL. It keeps sending
> samples to the
> device anyway.
>
> Just to be sure, there are no messages printed to the console by
> OpenAL when
> the problem occurs?
> _______________________________________________
> Openal mailing list
> Openal@...
> http://opensource.creative.com/mailman/listinfo/openal
>

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Troy Yee]

My attempts with 1.9.563 and with ~/.alsoftrc setting [alsa] mmap = off both produced same problem.  Is there a way I can be certain that the mmap = off option did what is expected?

I'm currently trying to reproduce the problem with just ALSA in the loop.

Troy.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

On Thursday 08 October 2009 9:36:19 am Troy Yee wrote:
> My attempts with 1.9.563 and with ~/.alsoftrc setting [alsa] mmap = off
>  both produced same problem.  Is there a way I can be certain that the mmap
>  = off option did what is expected?

Modify the source, and add an AL_PRINT() statement to the start of
ALSANoMMapProc, before the while() loop. If you do that, it may also be a good
idea to add a counter, using a uint64_t. eg..

uint64_t myin64val = 0;
...
aluMixData(...);
myin64val += data->size;
AL_PRINT("Current val: 0x%llx\n", myint64val);

and see what the value is when it starts giving problems. If it's very close
to 80000000 or 100000000, then it very likely is an overflow problem
somewhere.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Troy Yee]

Thanks Chris.

I did this and don't see anything being printed.  I confirmed that my .alsoftrc is being read by changing some other settings and observing that they take effect.  Is there a reason why mmap stuff wouldn't be acted upon?  (I haven't looked yet but will after I send this).

Troy.

----- Original Message -----
From: Chris Robinson <chris.kcat@...>
Date: Thursday, October 8, 2009 10:18
Subject: Re: [Openal] Re: OpenAL Soft performance question
To: openal@...

> On Thursday 08 October 2009 9:36:19 am Troy Yee wrote:
> > My attempts with 1.9.563 and with ~/.alsoftrc setting [alsa]
> mmap = off
> >  both produced same problem.  Is there a way I can
> be certain that the mmap
> >  = off option did what is expected?
>
> Modify the source, and add an AL_PRINT() statement to the start
> of
> ALSANoMMapProc, before the while() loop. If you do that, it may
> also be a good
> idea to add a counter, using a uint64_t. eg..
>
> uint64_t myin64val = 0;
> ...
> aluMixData(...);
> myin64val += data->size;
> AL_PRINT("Current val: 0x%llx\n", myint64val);
>
> and see what the value is when it starts giving problems. If
> it's very close
> to 80000000 or 100000000, then it very likely is an overflow
> problem
> somewhere.
> _______________________________________________
> Openal mailing list
> Openal@...
> http://opensource.creative.com/mailman/listinfo/openal
>

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

On Thursday 08 October 2009 5:36:50 pm Troy Yee wrote:
> Thanks Chris.
>
> I did this and don't see anything being printed.  I confirmed that my
>  .alsoftrc is being read by changing some other settings and observing that
>  they take effect.  Is there a reason why mmap stuff wouldn't be acted
>  upon?  (I haven't looked yet but will after I send this).

I could only guess, if the .alsoftrc isn't properly formatted it may be
ignoring the setting. Or perhaps the modified lib isn't being used.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal