« Return to Thread: Sound stuttering for small buffer sizes in hardware OpenAL implementation for Audigy SE

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

by Daniel PEACOCK :: Rate this Message:

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

« Return to Thread: Sound stuttering for small buffer sizes in hardware OpenAL implementation for Audigy SE