David Walser wrote: > David Walser wrote: >> 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. > > Ok, I looked into it, and it's not currently bugged. It has code internally very > similar in nature to libao, and I tested it and it works fine. If the dsp's are not > available it'll try arts, esd, and nas in that order. > >>>> 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. > > Yeah, SDL definately does try the DSP's before going to arts, in fact it goes > farther than libao does and looks for more than one DSP, which is pretty cool. I > might see if we can make a similar adjustment to libao. > > Anyway, given that SDL does this autodetection, absolutely no SDL apps should now be > using soundwrapper. Are there any that are?
I found some: adontell-wastesedge egoboo supertux tuxracer Those packages, as well as any other SDL-based apps, should *not* use soundwrapper.
