Guillaume Cottenceau wrote: > David Walser <[EMAIL PROTECTED]> writes: >> > 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?
Nope, only the first part. > Well, what's the big deal with it? Isn't it bad? Because, say, If arts/esd don't have the device open, you probably don't want it using them. Like I said, their too CPU intensive, and you agreed with me that for now, the right approach is to only use it if they've already got the device open. A good example is timidity. Like frozen bubble, it's a CPU intensive app, and doesn't play too well with arts. Also using arts output makes it take longer to start. So our current TiMidity package only uses aRts if it *has* to (aRts has the DSP open), that way it'll at least play in that case. > 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. No, user runs arts if their running KDE. If they are using it for sound output, arts has the device open. If it's not open, they're not using it, despite the fact that it's running. The user is just not going to have this problem. If they want arts, they can make sure it has the device open first. Nice advantage over current soundwrapper is, if they *don't* want it, they can just make sure arts doesn't have it open. Currently all soundwrapper using menu entries are useless in that case. Using my (and libao's) approach, 99% of the time the user won't have to think or care about any of this. > And, btw, what will happen? A KDE error message? Sound delayed > until FB is closed? Sound ignored? Depends on how the app is coded. It could just wait until FB is closed. >> > [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. >
