[Openal] Queuing multiple buffers with changing frequency to
joern at ca3d-engine.de
Thu Apr 24 10:59:29 PDT 2008
[ This reply went accidently only to Jason, here is a copy for the list
-- sorry. ]
Jason Daly schrieb:
> "All buffers in a queue must have the same format and attributes."
> That's pretty clear. Buffer attributes include frequency, bits,
> channels, and size (although I think most implementations _are_ tolerant
> of varying sizes).
Ah thanks, I didn't find this line in the OpenAL Programmer's Guide PDF
and was referring to "2) All buffers attached to a source using
alSourceQueueBuffers should have the same audio format." on page 14.
> Feel free to try it out. Some implementations might not care (software
> implementations in particular), but I wouldn't expect every
> implementation to work. This is the kind of thing that hardware hates,
> for example.
> What exactly are you trying to do in your application? There might be a
> way around the problem.
I have implemented support for MP3 and OggVorbis streams using MPG123
lib for MP3 support and the OggVorbis implementation of xiph.org.
MPG123 allows to fix the output format of the PCM data including the
number of channels and the sample rate for an MP3 stream so no problems
On the OggVorbis side there is the possibility that a OggVorbis file
contains multiple vorbis streams and their number of channels and sample
rate may change:
"multiple stream links
A Vorbis stream may consist of multiple sections (called links) that
encode differing numbers of channels or sample rates. It is vitally
important to pay attention to the link numbers returned by ov_read and
handle audio changes that may occur at link boundaries. Such
multi-section files do exist in the wild and are not merely a
I haven't found a file with multiple bitstreams and changing frequency
yet and I guess they are quite rare.
Do you see any need to support such files in an application where users
may provide their own OggVorbis files for music playback or is the
overhead for supporting these files (if in some way possible with
OpenAL) not worth the effort?
With best regards
More information about the Openal