Re: How to avoid sonic boom when changing pitch?
Re: How to avoid sonic boom when changing pitch?
- Subject: Re: How to avoid sonic boom when changing pitch?
- From: Zack Morris <email@hidden>
- Date: Mon, 04 Jul 2011 08:35:55 -0600
On Jul 2, 2011, at 3:52 AM, Paul Davis wrote:
> On Sat, Jul 2, 2011 at 1:23 AM, Einstin <email@hidden> wrote:
>> Hello,
>>
>> I use openAL to play shot sound (.wav), but it sounds boom once I change
>> the PITCH.
>>
>> e.g.
>>
>> alSourcef(sourceID, AL_PITCH,1.5)
>> alSourcePlay(sourceID);
>>
>>
>> But if setting the AL_PITCH value to 1.0 will be very OK. What should I do
>> for solve it ?
>
> its a bug in openAL (at least the open source version of openAL). a
> very, very stupid bug. i know of at least one developer who uses
> openAL whose uses something like 1.0000001 as his "normal" speed and
> then all speed changes get properly interpolated. but the open source
> version will definitely click if you change from 1.0 to any other
> speed. i don't know if this bug affects the apple version - they did
> make a few changes here and there.
>
> personally, i wouldn't use openAL if you paid me, but that's another story.
Ya I agree that OpenAL definitely has a lot of problems, because it seems to be written in an "older" style which is more about devices and drivers than more modern ways of doing things with queues and filters (audio units and the like). I had a similar issue when changing amplitude, because Apple's implementation has some kind of enveloping that happens (probably to prevent pops) where the amplitude changes over a period of time:
http://lists.apple.com/archives/coreaudio-api/2010/Nov/msg00135.html
I later discovered alcSuspendContext() for executing a bunch of state changes while OpenAL is suspended and then resuming so they happen all at once, but haven't tried it yet, since I had just learned to live with the suckiness:
http://old.nabble.com/Do-any-implementations-support-alcSuspendContext-correctly--td24618125.html
I think that probably someone needs to sit down and do a fresh rewrite of OpenAL, since it doesn't do anything terribly intensive by today's standards. I find it amazing that just getting a simple pointer to the hardware's double buffer is so complicated. We had this huge library at one time that did it under Carbon/Cocoa with layer after layer of workaround functions since Apple kept deprecating everything we used in the Sound Manager, so we could run our own MOD style player, and ended up just ditching it when we tried OpenAL. It was a real bummer when we started finding so many bugs in the implementation.
OpenAL's big mistake seems to be that it doesn't have enough encapsulation. It's like we are being forced to work at the TCP level when we really want UDP. OK maybe that's a bad analogy, since the layer I need just below TCP doesn't actually exist (to send packets with optional guaranteed delivery and ordering). OpenAL should probably be broken up into at least two layers: one that simply exposes a queuing system to get/send buffers to the input and output hardware (with methods to check the offset and timestamp of the sample currently being recorded/rendered, ideally with a pure syntax like unix file streams), and another layer that builds point sources on top of that, in a completely freeform/accessible/open way. In fact, let's just the low level a single call that takes pointers to both the input and output bytes at the same time so we have exact synchronization and can do things like echo cancellation. Then the abstract mixing could happen in regular source files with simple loops that we could include in our projects.
For instance, I need to be able to have a callback filter on each source, so I can do things like reverberations on the samples before finally handing them off to OpenAL. Right now we are pre-rendering copies of our sounds with FX applied, so that we can just play a sound echoed or whatever (like textures - best to leave them on the card). The OpenAL extensions for reverberations are rarely implemented and have no future as they stand now.
P.S. Just out of curiosity, does anyone have code to set up the OpenAL environment with exact dimensions? I have an OpenGL context where everything is in meters, so I'm say half a meter from the screen, and I want the world to be to scale, and for the life of me I just can't find any examples for the parameters to set it up properly. The one thing that OpenAL was designed to do is not documented. I sure see that way too often these days (for most libs, it's all I can see anymore, maybe I'm getting too old for this stuff, although with open source, you often get what you pay for, so something for nothing is better than the nothing for nothing we had in the early 90s before the internet hahah).
P.P.S. I'll do the full rewrite of OpenAL, I just need $50,000 to design and develop the cross platform code over 3-6 months, then 3 months of revisions and 3 months of testing/feedback. Heck that's a drop in the bucket for Apple! I sure wish development worked that way. Apple should make a Dev Store which would be the mirror image of the App Store, where customers would post solutions they need at various prices and developers would pick the most awesome ones. It would be the next-gen version of the business consulting that Microsoft built its empire on.
Thanx,
--Zack _______________________________________________
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