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?
