Re: OpenAl Start/Stop crackle/pop
Re: OpenAl Start/Stop crackle/pop
- Subject: Re: OpenAl Start/Stop crackle/pop
- From: Phil <email@hidden>
- Date: Sun, 11 Jan 2009 12:42:22 +0000
Somewhat off-topic - I can't comment on OpenAL, but in support of
Marc's 'see my example from a previous post' - for whatever reason
there are huge performance gains associated with using
AudioUnitIORemote (as opposed to aping the use of Audio Queue playback
lifted from the Audio Queue Services Programming Guide). For our
particular in-game synth on the iPhone, using the Audio Unit bought us
back around 20% of the available device CPU cycles, a huge win, and
has put our game into a '30FPS all the time' domain on a 1G Touch,
with all 16 audio channels active. And it took around 5 minutes and
one compile to implement, so if it's not too much hassle I'd recommend
trying it out, Audio Units are likely to be the right route forward on
OS X devices anyway.
On 11 Jan 2009, at 01:11, Marc Vaillant wrote:
On Sat, Jan 10, 2009 at 02:13:29PM -0800, Stefan Alder wrote:
Marc,
Thanks for your response.
I am indeed on the iPhone. I'm only aware of alSourcePlay,
alSourceStop, and
alPause and I get the clicking on all of them. If I manually ramp
the volume
up or down (by incrementing vol. from 1 to 0 and vice versa over
50ms or so
with usleep in a loop) it seems to eliminate clicking at low
switching speeds,
but because my sound switching is controlled by user events,
switching speed
can be high, and in those cases the additional latency seems to be
a problem.
It also seems that my volume ramp up/down can get out of sync with
with
operations occuring in OpenAl's thread -- does this make sense?
Yes. You'll never really get it to work right that way. Your options
for getting this to work really depend your requirements for
switching.
So for example if when you switch on, you only ever need it to start
playing at the beginning of your sound, then you can simply multiply
the
audio *data* (PCM) with a ramp up. This assumes that the problem only
occurs when switching on--as the OpenAL source code indicates. Look
for the generateTone function in my AudioUnit example for how to do
this (there's nothing AudioUnit specific about that function, the
corresponding format for the PCM data in OpenAL is
AL_FORMAT_STEREO16 ).
If you need to start playing in the middle of your sound, then you
really need to do something like what I suggest below.
Are you suggeseting dropping OpenAl entirely and using the RemoteIO
audio unit
directly? I guess I could do this, but am reluctant as I'm sure to
end up
duplicating a lot of what OpenAl already provides.
Sorry, I was a bit vague. I meant more generally to stream your
audio,
which can also be done with OpenAL. I.e. feed your audio data
continuously in small buffers. When you need to turn it off, you
simple
multiply the current portion of your signal that you are buffering
with
a ramp down. Then shut it down or just feed a zero signal until you
need to start playing again, at which time you ramp up the signal.
Buffer sizes on the iphone are about 20 - 40ms so that's the max
latency
you will have.
Take a look at the following for how to do streaming with OpenAL:
http://www.devmaster.net/articles/openal-tutorials/lesson8.php
The pain about OpenAL is that there is no feedback when a buffer is
completed playing, and no callbacks, so you need to poll to determine
the state as shown in that example.
If you don't need the 3D features of OpenAL, then doing it with
AudioUnit RemoteIO is cleaner. Again, see my example from a previous
post.
Good Luck and let me know how it goes.
Best,
Marc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden