Guillaume Cottenceau wrote:
> Lonnie Borntreger <[EMAIL PROTECTED]> writes:
>
>> > I agree, that would be nice. Unfortunately that means they'd all be
>> > crashing right now in some circumstances (aRts has the device open).
>> > Correct?
>>
>> Yup. The menu is useless if I have to start it from the command line to
>> give it the correct DSL options.
>>
>> Maybe soundwrapper needs to be re-written to include the ability to
>> detect an SDL linked binary, then add the correct SDL sound options
>> instead of running (arts/esd)dsp.
>
> Rather than that, SDL should use esd or arts instead of no-sound,
> if any of them is using the dsp at that time. It should do that,
> I don't know if it's currently bugged regarding that.
I agree. This kind of arts/esd autodetection stuff is one thing I've been working on
the past couple weeks. If you want me to look into SDL and submit a patch to that,
let me know.
Of course, then you could end up with the bubble using arts/esd, which you say you
don't want, and is why you don't want soundwrapper on it. Of course in the situation
that SDL uses arts/esd *only* in the case that arts or esd have the sound device open,
it would be the appropriate thing to do. If the user was unhappy with the results,
they shouldn't be trying to play music with XMMS (using arts/esd) and frozen-bubble at
the same time :o) and they can wait 45 seconds until arts/esd automatically let go of
the device and try again.
In the meantime, it's too bad for the apps we *do* use soundwrapper on, because they
use arts/esd if the daemons are running. arts/esd provide the ability to play
multiple streams at once, and if they aren't used for about 45 seconds, they free up
the device. If a user's system has arts/esd with the device open, you can assume they
are making use of this functionality (maybe playing XMMS and doing other things). If
the device isn't open though, you can assume they're not, and it's OK to have an app
just use OSS, instead of forcing it to wake up artsd/esd.
It would be nice if soundwrapper could have *that* behavior (and then basically be
just like libao for apps that don't use libao or do their own autodetection). You
couldn't do it with bash though, you'd have to do it in C, and...
I have done it. I have rewritten soundwrapper in C to only use arts/esd if those have
the DSP open, so now we can use it on SDL apps like the bubble too, and it solves our
problem with those for now also.
soundwrapper.c is attached. It needs to be compiled with -lartsc -lesd, and also,
whatever package it's put it (soundwrapper is currently in menu) needs an autoconf
macro added:
AC_CHECK_FUNCS(arts_suspended)
because that call was only recently added to arts (by me actually :o), and using the
autoconf to check for its existence will allow my new soundwrapper to work even if
someone compiles it on an old arts (in which case it'll just fall back to the current
behavior of using arts if artsd is running).
#include <unistd.h>
#include <artsc/artsc.h>
#include <esd.h>
#include <stdlib.h>
int main(int argc,char **argv){
int sock;
#ifdef HAVE_ARTS_SUSPENDED
if (arts_init() == 0 && arts_suspended() == 0){
#else
if (arts_init() == 0){
#endif
arts_free();
argv[0] = "artsdsp";
execvp("artsdsp",argv);
return 0;}
/* don't wake up the beast while detecting */
setenv("ESD_NO_SPAWN", "1", 1);
if ((sock = esd_open_sound(NULL)) >= 0 && esd_get_standby_mode(sock) == ESM_RUNNING){
esd_close(sock);
argv[0] = "esddsp";
execvp("esddsp",argv);
return 0;}
execvp(argv[1],argv+1);
return 0;}
