[Openal] Queuing multiple buffers with changing frequency to one source

[Jörn Koch]

[ 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 
there.
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 
specification curiosity."

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?

Thanks!

With best regards
Jörn Koch