-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is this coming up soon? As far as I can tell, SDL only supports direct
sound programming under Linux either by using OSS or by playing through
ESD (which, I think, does support ALSA independently). Will SDL ever have
direct ALSA support?
Rafael R. Sevilla <@Rafael_R_Sevilla> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE57hnT93111w6M5IERAtfJAJ9nv6qpJy8nx7bRHRTiu2EEVVI2aACfbyiy
DRAsycMI+Dchn54cNMN8jhg=
=vWBJ
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is this coming up soon? As far as I can tell, SDL only supports direct
sound programming under Linux either by using OSS or by playing through
ESD (which, I think, does support ALSA independently). Will SDL ever have
direct ALSA support?
We’ve contacted the ALSA folks several times for API information, and their
response has been something like “It’s still unstable, better wait.”
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I’d like to see this too. Also, has anybody thought about openAL support
once the 1.0 spec is finalized and there is an implementation of it?
Andrew.On Thu, 19 Oct 2000, Rafael R. Sevilla wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is this coming up soon? As far as I can tell, SDL only supports direct
sound programming under Linux either by using OSS or by playing through
ESD (which, I think, does support ALSA independently). Will SDL ever have
direct ALSA support?
Rafael R. Sevilla +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE57hnT93111w6M5IERAtfJAJ9nv6qpJy8nx7bRHRTiu2EEVVI2aACfbyiy
DRAsycMI+Dchn54cNMN8jhg=
=vWBJ
-----END PGP SIGNATURE-----
OpenAL doesn’t fit the SDL “blit PCM data to a buffer” model. As it is
already cross-platform, it doesn’t make much sense to somehow layer
on top of it using SDL. That said, we do have SDL_OPENGLBLIT (shudder).
m.On Wed, Oct 18, 2000 at 08:45:36PM -0400, Andrew Ford wrote:
I’d like to see this too. Also, has anybody thought about openAL support
once the 1.0 spec is finalized and there is an implementation of it?
–
Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire
OpenAL doesn’t fit the SDL “blit PCM data to a buffer” model. As it is
already cross-platform, it doesn’t make much sense to somehow layer
on top of it using SDL. That said, we do have SDL_OPENGLBLIT (shudder).
SDL_OPENALBLEEP? 
Last time I looked, openAL had support for using SDL as its back-end
which makes kind of sense (no duplication of low-level drivers), but
of course there’s no use of fancy DSPy hardware stuff then.
Then again, audio isn’t nearly as dependent on hardware acceleration as
graphics is
SDL_OPENALBLEEP?
SDL_OPENALBLIT would actually kindof make sense because the low level
"mix to device" function is called “native_blitbuffer”
Last time I looked, openAL had support for using SDL as its back-end
which makes kind of sense (no duplication of low-level drivers), but
of course there’s no use of fancy DSPy hardware stuff then.
Right, using SDL as a backend is fine because the software OpenAL
driver just needs to write to a memory space the sound card will read
from, which SDL provides.
Until there are OSS DSPy interfaces, there’s not much point worrying
about not having it…
Then again, audio isn’t nearly as dependent on hardware acceleration as
graphics is
Chicken and egg 
m.On Thu, Oct 19, 2000 at 11:10:43AM +0200, Mattias Engdeg?rd wrote:
–
Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire