[Openal] Music replay.

steve sjbaker1 at airmail.net
Sat Dec 16 06:46:37 PST 2006


PS: I checked out all of the branches under SVN - and ALL
copies of al_source.c have the same 2.0 limit on AL_PITCH.

steve wrote:
> I'm playing around with a MIDIfile player under Linux using
> OpenAL because I ultimately want music that I can attach
> to a 3D object - and I'm taking cues from the music to drive
> animation.  I have a MIDIfile loader and sequencer and all
> that stuff and I have a loader for the sound-fonts that
> all of the standard Linux MIDIfile players (timidity,
> wildmidi, etc) use.  I plan to release the code as
> an OpenSource library once I have it working.
> 
> So - the plan was to load each of my sound-font waveforms
> into its own alBuffer - and use alSources to play them.
> 
> The tricky part turns out to be playing notes at the
> correct frequency.
> 
> Each instrument sound in the sound font has a bunch of
> waveforms - each one appropriate to notes played at a
> specified range of frequencies - so the first step is
> to pick the sample that most closely matches the
> frequency of the note I'm trying to play - then I
> kick off an alSource with that alBuffer - adjusting
> the AL_PITCH to get the precise frequency I need:
> 
> alSourcef(handle,AL_PITCH,note_freq/sample_freq);
> 
> ...but here's the snag.  OpenAL is telling me that
> any AL_PITCH greater than 2.0 is an error!  That
> means that I can't boost the frequency by more than
> one octave...that *SUCKS*!
> 
> This makes no sense - but I've peered into the Linux
> sources and yes, indeed it clamps AL_PITCH to 2.0 and
> flags an error.
> 
> A comment in the code says this is contrary to the
> OpenAL specification...but that's not true - the
> specification says that implementations are free to
> limit the range of AL_PITCH.
> 
> So while the Linux driver is horribly limited, it
> doesn't seem to be illegal.
> 
> My questions:
> 
> 1) Is there a way to query OpenAL's AL_PITCH limits
>    so my code can at least avoid getting an error?
>    What's to say that if I get it working with pitch
>    limits of 2.0, I won't one day find a player with
>    a limit of 1.5?  If the API allows there to be a
>    limit that's allowed to be different between
>    implementations, there MUST be an alGet for it.
> 
> 2) Is there a better way to write my music player?
> 
> 3) If I do push my software to use AL_PITCH up to
>    2.0 - but not beyond - will I run into problems
>    when doppler pushes the overall frequency higher
>    than that?
> 
> 4) Is there a was I could fix the driver to increase
>    that limit?   Does anyone understand WHY there is
>    a limit - does anyone know where I should be looking
>    in the sources to fix it.  If I simply remove the
>    clamp (and another one in al_filter.c), the sound
>    plays OK up to an AL_PITCH of maybe 3.0 - but higher
>    than that I get some nasty replay artifacts that
>    suggest there is an aliasing problem.
> 
> 5) In desperation, I tried lying to OpenAL about the
>    sampling rate of the alBuffer (eg doubling the
>    true number) so that I could reduce the AL_PITCH
>    settings proportionately.  This works to some
>    extent - but there seems to be some kind of limit
>    on the maximum value for the alBuffer's sampling
>    rate - and beyond that some very strange symptoms
>    start cropping up.  Is there some kind of hidden
>    upper limit to the alBuffer sample frequency?
> 
> This is very frustrating!
> _______________________________________________
> Openal mailing list
> Openal at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal
> 
> 



More information about the Openal mailing list