OpenAL clicking during on/off switching. Tracked down problem in OpenAL source.

Originator:vaillant
Number:rdar://6388390 Date Originated:11/20/08
Status:open Resolved:
Product:iphone sdk Product Version:2.1
Classification:serious bug Reproducible:always
 
Summary: When modulating a signal on and off with alSourcePlay / alSourceStop (or alSourcePause) clicking is clearly audible.   I have checked out the OpenAL source code from the OpenAL svn repository and tracked down the problem to the OALSource::RampUp() method (see details below on a proposal to fix the problem).
This is a general issue for both OS X desktop and iphone sdk, but since I can't compile the OpenAL framework for the iphone, I can't fix it myself.

Steps to Reproduce:  I've created a simple OS X desktop program (tested in Leopard 10.4.5) that reproduces the problem.  See attached zip file clicks.zip or grab from:
http://stuff.vaillant.fastmail.fm/clicks.zip
In Terminal.app:
1.  unzip clicks.zip
2.  make
3. ./clicks

This program switches a single tone on and off every second.  Listen for the click/pops.

Expected Results: Clean on off switching with no clicking/popping sounds.

Actual Results:  Clearly audible clicking/popping. 

Notes: Tracking down the problem in the OpenAL svn source revealed the following:  OALSource::RampUp() and OALSource::RampDown() modulate the on/off switching with a linear function so that no clicking is heard when transitioning from on to off and off to on.  However, only OALSource::RampDown() is actually executed. There is a return statement in the first line of OALSource::RampUp() (line 2832 of oalSource.cpp) so this method does nothing.  As a result clicking is clearly audible when modulating from on to off.  If I comment that return statement and build the OpenAL framework, the method appears to work properly (tested in Leopard) and clicking is eliminated. 

I'm developing an iphone app which has repeating on/off switching, so audible clicking is a real problem. If there is not a good reason why that return statement is there, it should be removed/commented.   Also, the proper (as in optimal for minimizing duration of ramp as well as bandwidth) way to ramp up/down is with a 3-5ms gaussian instead of a linear function.  I'll probably submit a patch proposal at some point.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!