I know this -may- be treading on sacred ground, but is there any way for
SDL to probe the -software- drivers first before trying hardware? I’ve
got multiple (3 actually) soundcards but only the first is hooked up to
speakers… and under KDE/X, artsd is almost -always- active. Now I
know I could disable artsd before running an SDL app, but that strikes me
as a waste of time due to theoretically SDL supporting it…
Yeah, but the sound daemons always have worse latency than writing to the
soundcard directly. For multimedia apps it’s always preferrable to write
to the soundcard if you can.
While I agree that sound daemons (like artsd or esound) really are a Bad
Thing (a kludge to hold us over till ALSA in 2.6 , because sooo many
distros have them turned on by default, and sooo many users don’t
understand that they lock up the sound device (where I work, I’m the
only sysadmin who understands this, and I’m technically the Windows
guy, not the *nix guy it always causes problems for end-users.
Don’t forget that in the case of artsd and esd, the applicable -GUI-
systems enable by default… and many GUI apps are dependant on them and
lock the daemons open. Now the artsd at least can be forced to be shut
down (that’d be useful in an SDL helper lib I guess… but I’m not sure
about esd. (for those unfamiliar, KDE and artsd are tied together fairly
tightly, and Gnome and esd are tied together as well but somewhat more
loosely). By my own experience artsd is more powerful and much nicer in a
lot of ways but has undergone fairly bad breakage in some circumstances
(such as g+±3.0).
The thing is - regardless of how nice it is to talk to hardware directly,
when a sound daemon is in place like this it’s NOT necessarily the “Right
Thing” to just grab the next card in the list…
IMHO right things are:
1. a configuration file (TODO for 2.0 I know
2. disable the daemon on request… hrm… helper lib time?
sigh. I’d like something that fixed -all- SDL apps.
(this would require the app being aware of it… also
3. use the daemon, assuming that’s want the user wants…
(probably a safe bet a lot of the time)
Outside of UI territory there’s lots of options… I suppose one would be
to code an “SDL sound daemon” but that’s just overkill… heh a
DirectX-like kernel module just to provide guaranteed sound access to SDL
apps. Yep that’s a M$-style approach. I sense “Wrong Thing”
I don’t think setting environment vars is the Right Thing but it’d make a
good FAQ backup… Something like
Q: I’m running KDE and I’m not hearing anything? Note : I’ve got a second
soundcard but haven’t gotten around to disabling it… (or I need it for
other purposes and would prefer SDL not to -ever- touch it…
SDL_AUDIO=artsd" for KDE or something like that…
So how much does coexisting with the running system matter to SDL?
- TeunisOn 25 Mar 2002, Samuel Hart wrote:
On Mon, 2002-03-25 at 10:46, Sam Lantinga wrote:
A: in .Xclients (which doesn’t exist by default btw) include "export