David Walser <[EMAIL PROTECTED]> writes:
> 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.
Yes, it'd help. Please test current situation, if it's not
working, I'd appreciate a patch[1] :).
> 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.
That's the big question.
Theoretically, since esd/arts are superior to dsp (since they
don't block the dsp), we should assume it's good to use them
rather than "pure" oss, even if they're not sitting on the dsp.
However, this has two drawbacks: first, once, SDL had this
behaviour (starting esd), and it was removed because esound was
bugged enough to mean sound delays in frozen-bubble[2]. Second,
we can't know if the user would prefer arts or esd (running
kde/gnome maybe, but if none..).
So I'd very strongly suggest doing what you say: use OSS instead
of waking use arts/esd if nothing is sitting on the dsp.
> 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...
Well it will always be using esddsp and artsdsp, which are know
to be performance-poor.
> 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.
Well, what's the difference with current soundwrapper? Excuse my
probably dumb question.. It seems to me that both version will
use, say, artsdsp, if arts daemon is currently running. What's
the difference?
> 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).
Thanks for your work.
Ref:
[1] though I'm going in vacations tomorrow and will be back only
on july-28
[2] * Fri Aug 2 2002 Guillaume Cottenceau <[EMAIL PROTECTED]> 1.2.4-7mdk
- revert 1.2.4-5mdk change making use of RH patch to prefer sound daemons
since there are delay problems when selecting esound
--
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
