David Walser <[EMAIL PROTECTED]> writes: > > 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.
Ah, ok. > > 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 never really looked at libao more than compiling it for vorbis-tools. > > 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. Ah, you mean pidof artsd doesn't do the second part of your "and" condition? Well, what's the big deal with it? Isn't it bad? Because, say, you're under KDE with arts. Arts doesn't sit on the DSP. You play frozen-bubble. Suddenly you receive a mail, kmail will want to generate the "ring" that goes along with mail reception. But can't since oss has taken over the dsp. It's not too good, I think? User wants to use arts if he has arts running I guess. And, btw, what will happen? A KDE error message? Sound delayed until FB is closed? Sound ignored? > > [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? I think it supports and doesn't prefer. I think it should autodetect (it dlopen's stuff IIRC). Maybe this is untrue, or bugged. > To define what I'm asking: > support - you can manually ask it to use a particular sound daemon Via environment variable that's possible, IIRC. > prefer - use one if one is running (are we using the same definition here?) Well I used another definition. Prefering is to try and select one option when possible. Here we talk about trying and selecting one option when no other solution is possible :). > autodetect - do what libao and my new soundwrapper do, use one > if it has the DSP open yup. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
