Custom Search
|
Date: December 31, 2006
From: "Thomas Franklin" <tfranklin914@xxxxxxxxx>
_______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 31, 2006
From: Garin Hiebert <garinh@xxxxxxxxxxxxxxx>
In-reply-to:
<61650144.20061229192558@xxxxxxxxxxxxxx>
References:
<61650144.20061229192558@xxxxxxxxxxxxxx>
Here is a part of those code:
alGetSourcei(self.source, AL_BUFFERS_PROCESSED, @processed);
while processed > 0 do begin
alSourceUnqueueBuffers(self.source, 1, @buffer); // !!! Here is an
exception!
active := self.Stream(buffer); // decoding and fill the buffer
if active then alSourceQueueBuffers(self.source, 1, @buffer);
Dec(Processed); // счётчик
отработанных
end;
This is a well-used code, which is good working at my old programs.
But today I meet a problem. What can I do to determine a source of problem?
It's suspicious that this is only happening with Ogg Vorbis data. The OpenAL library itself shouldn't care at all, since the buffer is PCM data whether or not it came from WAV or Ogg Vorbis originally. Is it possible that for the Ogg Vorbis case your code is handing over an invalid buffer ID to alSourceUnqueueBuffers? That could cause a crash, because the pointer may not be checked for validity before being used to store the unqueued buffer ID.
- To test out the above theory, perhaps you should try adding an alIsBuffer test before proceeding with the buffer unqueue process.
- Can you provide more specifics on the exception you're seeing? If you're in Windows (I assume so, since this looks like Delphi code to me...), what's coming up on the bluescreen?
- If my assumption was correct that you're on Windows, did this problem happen when moving to the new version of the OpenAL library? If not, do you know what changed between the last known working state and now?
Garin _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 29, 2006
From: admin <stargazer@xxxxxxxxxxxxxx>
Hello openal,
I'm using a latest release of OpenAL.
WAV files playng OK, and I decide to use my old Ogg Vorbis class.
Buffers are decoding and queueing OK, so I can hear beginning of a a
music. But when it try to unqueue first processed buffer, I got an
exception.
Here is a part of those code:
alGetSourcei(self.source, AL_BUFFERS_PROCESSED, @processed);
while processed > 0 do begin
alSourceUnqueueBuffers(self.source, 1, @buffer); // !!! Here is an
exception!
active := self.Stream(buffer); // decoding and fill the buffer
if active then alSourceQueueBuffers(self.source, 1, @buffer);
Dec(Processed);
// счётчик отработанных
end;
This is a well-used code, which is good working at my old programs.
But today I meet a problem. What can I do to determine a source of problem?
Thanks for advance!
--
Best regards,
Ivan Kuzmitsky mailto:stargazer@xxxxxxxxxxxxxx
_______________________________________________
Openal mailing list
Openal@xxxxxxxxxxxxxxxxxxxxxxx
http://opensource.creative.com/mailman/listinfo/openal
Date: December 29, 2006
From: Jason Daly <jdaly@xxxxxxxxxxx>
In-reply-to:
<2ceb68a80612282118ve9a1970h283dd945bf9ba770@xxxxxxxxxxxxxx>
References:
<904e76320612281244j248e4b0er3f3fbe776230b076@xxxxxxxxxxxxxx> <1673074550.20061228212447@xxxxxxxxxx> <2ceb68a80612282118ve9a1970h283dd945bf9ba770@xxxxxxxxxxxxxx>
Zach Miller wrote:
Newbie here as well..What sort of frequency/timing reliability is needed for "pushing" continuous 44100/16/2 data?Every millisecond? Second? 10 seconds?
It depends on how big you make your buffers. You'll end up making a tradeoff between latency and buffer queueing frequency. If you use a half-second buffer (88,200 bytes in your case). You'll have at least a half second of latency (the time from when you queue your audio on the source, and when you hear it), but you'll only have to update your source about every half second (usually a bit more often to be safe). If you want less latency, you can use a smaller buffer and update your source with new data more often.
This assumes you're constantly streaming data to OpenAL. If all you do is play static buffers, then timing isn't really a problem.
My code typically uses a worker thread that runs at 20 Hz or so to keep streaming sources happy.
--"J" _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 29, 2006
From: "Zach Miller" <betanull@xxxxxxxxx>
In-reply-to:
<1673074550.20061228212447@xxxxxxxxxx>
References:
<904e76320612281244j248e4b0er3f3fbe776230b076@xxxxxxxxxxxxxx> <1673074550.20061228212447@xxxxxxxxxx>
If what you mean is playback of music (for example), OpenAL uses a
"push" mechanism which means you have to keep feeding it with data
(through an alBufferData call), rather than a "pull" mechanism where
it would call a callback function when it wants data. Unless you can
periodically feed data to it in your main game loop... you are best
spawning a thread to do this work.
_______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 28, 2006
From: "Jeremy Falcon" <ironbird@xxxxxxxxx>
In-reply-to:
<1673074550.20061228212447@xxxxxxxxxx>
References:
<904e76320612281244j248e4b0er3f3fbe776230b076@xxxxxxxxxxxxxx> <1673074550.20061228212447@xxxxxxxxxx>
Hello Jeremy,
Thursday, December 28, 2006, 8:44:09 PM, you wrote:
> · Does OpenAL use multiple threads internally to support async playback
> or should I use a worker thread(s) in my own program to achieve this?
If what you mean is playback of music (for example), OpenAL uses a
"push" mechanism which means you have to keep feeding it with data
(through an alBufferData call), rather than a "pull" mechanism where
it would call a callback function when it wants data. Unless you can
periodically feed data to it in your main game loop... you are best
spawning a thread to do this work.
> · Is hardware support offered for other cards besides those in the
> SoundBlaster compatible family?
On Windows, yes - any card that has DirectSound3D acceleration.
On Mac, there is no hardware support anywhere.
On Linux, pass...
--
Best regards,
Peter mailto: darkmatter@xxxxxxxxxx
_______________________________________________
Openal mailing list
Openal@xxxxxxxxxxxxxxxxxxxxxxx
http://opensource.creative.com/mailman/listinfo/openal
_______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 28, 2006
From: Peter Mulholland <darkmatter@xxxxxxxxxx>
In-reply-to:
<904e76320612281244j248e4b0er3f3fbe776230b076@xxxxxxxxxxxxxx>
References:
<904e76320612281244j248e4b0er3f3fbe776230b076@xxxxxxxxxxxxxx>
Hello Jeremy, Thursday, December 28, 2006, 8:44:09 PM, you wrote: > · Does OpenAL use multiple threads internally to support async playback > or should I use a worker thread(s) in my own program to achieve this? If what you mean is playback of music (for example), OpenAL uses a "push" mechanism which means you have to keep feeding it with data (through an alBufferData call), rather than a "pull" mechanism where it would call a callback function when it wants data. Unless you can periodically feed data to it in your main game loop... you are best spawning a thread to do this work. > · Is hardware support offered for other cards besides those in the > SoundBlaster compatible family? On Windows, yes - any card that has DirectSound3D acceleration. On Mac, there is no hardware support anywhere. On Linux, pass... -- Best regards, Peter mailto:darkmatter@xxxxxxxxxx _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 28, 2006
From: "Jeremy Falcon" <ironbird@xxxxxxxxx>
_______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 23, 2006
From: Paul Surgeon <surgpm@xxxxxxxxxxxxxxxx>
What is the status of the sound capture in the OpenAL source for the Linux platform? Is there anyway to see the progress of particular features without having to check out the source? Thanks Paul _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 21, 2006
From: Peter Mulholland <darkmatter@xxxxxxxxxx>
In-reply-to:
<871FEE9D-F357-4A26-9164-CCA9A9A808E5@xxxxxxxxxxxxxxxx>
References:
<871FEE9D-F357-4A26-9164-CCA9A9A808E5@xxxxxxxxxxxxxxxx>
Hello Nolan, Thursday, December 21, 2006, 8:07:38 PM, you wrote: > After getting my game working quite nicely under OS X and Linux, I > saved the best for last and tried getting it working under windows. I > knew that doing so would be a chore, and in that I wasn't > disappointed . . . er, was disappointed . . . er, something. :) *break* OS X and Linux implementations will be software mixing (some exceptions under Linux but most will be software). Under Windows, you can bet you're getting a hardware implementation and therefore, hardware limits. You can force the Software version on Windows too when you call alcOpenDevice(). -- Best regards, Peter mailto:darkmatter@xxxxxxxxxx _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 21, 2006
From: Garin Hiebert <garinh@xxxxxxxxxxxxxxx>
In-reply-to:
<B00A88EE-5AD0-4C5F-ABEE-C6FDE752F344@xxxxxxxxxxxxxxxx>
References:
<C0B8371A-932C-4047-AEDD-BD7F01DFC198@xxxxxxxxxxxxxxxx> <B00A88EE-5AD0-4C5F-ABEE-C6FDE752F344@xxxxxxxxxxxxxxxx>
OK, so the maximum I need to worry about is a maximum count of *all* sources (rather than a maximum number of *playing* ones?) I was under the impression that I could create as many as I wanted and that the point where I needed to check for failure was the alSourcePlay().
This may have already been answered -- I'm not sure, but just to be clear... All generated sources can be played at once -- they correspond to the playable "voices" on a hardware-based audio solution. alSourcePlay should always work for a valid source name. The virtually unlimited resource is buffers -- you can generate a huge number of those...
Garin _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 21, 2006
From: Garin Hiebert <garinh@xxxxxxxxxxxxxxx>
In-reply-to:
<871FEE9D-F357-4A26-9164-CCA9A9A808E5@xxxxxxxxxxxxxxxx>
References:
<871FEE9D-F357-4A26-9164-CCA9A9A808E5@xxxxxxxxxxxxxxxx>
So am I limited to 32 sources under windows, or has that changed in the past four years? Or is there some other possible cause for this?
That seems very plausible -- most any sound card under Windows except a Creative Audigy or X-Fi is going to be limited to 32 sources or less.
Garin _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 21, 2006
From: Nolan Darilek <nolan@xxxxxxxxxxxxxxxx>
References:
<C0B8371A-932C-4047-AEDD-BD7F01DFC198@xxxxxxxxxxxxxxxx>
Begin forwarded message:
|
_______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 21, 2006
From: Nolan Darilek <nolan@xxxxxxxxxxxxxxxx>
It works reasonably fine, actually, but eventually my alGenSources() calls start returning "invalid value." I've looked at the array into which I'm generating (this is Java in case that matters) and it looks valid. So this leaves "out of non-memory resources" as the next cause, according to the programmer's guide.
Is the information on this page still valid?http://209.85.165.104/search?q=cache:2NAsPwmbuqIJ:www.gamedev.net/ community/forums/topic.asp%3Ftopic_id%3D102469+openal+algensources+% 22invalid+value%22+windows&hl=en&gl=us&ct=clnk&cd=1&client=safari
I have a distance-based mixer that automatically stops/starts sources should starting one result in an error, but it sorta depends on the source being created. Playing the source can fail, but the system depends on creation to succeed.
So am I limited to 32 sources under windows, or has that changed in the past four years? Or is there some other possible cause for this?
_______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 20, 2006
From: "net.surfer@xxxxxxxxxx" <net.surfer@xxxxxxxxxx>
>> [...] now it compiles, but it always reads "zero" samples. [...] > Internally, a capture device is tied to the current context > To work around this bug in the SI, just use alcOpenDevice, alcCreateContext, > and alcCreateContext (or simply alutInit ;-) ) before calling alcCaptureOpen. Thank you, now it seems to work. I'll " polish" my example program a little bit and re-post it, in case anybody is interested Cheers, Franco Naviga e telefona senza limiti con Tiscali Scopri le promozioni Tiscali adsl: navighi e telefoni senza canone Telecom http://abbonati.tiscali.it/adsl/ _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 19, 2006
From: Sven Panne <sven.panne@xxxxxxxxx>
In-reply-to:
<3068700.1166464724571.JavaMail.root@ps6>
References:
<3068700.1166464724571.JavaMail.root@ps6>
Am Montag, 18. Dezember 2006 18:58 schrieb net.surfer@xxxxxxxxxx: > [...] now it compiles, but it always reads "zero" samples. [...] The problem is that the OpenAL SI is not fully OpenAL 1.1 spec compliant: Internally, a capture device is tied to the current context, which is simply wrong. In your example, there is no current context, so alcCaptureOpen fails. To work around this bug in the SI, just use alcOpenDevice, alcCreateContext, and alcCreateContext (or simply alutInit ;-) ) before calling alcCaptureOpen. Cheers, S. _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 19, 2006
From: Sven Panne <sven.panne@xxxxxxxxx>
In-reply-to:
<458412C7.3040905@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061214164252.pz28hrz3eokg4440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <45819EC8.3000907@xxxxxxxxxxxxxxx> <458412C7.3040905@xxxxxxxxxxxxxxxxxxxxxxxxx>
Am Samstag, 16. Dezember 2006 16:37 schrieb Marius Zirngibl:
> [...] I didn't set any device manually.. but I think it uses /dev/dsp.
> I also thought about switching to ALSA, but I didn't yet find out how to
> tell OpenAL to use it.
In former times, the OpenAL Sample Implementation used /dev/dsp as the default
on Linux, but this has changed been changed a few months ago. The default
device is "native" now, and this is the same as "alsa"/"oss"/"dmedia"/"null",
depending on your platform ("alsa" on Linux). The default ALSA device when
that backend is used is, well, "default", BTW.
The default device can be specified in /etc/openalrc or ~/.openalrc like:
(define devices '(oss alsa null))
The first device in this list which can be opened successfully wins.
Similarly, association lists can be passed to alcOpenDevice, e.g.:
"((sampling-rate 44100) (device '(native))"
I am not really sure if this LISP syntax was the best choice, but at least I'm
not responsible for that... ;-)
Cheers,
S.
_______________________________________________
Openal mailing list
Openal@xxxxxxxxxxxxxxxxxxxxxxx
http://opensource.creative.com/mailman/listinfo/openal
Date: December 19, 2006
From: Sven Panne <sven.panne@xxxxxxxxx>
In-reply-to:
<25078.203.12.172.254.1166396483.squirrel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<25078.203.12.172.254.1166396483.squirrel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Am Montag, 18. Dezember 2006 00:01 schrieb nic@xxxxxxxxxxxxxxx: > [...] Is this supported use of the library? [...] IIRC all default values for all kinds of OpenAL objects are stated in the spec, so if these values are what you want, it's "supported". :-) Cheers, S. _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 18, 2006
From: Jason Daly <jdaly@xxxxxxxxxxx>
In-reply-to:
<24668098.1166457372106.JavaMail.root@ps9
>
References:
<24668098.1166457372106.JavaMail.root@ps9
>
net.surfer@xxxxxxxxxx wrote:
Hello, I am new to the list and to OpenAL. I am trying to use the soundcard as an A/D converter in an application (that has nothing to do with sound) to read two voltages wired to the left and right channel of the soundcard input. All I need to do is to read one sample (i.e.: one value for the left channel and one value for the right channel) when I need it, which would happen at low frequency (50 Hz or so). I took a quick read at the programming guide, but the following code doesn't even compile, as the AL_DATA constant (page 28 of the Programming Guide .pdf) is not even present in <AL/al.h> !!!
I think the main point of confusion here is that the "buffer" used by the capture API is not the same as the "buffer" that is filled and used by an OpenAL source during playback. The capture "buffer" is simply an array where the capture system stores its samples.
Here follows the code (commented to further explain what I'm trying to do)... is anybody able to correct it,or to point me to some working code sample doing what I'm trying to do?
I'll do my best... (see below)
-----------------------
#include <stdio.h>
#include <AL/al.h>
#include <AL/alc.h>
int main( int argc, char *argv[] )
{
ALCdevice *mydevice;
ALubyte mybuf[16384];
ALint samples;
ALint leftch, rightch;
// 8000 Hz is really an overkill for my purpose
// We assume we'll be able to retrieve our samples at least 10 times
// a second. At 8000Hz, 16-bit, stereo, we need OpenAL to buffer at
// least 3200 bytes
mydevice = alcCaptureOpenDevice( NULL, 8000, AL_FORMAT_STEREO16, 3200 );
alcCaptureStart( mydevice );
// this would be the application main loop
while( 1)
{
// .....
// ... this would retrieve the samples, whenever I need it
// Copy the samples from OpenAL to our buffer
alcGetIntegerv(mydevice, ALC_CAPTURE_SAMPLES, &samples);
if (samples > 0)
alcCaptureSamples(mydevice, (ALCvoid *)mybuf, samples);
// process the samples....
// sleep(1);
// ......
}
alcCaptureStop( mydevice );
alcCaptureCloseDevice( mydevice );
return 0;
}
Naviga e telefona senza limiti con Tiscali Scopri le promozioni Tiscali adsl: navighi e telefoni senza canone Telecom http://abbonati.tiscali.it/adsl/ _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
--
--"J"
"I'm a castaway stranded in a desolate land,
I can see the footprints in the virtual sand."
--Neil Peart
_______________________________________________
Openal mailing list
Openal@xxxxxxxxxxxxxxxxxxxxxxx
http://opensource.creative.com/mailman/listinfo/openal
Date: December 18, 2006
From: "net.surfer@xxxxxxxxxx" <net.surfer@xxxxxxxxxx>
Hello,
I am new to the list and to OpenAL.
I am trying to use the soundcard as an A/D converter
in an application (that has nothing to do with sound)
to read two voltages wired to the left and right channel
of the soundcard input.
All I need to do is to read one sample (i.e.: one value for
the left channel and one value for the right channel) when
I need it, which would happen at low frequency (50 Hz or so).
I took a quick read at the programming guide,
but the following code doesn't even compile,
as the AL_DATA constant (page 28 of the Programming Guide .pdf)
is not even present in <AL/al.h> !!!
Here follows the code (commented to further explain
what I'm trying to do)... is anybody able to correct it,
or to point me to some working code sample doing what I'm
trying to do?
Thank you in advance,
Franco
-----------------------
#include <stdio.h>
#include <AL/al.h>
#include <AL/alc.h>
int main( int argc, char *argv[] )
{
ALCdevice *mydevice;
ALuint mybuf[1];
ALint leftch, rightch;
// 8000 Hz is really an overkill for my purpose
// 2 samples 16 bit each is 4 bytes, right?
mydevice = alcCaptureOpenDevice( NULL, 8000, AL_FORMAT_STEREO16, 4 );
alGenBuffers( 1, mybuf );
alcCaptureStart( mydevice );
// this would be the application main loop
while( 1)
{
// .....
// ... this would retrieve the samples, whenever I need it
// one samples means a couple of 16 bit values, right?
alcCaptureSamples( mydevice, mybuf, 1 );
// make usage of the sample
alGetBufferi( mybuf[0], AL_DATA, &leftch );
alGetBufferi( mybuf[0], AL_DATA, &rightch );
printf("%d %d\n", leftch, rightch );
// do other things....
// sleep(1);
// ......
}
alcCaptureStop( mydevice );
alDeleteBuffers( 1, mybuf );
alcCaptureCloseDevice( mydevice );
return 0;
}
Naviga e telefona senza limiti con Tiscali
Scopri le promozioni Tiscali adsl: navighi e telefoni senza canone Telecom
http://abbonati.tiscali.it/adsl/
_______________________________________________
Openal mailing list
Openal@xxxxxxxxxxxxxxxxxxxxxxx
http://opensource.creative.com/mailman/listinfo/openal
Date: December 18, 2006
From: Garin Hiebert <garinh@xxxxxxxxxxxxxxx>
In-reply-to:
<25078.203.12.172.254.1166396483.squirrel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<25078.203.12.172.254.1166396483.squirrel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Is this supported use of the library?
I think this is now in the category of "inadvertently supported," and I agree that it should be more formally supported. The idea has floated around before of being able to explicitly force spatialization on/off for each source to make this formal, and it (or something equivalent) will certainly happen.
Garin _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 17, 2006
From: "nic@xxxxxxxxxxxxxxx" <nic@xxxxxxxxxxxxxxx>
Hi OpenAL list, Because I am not using the 3D capabilities of OpenAL, I have neglected to set up any listeners or positions or velocities. I just create sources and buffers and this seems to work well on many Windows implementations. Is this supported use of the library? If not, could it be incorporated in the spec? It greatly simplifies the set-up code and understanding required for users who do not need the 3D functionality. Kind regards, Nic _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 17, 2006
From: "nic@xxxxxxxxxxxxxxx" <nic@xxxxxxxxxxxxxxx>
In-reply-to:
<738324143.20061217090712@xxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <4584B6B3.5000208@xxxxxxxxxxxxxxx> <738324143.20061217090712@xxxxxxxxxx>
> Peter Mulholland wrote: >> Hello nic, >> >> Sunday, December 17, 2006, 3:17:07 AM, you wrote: >> >>> I am designing an application with similar requirements to yours. I am >>> using OpenAL exclusively for 2D audio, I don't use any positioning. I >>> deliberately selected it over ASIO and DS3D on Windows for various >>> reasons (having experience with both). >> >> Maybe you would be better off with PortAudio as your backend? > > I've played a bit with this library - it's a really solid, easy > to use library - but it's really minimal. Very low-level. > > Basically, you set up one input and/or output stream - and it > calls a user callback to consume or provide raw audio data. > > So this hides low level device differences and all of the > treading and timing issues - but absolutely 100% of mixing, > frequency shifting and volume control will be in your application. > > If you actually want to do all of the work, this is a nice > way to hide the details of Windows versus Linux versus Mac but > beyond that, you have to do all of the work yourself. > > For what PortAudio claims to do, it does it very nicely indeed, > but what it does is very little. > Hi Peter (and others), When I was looking for information about OpenAL vs. PortAudio, I read some scathing (and untruthful) remarks about OpenAL on the PortAudio mailing list, from people who have obviously never used OpenAL! For example the claim of "using OpenAL, you can't even do something as basic as playing a stereo WAV file" was not refuted on the list. Of course, the opposite is true. OpenAL supports stereo playback without spatialization and PortAudio does not provide any WAV file loader. Here is my biased opinion. Peter, I agree with your description of PortAudio. I tested it (successfully) but I never used it in any application. I think the biggest differences between PortAudio and OpenAL is the target audience: OpenAL for games developers and PortAudio for audio application developers. At least, even if the audience was not targeted, it seems this is the way the users have split! I don't know which library predates the other. For games authors, OpenAL offers big advantages over PortAudio like some limited (but often hardware accelerated) frequency shifting, volume control and mixing as you say. Not to forget 3D support! For audio applications authors, I think there is very little difference between PortAudio and OpenAL. In many cases the application requires to perform it's own frequency shifting, not just because the range is limited by OpenAL, but because the resampling may not be for immediate playback, or because some higher quality resampling may be required. Once it is necessary to implement resampling, then gain (multiplication) and mixing (addition) are no big deal. The 3D functionality is not used. There may be other considerations like buffer latency for real-time applications, but functionality-wise the two libraries are nearly equivalent in this use. I chose OpenAL for my audio application because of a personal preference for the API. Among other features, I prefer to manage all the threads in my application myself, not to have them embedded in libraries and abstracted through callbacks. Kind regards, Nic _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 17, 2006
From: steve <sjbaker1@xxxxxxxxxxx>
In-reply-to:
<738324143.20061217090712@xxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <4584B6B3.5000208@xxxxxxxxxxxxxxx> <738324143.20061217090712@xxxxxxxxxx>
Peter Mulholland wrote:
Hello nic, Sunday, December 17, 2006, 3:17:07 AM, you wrote:I am designing an application with similar requirements to yours. I amusing OpenAL exclusively for 2D audio, I don't use any positioning. I deliberately selected it over ASIO and DS3D on Windows for various reasons (having experience with both).Maybe you would be better off with PortAudio as your backend?
I've played a bit with this library - it's a really solid, easy to use library - but it's really minimal. Very low-level. Basically, you set up one input and/or output stream - and it calls a user callback to consume or provide raw audio data. So this hides low level device differences and all of the treading and timing issues - but absolutely 100% of mixing, frequency shifting and volume control will be in your application. If you actually want to do all of the work, this is a nice way to hide the details of Windows versus Linux versus Mac but beyond that, you have to do all of the work yourself. For what PortAudio claims to do, it does it very nicely indeed, but what it does is very little. _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 17, 2006
From: Peter Mulholland <darkmatter@xxxxxxxxxx>
In-reply-to:
<4584B6B3.5000208@xxxxxxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <4584B6B3.5000208@xxxxxxxxxxxxxxx>
Hello nic, Sunday, December 17, 2006, 3:17:07 AM, you wrote: > I am designing an application with similar requirements to yours. I am > using OpenAL exclusively for 2D audio, I don't use any positioning. I > deliberately selected it over ASIO and DS3D on Windows for various > reasons (having experience with both). Maybe you would be better off with PortAudio as your backend? -- Best regards, Peter mailto:darkmatter@xxxxxxxxxx _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 17, 2006
From: Garin Hiebert <garinh@xxxxxxxxxxxxxxx>
In-reply-to:
<4584C724.5080001@xxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx> <45840BD7.2010005@xxxxxxxxxxx> <318761807.20061216165402@xxxxxxxxxx> <45843F39.6020202@xxxxxxxxxxx> <372705176.20061216194647@xxxxxxxxxx> <458477CF.7020109@xxxxxxxxxxx> <45848978.9070908@xxxxxxxxxxxxxxx> <4584C724.5080001@xxxxxxxxxxx>
How on earth is a responsible application author do deal with this?
Before outlining a few potential solutions, some background:I don't think this has been much of an issue for our target market (game developers). The model we see at Creative constantly is that a game developer targets a few profiles of the features desired, getting caps for the highest desired profile, failing to a lower one, failing to perhaps a third lower one... It's fairly rare to find an audio engine for gaming which actually grabs the complete capabilities of the audio system and fully utilizes them. DS3D offered all kinds of capabilities information for the developer, but often the information was wrong (bugs or perhaps feature-inflation by some companies) and regardless wasn't taken advantage of -- so with OpenAL it just wasn't considered important to add the complexity of enumerating capabilities. An example -- there are several Windows games out there which look for EAX 5 capabilities, knowing that any card which has EAX 5 will be a Creative product with at least 128-source support as well. These games run EAX 5 with 128 sources on Creative X-Fi boards, and just fall back to a 32 source software mixer (maybe using our "Generic Software" system's EAX 2 support). Why does a developer live with such an inflexible sound system? The main reason is reliability -- they just have to test on some X-Fi boards to get their high-end path, and a smattering of lower-end cards to cover the low-end path, and their testing will be pretty solid. In the more flexible case, they have to deal with a near-infinite variety of low or mid-range solutions which may or may not work as their manufacturers declare (there are some which I can guarantee _won't_ -- see http://tinyurl.com/ymwgo5).**
So, I offer two potential solutions:1) The "magic number" solution -- lame in some ways, but it could work -- just know what the magic values are. For most OpenAL implementations, you can pitch shift by a factor of two -- from 0.5 to 2.0. Some implementations expand this, but none that I'm aware of will guarantee more than another factor of two improvement -- on Creative "native" implementations, you can go from a very small number (near 0) to 2.0 guaranteed. For native implementations, the potential pitch shift upwards is higher than 2.0 -- the formula is actually 192kHz/(buffer's sample rate in kHz) for X-Fi boards, for instance (the X-Fi has hardware mixing at 192kHz). The bottom line -- internalize this information for your implementation, or just take a lowest-common-denominator approach and assume only 0.5 to 2.0 works.
2) The "fixed implementation" solution -- pick one implementation (potentially per platform) and force a consistent feature set among them. If you ship a fixed library with your app, this is quite achievable (especially if you're willing to make some small changes in the original library code). (This isn't what Creative really wants you to do -- we'd like your customers to be able to enumerate and use Creative hardware -- but if your app requires a consistent feature set, this is the way to do it. Through the magic of open source software, you don't have to do things Creative's way.)
Garin _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 17, 2006
From: steve <sjbaker1@xxxxxxxxxxx>
In-reply-to:
<45848978.9070908@xxxxxxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx> <45840BD7.2010005@xxxxxxxxxxx> <318761807.20061216165402@xxxxxxxxxx> <45843F39.6020202@xxxxxxxxxxx> <372705176.20061216194647@xxxxxxxxxx> <458477CF.7020109@xxxxxxxxxxx> <45848978.9070908@xxxxxxxxxxxxxxx>
Garin Hiebert wrote:
Sneaky hidden limits that change from one platform to another are precisely the kinds of thing that OpenAL should be protecting me from."Sneaky" is the wrong word -- the specification _says_ that these limits may change from implementation to implementation.
Fair enough - but giving you no way to query those variable limits is hopeless. You are saying to the application writer: Look! We have this great feature - but a compliant driver might only give you 1% of what you need - and by the way there is no way to query that. How on earth is a responsible application author do deal with this? _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 17, 2006
From: "nic@xxxxxxxxxxxxxxx" <nic@xxxxxxxxxxxxxxx>
In-reply-to:
<458402F8.1070605@xxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx>
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.
Hi Steve,I have encountered similar limitations in OpenAL pitch shifting on windows. Different devices support different rates (some up to 2X, some up to 4X). I don't generate any error trying to pitch shift faster, it just seems to be capped at a maximum rate in each implementation. This is described in the spec. Per Garins previous message, many of these restrictions are due to hardware limitations. I think pitch shifting of samples for sequenced audio is not the intended application for the pitch shift function.
I am designing an application with similar requirements to yours. I am using OpenAL exclusively for 2D audio, I don't use any positioning. I deliberately selected it over ASIO and DS3D on Windows for various reasons (having experience with both). In my application it is necessary to support pitch shifting as fast as 10X and also to reverse the playback! I don't consider the absence of these functions a failing of an audio API. These are low-level operations which can easily be performed on the audio data in software prior to buffer streaming (at least, this is the impression I have formed). I don't have any experience in sequenced audio playback applications, but I expect that they all do their own sample rate conversion and mixing in software prior to buffer streaming for playback.
It is very easy for you to implement basic nearest-neighbour or linear resampling for your first tests. When you need higher quality, you can implement sinc window resampling as described here: http://ccrma-www.stanford.edu/~jos/resample/. Software mixing with signed PCM samples is just addition. It is not computationally intensive and it is easy to write. I think if you search on google, you will find all the information you require to make your application successful with OpenAL.
Kind regards, Nic _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 17, 2006
From: Garin Hiebert <garinh@xxxxxxxxxxxxxxx>
In-reply-to:
<458477CF.7020109@xxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx> <45840BD7.2010005@xxxxxxxxxxx> <318761807.20061216165402@xxxxxxxxxx> <45843F39.6020202@xxxxxxxxxxx> <372705176.20061216194647@xxxxxxxxxx> <458477CF.7020109@xxxxxxxxxxx>
No - I'm assuming that OpenAL is going to properly virtualise all of that stuff for me.
In this case, OpenAL won't -- it wasn't designed as an infinitely-flexible pitch-shifting audio API. If it were, then indeed this would be a major flaw.
Fortunately, the reason why many SoundFont banks have various samples in them of the same instrument is to avoid having to pitch-shift over large ranges. That said, there may be pitch shifts of over an octave required even for a well-made bank (much less poorly-made banks), and OpenAL is probably not suitable as a generic SoundFont rendering API, even when properly-made addons are created.
Sneaky hidden limits that change from one platform to another are precisely the kinds of thing that OpenAL should be protecting me from.
"Sneaky" is the wrong word -- the specification _says_ that these limits may change from implementation to implementation.
What I guess I don't understand is that there are two things the driver and/or hardware has to deal with: The samples-per-second rate of the alBuffer has to be adjusted to match the actual replay rate - and the AL_PITCH and doppler effects also have to speed up and slow down the sample replay rate. So how come I have huge variability of the former and hardly any of the latter when in reality those two numbers end up being multiplied together at some point?
Visualize a 22kHz mixer. Now visualize a 44.1kHz sample being pitch-shifted by 3.5, and doppler shifted by a factor of two, and figure out how that's going to be represented ultimately. Sure, the mixer can dutifully try to represent that situation, but it's delusional to think you're going to get an accurate result -- the mixer simply can't represent all but the very lowest of the frequencies in the original sample in this simple example.
Garin _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: Peter Mulholland <darkmatter@xxxxxxxxxx>
In-reply-to:
<458477CF.7020109@xxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx> <45840BD7.2010005@xxxxxxxxxxx> <318761807.20061216165402@xxxxxxxxxx> <45843F39.6020202@xxxxxxxxxxx> <372705176.20061216194647@xxxxxxxxxx> <458477CF.7020109@xxxxxxxxxxx>
Hello steve, Saturday, December 16, 2006, 10:48:47 PM, you wrote: > No - I'm assuming that OpenAL is going to properly virtualise > all of that stuff for me. Sneaky hidden limits that change from > one platform to another are precisely the kinds of thing that > OpenAL should be protecting me from. The only way this could really happen feasibly is to fall back to software when you want something it can't do. OpenAL doesn't seem to implement the equivalent of DirectSound3D's Caps flags that would allow you to work out such limits. > What I guess I don't understand is that there are two things the driver > and/or hardware has to deal with: The samples-per-second rate of the > alBuffer has to be adjusted to match the actual replay rate - and the > AL_PITCH and doppler effects also have to speed up and slow down the > sample replay rate. So how come I have huge variability of the former > and hardly any of the latter when in reality those two numbers end up > being multiplied together at some point? Simple. The sample rate is only telling OpenAL the format of the data you're sending it to upload. It could very well resample that to the next usable hardware rate for it's own copy. For the small variation in pitch required for doppler, this could be being done by an audio DSP with a limited amount of resampling memory. > Yeah - but I'd really like not to have to write all of that software > when (in theory at least) that's the reason I have OpenAL! OpenAL is primarily for 3D positional audio. It is not a general purpose audio library, and when it comes to doing 2D audio stuff, it's a pain in the ass. > OpenAL is instensely annoying - it always comes 90% of the way towards > something nice and usable - then fails on the last 10%. I can agree there, for 3D sound it is OK but for anything else it has some very sore issues. -- Best regards, Peter mailto:darkmatter@xxxxxxxxxx _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: Garin Hiebert <garinh@xxxxxxxxxxxxxxx>
In-reply-to:
<458412C7.3040905@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061214164252.pz28hrz3eokg4440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <45819EC8.3000907@xxxxxxxxxxxxxxx> <458412C7.3040905@xxxxxxxxxxxxxxxxxxxxxxxxx>
I'm not using Doppler - at least not explicitly. Maybe I have to switch it off..?
If you're not setting velocities, then you're not using Doppler, so that's out as a potential issue.
The limit for the pitch is 2.0. You cannot set the pitch to a higher value, at least in the Linux implementation I use.
I wasn't sure which implementation you were using, but yes there's a 2.0 limit for the Linux implementation.
I didn't set any device manually.. but I think it uses /dev/dsp.
Ah -- I wasn't sure if you were on Windows -- the question is most relevant there because there are quite a few different code paths available. Any more information you can provide on Monday may be helpful -- the sample, if it starts glitching above a specific value, etc... Maybe there's a bug, or maybe this is an artifact with that specific sample above a certain frequency, or... I can try your sample out on some other (Windows) implementations, though, and that may help us figure it out.
Garin _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: steve <sjbaker1@xxxxxxxxxxx>
In-reply-to:
<372705176.20061216194647@xxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx> <45840BD7.2010005@xxxxxxxxxxx> <318761807.20061216165402@xxxxxxxxxx> <45843F39.6020202@xxxxxxxxxxx> <372705176.20061216194647@xxxxxxxxxx>
Peter Mulholland wrote:
You're assuming it will be doing software mixing.
No - I'm assuming that OpenAL is going to properly virtualise all of that stuff for me. Sneaky hidden limits that change from one platform to another are precisely the kinds of thing that OpenAL should be protecting me from.
OpenAL is designed to target hardware accelerated 3D audio as well, and this may well have limits. You really mustn't assume that dirty tricks that work on the software mixing implementation will work when you try it on a hardware accelerated implementation. 3D audio most likely assumes that it only has to bend pitch far enough to reasonably implement things like the Doppler effect, where the pitch range is not great due to intensity falloff. As you already found out, resampling too high introduces nasty aliasing which is not dealt as it would be in a 2D mixer designed for this, because 3D audio is focussing on speed rather than quality.
What I guess I don't understand is that there are two things the driver and/or hardware has to deal with: The samples-per-second rate of the alBuffer has to be adjusted to match the actual replay rate - and the AL_PITCH and doppler effects also have to speed up and slow down the sample replay rate. So how come I have huge variability of the former and hardly any of the latter when in reality those two numbers end up being multiplied together at some point?
Another reason to use software mixing, is that sources are a limited resource under hardware. It would hinder your libraries usefulness if it took 32 sources when theres only 40 available to use. If you mixed in software and fed this to OpenAL with buffer streaming, you would only be using 1 source.
Yeah - but I'd really like not to have to write all of that software when (in theory at least) that's the reason I have OpenAL! The doppler and range atten stuff is trivial compared to pitch-shifting envelope generation and then the mixing of 24 musical sounds together. If I have to do all of that myself then why bother with OpenAL at all? Well, whatever. OpenAL is instensely annoying - it always comes 90% of the way towards something nice and usable - then fails on the last 10%. _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: Peter Mulholland <darkmatter@xxxxxxxxxx>
In-reply-to:
<45843F39.6020202@xxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx> <45840BD7.2010005@xxxxxxxxxxx> <318761807.20061216165402@xxxxxxxxxx> <45843F39.6020202@xxxxxxxxxxx>
Hello steve, Saturday, December 16, 2006, 6:47:21 PM, you wrote: > Why not? > What's so hard about replaying buffers faster? The underlying 'engine' > must be able to do it because I can change the alBuffer's sampling > frequency up and down instead of playing with the alSource AL_PITCH > parameter - and the system works just find. > So the underlying mixing engine inside OpenAL must be capable of > resampling buffers at more or less arbitary frequencies. > What's stopping it from working nicely? You're assuming it will be doing software mixing. OpenAL is designed to target hardware accelerated 3D audio as well, and this may well have limits. You really mustn't assume that dirty tricks that work on the software mixing implementation will work when you try it on a hardware accelerated implementation. 3D audio most likely assumes that it only has to bend pitch far enough to reasonably implement things like the Doppler effect, where the pitch range is not great due to intensity falloff. As you already found out, resampling too high introduces nasty aliasing which is not dealt as it would be in a 2D mixer designed for this, because 3D audio is focussing on speed rather than quality. Another reason to use software mixing, is that sources are a limited resource under hardware. It would hinder your libraries usefulness if it took 32 sources when theres only 40 available to use. If you mixed in software and fed this to OpenAL with buffer streaming, you would only be using 1 source. -- Best regards, Peter mailto:darkmatter@xxxxxxxxxx _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: steve <sjbaker1@xxxxxxxxxxx>
In-reply-to:
<318761807.20061216165402@xxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx> <45840BD7.2010005@xxxxxxxxxxx> <318761807.20061216165402@xxxxxxxxxx>
Peter Mulholland wrote:
You are probably best doing your own resampling and mixing, and then playing this via AL's buffer queues. OpenAL isn't really designed for this sort of thing.
Why not? What's so hard about replaying buffers faster? The underlying 'engine'must be able to do it because I can change the alBuffer's sampling frequency up and down instead of playing with the alSource AL_PITCH
parameter - and the system works just find. So the underlying mixing engine inside OpenAL must be capable of resampling buffers at more or less arbitary frequencies. What's stopping it from working nicely? _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: Peter Mulholland <darkmatter@xxxxxxxxxx>
In-reply-to:
<45840BD7.2010005@xxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx> <45840BD7.2010005@xxxxxxxxxxx>
Hello steve, Saturday, December 16, 2006, 3:08:07 PM, you wrote: > Actually, my experiments suggest that AL locks up > and otherwise misbehaves if AL_PITCH is less than > 0.5 - and produces an error if AL_PITCH is greater > than 2.0. > So two octaves is all I can get from one sound > sample. Urgh! You are probably best doing your own resampling and mixing, and then playing this via AL's buffer queues. OpenAL isn't really designed for this sort of thing. -- Best regards, Peter mailto:darkmatter@xxxxxxxxxx _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: Marius Zirngibl <0zirngib@xxxxxxxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<45819EC8.3000907@xxxxxxxxxxxxxxx>
References:
<20061214164252.pz28hrz3eokg4440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <45819EC8.3000907@xxxxxxxxxxxxxxx>
>> It basically works, but when I change the pitch too much, you hear >> some clipping in the sound when the source is "rewinded". When I >> leave the pitch at the original value, the output is perfect. > > It may be a bug. Is it only happening for high pitch values above a > specific threshold? I cannot say exactly because I'm not at work now. I will test on Monday. > Is Doppler being used (which would be an additional multiplier on the > pitch)? I'm not using Doppler - at least not explicitly. Maybe I have to switch it off..? > There are certainly going to be limits on how far you can push pitch > shifting, but perhaps the implementation you're running isn't > enforcing the limit appropriately. The limit for the pitch is 2.0. You cannot set the pitch to a higher value, at least in the Linux implementation I use. > Which brings up another question -- what device are you opening? I didn't set any device manually.. but I think it uses /dev/dsp. I also thought about switching to ALSA, but I didn't yet find out how to tell OpenAL to use it. Thanks for your help... -marius _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: steve <sjbaker1@xxxxxxxxxxx>
In-reply-to:
<458406CD.9030405@xxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx> <458406CD.9030405@xxxxxxxxxxx>
Actually, my experiments suggest that AL locks up and otherwise misbehaves if AL_PITCH is less than 0.5 - and produces an error if AL_PITCH is greater than 2.0. So two octaves is all I can get from one sound sample. Urgh! _______________________________________________ Openal mailing list Openal@xxxxxxxxxxxxxxxxxxxxxxx http://opensource.creative.com/mailman/listinfo/openal
Date: December 16, 2006
From: steve <sjbaker1@xxxxxxxxxxx>
In-reply-to:
<458402F8.1070605@xxxxxxxxxxx>
References:
<458402F8.1070605@xxxxxxxxxxx>
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