I just merged my branch into the SDL 1.3 mainline, so I’d appreciate if
people could play with the audio subsystem and report bugs.
Mac OS X’s CoreAudio and Linux’s OSS (“dsp”) backends support multiple
devices, most of the other backends should still work, but only ever
report one “system output” device. Several of the existing backends can
and will be upgraded to support multiple devices as time, documentation,
and test platforms permit, but largely I was concerned with moving the
existing backends to the new internal interfaces so they still run more
or less like they did before.
Since this work required pretty close scrutiny of the existing code, a
lot of tangental stuff got cleaned up, fixed and reworked, too.
I tested as many backends as I could on the platforms available to me at
the moment: Linux, Mac OS X, BeOS and OS/2. Overall, only about half of
them could be verified to compile and work, so I expect a few just won’t
build at all without a patch or two.
Using the new features: look at test/testaudioinfo.c for basic device
enumeration, and test/testmultiaudio.c for playing to one or more
specific device(s). I tested on an Intel iMac and an amd64 Linux box
with the default audio device and a 10 dollar USB audio thing for a
second device.
Maybe not totally on-topic in this thread, but I tried to compile the
SDL 1.3 trunk with Visual C++, and experienced some problems in the
audio part of the code. First of all it failed to compile the
SDL_dibaudio.c and SDL_dx5audio.c - I’ve attached some patches that
make them compile again. The dx5 one is an obvious typing error, I’m
not sure about the others.
Now it compiles everything fine, but it apparently lacks a file called
SDL_active.c, which as I see only is referenced by the Visual C++
(VC6) project files and the dreamcast Makefile.
Is it some ancient leftover, or what? - Should I just remove it
from the project file?On 10/17/06, Ryan C. Gordon wrote:
I just merged my branch into the SDL 1.3 mainline, so I’d appreciate if
people could play with the audio subsystem and report bugs.
Maybe not totally on-topic in this thread, but I tried to compile the
SDL 1.3 trunk with Visual C++, and experienced some problems in the
audio part of the code. First of all it failed to compile the
SDL_dibaudio.c and SDL_dx5audio.c - I’ve attached some patches that
make them compile again. The dx5 one is an obvious typing error, I’m
not sure about the others.
Huh, I did better than I thought.
These patches are in Subversion now, thanks! (revision #2874)
Now it compiles everything fine, but it apparently lacks a file called
SDL_active.c, which as I see only is referenced by the Visual C++
(VC6) project files and the dreamcast Makefile.
Is it some ancient leftover, or what? - Should I just remove it
from the project file?
Likely you’ll have to disable the video subsystem at the moment, or
everything but the dummy video driver. The system is still in flux, and
a lot of existing video backends need to be updated (or deleted).
Also, if you’re doing this specifically to test the new audio stuff on
Solaris, you’re probably just going to hit this piece of SDL_sunaudio.c:
#error this code has not been updated for SDL 1.3.
Likely you’ll have to disable the video subsystem at the moment, or
everything but the dummy video driver. The system is still in flux, and
a lot of existing video backends need to be updated (or deleted).
Also, if you’re doing this specifically to test the new audio stuff on
Solaris, you’re probably just going to hit this piece of SDL_sunaudio.c:
#error this code has not been updated for SDL 1.3.
Likely you’ll have to disable the video subsystem at the moment, or
everything but the dummy video driver. The system is still in flux, and
a lot of existing video backends need to be updated (or deleted).
Also, if you’re doing this specifically to test the new audio stuff on
Solaris, you’re probably just going to hit this piece of SDL_sunaudio.c:
#error this code has not been updated for SDL 1.3.
Ok, i’ll re-run with --enable-video=“no” and ignore Solaris for now.
FreeBSD is (personally) a more important platform.
- Should I just remove it