In SDL-1.1.7 there are lot of audio drivers.
But I didn’t find any way to know audio drivers compiled on user computer.
I would like let the user decides what audio driver he wants. I know there
is the SDL_AUDIODRIVER variable but choose in a list should be more easy.
There are some functions to select an audio driver but nothing to access
the bootstrap structure.
It’s why I thought the SDL_ListAudioDriver.
Regards
Nicolas
Here a sample of what I thought. Of course it’s not complete, beaucause I
didn’t know if you like my idea and how do you want to implement this
function.
The part to free resources is missing.
/* in SDL_audio.h */
struct SDL_AudioDriver {
/* * * /
/ The name of this audio driver */
const char *name;
/* * * */
/* The description of this audio driver */
const char *desc;
}
/* in SDL_audio.c */
SDL_AudioDriver **SDL_ListAudioDriver()
{
int i;
int len;
SDL_AudioDriver **SDL_driverlist;
In SDL-1.1.7 there are lot of audio drivers.
But I didn’t find any way to know audio drivers compiled on user computer.
I would like let the user decides what audio driver he wants. I know there
is the SDL_AUDIODRIVER variable but choose in a list should be more easy.
There are some functions to select an audio driver but nothing to access
the bootstrap structure.
It’s why I thought the SDL_ListAudioDriver.
This was added a month ago and quickly removed because it opened up a
whole bunch of issues related to preferences and defaults and ways of
describing driver capabilities.
There will be something like this in SDL 1.3 at some point, but not in
SDL 1.2.
Ideally the defaults are fine for the user. If the application can’t
open /dev/dsp, it will try ESounD and aRts respectively. If those don’t
work, usually the sound will fail.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
There are some functions to select an audio driver but nothing to access
the bootstrap structure.
It’s why I thought the SDL_ListAudioDriver.
This was added a month ago and quickly removed because it opened up a
whole bunch of issues related to preferences and defaults and ways of
describing driver capabilities.
Was the problem with reading the bootstrap structures or with allowing the
user to select which driver they wanted to use?
There will be something like this in SDL 1.3 at some point, but not in
SDL 1.2.
Do you already have a convention for versioning? The Python team found that
people/managers were sometimes reluctant to adopt Python as a development
platform/tool because the major version number was still “1”, so they went
from 1.5.2 to 1.6 [and shortly thereafter] to 2.0. (instead of continuing
along with 1.5.3, 1.5.4, etc…)
If you say SDL 1.2 will introduce API changes that would break existing
programs that make use of SDL, could I recommend you call such a version
2.0?
I dunno, just thought it might help…–
Olivier A. Dagenais - Software Architect and Developer
Was the problem with reading the bootstrap structures or with allowing the
user to select which driver they wanted to use?
Allowing the user to select which driver they wanted to use.
Do you already have a convention for versioning?
Yes. Even minor numbers are binary compatible and “stable”.
Odd minor version numbers are development/experimental branches,
which after they become stable get turned into the next even
numbered release.
If you say SDL 1.2 will introduce API changes that would break existing
programs that make use of SDL, could I recommend you call such a version
2.0?
SDL 1.2 will not introduce API changes over the 1.1 series.
SDL 1.3 will introduce changes, and if there are as many changes as I
think there will be, it will probably be rolled over into SDL 2.0.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software