Guillaume Cottenceau wrote: > 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] :).
Ok, I'll look into it. >> 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. I agree, theoretically. Unforunately arts and esd are too CPU intensive currently. > 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. Glad you agree :o) >> 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. Yeah, I suppose ideal would be all apps using libao. Maybe I'll look into that at some point :o) How about an XMMS libao output plugin? >> 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? Exactly what I was talking about earlier. My soundwrapper will only use artsdsp/esddsp if artsd/esd are running *AND* artsd/esd have the DSP device currently open. Perfect solution. This is exactly what libao does BTW. >> 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. No problem. > Ref: > [1] though I'm going in vacations tomorrow and will be back only > on july-28 Enjoy. > [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 So, what's the current situation? It supports, but doesn't prefer, and doesn't autodetect sound daemons? To define what I'm asking: support - you can manually ask it to use a particular sound daemon prefer - use one if one is running (are we using the same definition here?) autodetect - do what libao and my new soundwrapper do, use one if it has the DSP open
