Sound stuttering for small buffer sizes in hardware OpenAL implementation for Audigy SE

[Thilo Schulz]

Hello,

I have a user who uses the "Sound Blaster Audigy SE".. when he uses one of the
two upper native devices:

Lautsprecher (SB Audigy)
Digitale Audioschnittstelle (SB Audigy)
Generic Software

the background music playing in the game stutters. Generic Software plays
fine.

There are 4 buffers which are queued, unqueued, refilled with data and
requeued, and always chunks of 4096bytes of 44khz sampled 16 bit pcm stereo
data are fed to each buffer. The buffers should be refilled right on time,
there is always enough data available, there is only one or two buffers
consumed after each frame so all should be fine. Still, the sound stutters.
It seems to me as though the hardware OpenAL device would not be able to
correctly switch in time to the next queued buffer if each buffer is only
4096 bytes large (meaning 1024 samples). Doubling the buffer size to 8192
gets rid of the problem.

Now I am left wondering: why does it work on Generic Software but not
Hardware? What would be a good buffer size to use to make sure that it works
on all hardware?

--
Thilo Schulz


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

[Tom Keresztes]

Hi,
 
   Generally this is a result of the cpu not updating the buffers in
time, probably the cpu load is too high and the sound update does not
run often enough (i have a sound updates in a secondary thread which
updates at 25 per sec / iPhone, and while cpu is capable of doing the
mixing the flash is not fast enough to read enough data on time - while
streaming vorbis audio). Running the sound thread as realtime was
unnecessary.
   Also, please note that Audigy SE is not a true Audigy, as it lacks
hardware mixing (though not sure it is the lack of hardware accelerated
3d audio or hw acceleration in general) which might make the issue more
audible. You can verify this when you query the the number of processed
buffers, if it is larger than one, you definitely need to increase the
frequency of updates (and guarantee that they happen).

Thats my 5 cents,
   Tom K.

Thilo Schulz wrote:

> Hello,
>
> I have a user who uses the "Sound Blaster Audigy SE".. when he uses one of the
> two upper native devices:
>
> Lautsprecher (SB Audigy)
> Digitale Audioschnittstelle (SB Audigy)
> Generic Software
>
> the background music playing in the game stutters. Generic Software plays
> fine.
>
> There are 4 buffers which are queued, unqueued, refilled with data and
> requeued, and always chunks of 4096bytes of 44khz sampled 16 bit pcm stereo
> data are fed to each buffer. The buffers should be refilled right on time,
> there is always enough data available, there is only one or two buffers
> consumed after each frame so all should be fine. Still, the sound stutters.
> It seems to me as though the hardware OpenAL device would not be able to
> correctly switch in time to the next queued buffer if each buffer is only
> 4096 bytes large (meaning 1024 samples). Doubling the buffer size to 8192
> gets rid of the problem.
>
> Now I am left wondering: why does it work on Generic Software but not
> Hardware? What would be a good buffer size to use to make sure that it works
> on all hardware?
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openal mailing list
> Openal@...
> http://opensource.creative.com/mailman/listinfo/openal
>  

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

[Thilo Schulz]

On Monday 25 May 2009, Tom Keresztes wrote:
>    Generally this is a result of the cpu not updating the buffers in
> time, probably the cpu load is too high and the sound update does not
> run often enough (i have a sound updates in a secondary thread which
> updates at 25 per sec / iPhone, and while cpu is capable of doing the
> mixing the flash is not fast enough to read enough data on time - while
> streaming vorbis audio). Running the sound thread as realtime was
> unnecessary.

His framerate was at 125, so there were 125 updates per second.

>    Also, please note that Audigy SE is not a true Audigy, as it lacks
> hardware mixing (though not sure it is the lack of hardware accelerated
> 3d audio or hw acceleration in general) which might make the issue more
> audible. You can verify this when you query the the number of processed
> buffers, if it is larger than one, you definitely need to increase the
> frequency of updates (and guarantee that they happen).

The number of processed buffers was never larger than 1, and there are four
filled audio buffers. This also doesn't explain why it would work on Generic
Software, but not the hardware device.

--
Thilo Schulz


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

[Daniel PEACOCK]

I think using 4 Buffers of 1024 samples played back at 44.1KHz should be
perfectly reasonable for streaming as it gives you just under 100
milliseconds of queued data to cope with any unexpected CPU spikes.  I
would expect it to work with any of Creative's native AL devices.
Unfortunately that doesn't appear to be the case for the Audigy SE card.
I'll have to look into that and see what the problem is.

If you are simply streaming a large audio file for your background music
(rather than creating an interactive music system) then it might be worth
doubling the size of each buffer to 2048 samples as the only downside is
the extra memory overhead (and possibly decode time if your music is
compressed - although that could be done in two steps to spread the load ).

Dan
Creative Labs (UK) Ltd.

Notice
The information in this message is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to this
message by anyone else is unauthorized.  If you are not the intended
recipient,  any disclosure,  copying or distribution of the message,  or
any action taken by you in reliance on it,  is prohibited and may be
unlawful.  If you have received this message in error,  please delete it
and contact the sender immediately.  Thank you.

Creative Labs UK Ltd company number 2658256 registered in England and Wales
at Belmont Road, Belmont Place, Maidenhead, Berkshire, SL6 6TB



                                                                           
             Thilo Schulz                                                  
             <arny@...                                            
             .de>                                                       To
             Sent by:                  openal@...      
             openal-bounces@op                                          cc
             ensource.creative                                            
             .com                                                  Subject
                                       Re: [Openal] Sound stuttering for  
                                       small buffer sizes in hardware      
             05/25/2009 03:24          OpenAL      implementation for      
             PM                        Audigy SE                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




On Monday 25 May 2009, Tom Keresztes wrote:
>    Generally this is a result of the cpu not updating the buffers in
> time, probably the cpu load is too high and the sound update does not
> run often enough (i have a sound updates in a secondary thread which
> updates at 25 per sec / iPhone, and while cpu is capable of doing the
> mixing the flash is not fast enough to read enough data on time - while
> streaming vorbis audio). Running the sound thread as realtime was
> unnecessary.

His framerate was at 125, so there were 125 updates per second.

>    Also, please note that Audigy SE is not a true Audigy, as it lacks
> hardware mixing (though not sure it is the lack of hardware accelerated
> 3d audio or hw acceleration in general) which might make the issue more
> audible. You can verify this when you query the the number of processed
> buffers, if it is larger than one, you definitely need to increase the
> frequency of updates (and guarantee that they happen).

The number of processed buffers was never larger than 1, and there are four

filled audio buffers. This also doesn't explain why it would work on
Generic
Software, but not the hardware device.

--
Thilo Schulz
[attachment "signature.asc" deleted by Daniel PEACOCK/UK/CLE/Creative]
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

ForwardSourceID:NT0006C7BE

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