Re: [Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
David Walser <[EMAIL PROTECTED]> writes: > > 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 argh. as far as my tests went, a while ago, i saw that using artsdsp and esddsp was a big performance problem, so personally i use it for xmms only, but not for frozen-bubble and the other games i maintain. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
On Sun Jul 20 1:53 -0500, Lonnie Borntreger wrote: > On Sat, 2003-07-19 at 20:10, David Walser wrote: > > David Walser wrote: > > 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? > > [SDL Init] ALSA lib pcm_hw.c:1055:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: > Device or resource busy > [Graphics...] [Levels] mcop warning: user defined signal handler found for SIG_PIPE, > overriding > Fatal signal: Segmentation Fault (SDL Parachute Deployed) That's an exact analogue to what happens with libao and aRts. Current conjecture is that it's something glibc related... -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] Take due notice and govern yourselves accordingly. Currently playing: Metallica - St. Anger - Some Kind of Monster Linux 2.4.21-3mdk 03:24:00 up 2 days, 14:23, 12 users, load average: 0.47, 0.43, 0.38
Re: [Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
On Sat, 2003-07-19 at 20:10, David Walser wrote: > David Walser wrote: > 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? [SDL Init] ALSA lib pcm_hw.c:1055:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Device or resource busy [Graphics...] [Levels] mcop warning: user defined signal handler found for SIG_PIPE, overriding Fatal signal: Segmentation Fault (SDL Parachute Deployed) Well, something is not working right then, because that's what happens when running frozen-bubble without soundwrapper, with artsd running. Lonnie Borntreger
[Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
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.
Re: [Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
On Fri 18 Jul 2003 08:53, David Walser posted as excerpted below: > 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 don't know whether it's soundwrapper, or something else, but dosbox is an SDL app that still fails to work, from my normal user, anyway. (I run ARTS and it will have just been active since I have KDE set up with an app-launch sound that will have presumably just played or still be playing.) It works fine if I run dosbox as root, which implies a permissions issue somewhere. However, I did the PAM mod (as mentioned in the fast-user switching thread) to 660 from 600, and that didn't help, and I don't really know where to go from there.. Yes, the normal user in question IS a part of the audio group. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
[Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
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?
[Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
Guillaume Cottenceau wrote: > David Walser <[EMAIL PROTECTED]> writes: > >> > I'll let you know when it's up. >> >> http://luigiwalser.homeip.net:8080/~david/soundwrapper-1.0-1mdk.src.rpm >> >> If we use this, we'll need a new menu package w/out the >> soundwrapper script, then this new RPM will need a Conflicts: >> menu <= the current release > > Wouldn't it be simpler to include it in the "menu" package? Absolutely. But like I said, the menu package is going away once the WMs adopt the freedesktop.org menu spec.
[Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
Levi Ramsey wrote: > On Thu Jul 10 15:44 -0400, David Walser wrote: >> Are you running current Cooker? What I was asking was this - on current Cooker, >> *if* arts has the sound device open and you call any libao app w/out specifying >> output device (so ogg123, mpg321, etc), it crashes. > > I actually haven't updated for a while (because gendistrib returns too > many errors for my liking), probably about a month now. I haven't > really tested in KDE of late... am testing now. Aha. > xmmsao [1] works for me... even playing KAsteroids at the same time with no > troubles. > > # rpm -q 'kdebase' > kdebase-3.1.2-20mdk > > Possible bug in one of the last few KDE updates? No. My guess is glibc; anyway it's a library libao depends on I'm pretty sure. Yeah, on older Cooker (couple months) it worked just fine.
[Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
Levi Ramsey wrote: > On Thu Jul 10 15:44 -0400, David Walser wrote: >> Levi Ramsey wrote: >> >> > On Thu Jul 10 11:35 -0400, David Walser wrote: >> >> Levi Ramsey wrote: >> >> > On Thu Jul 10 13:40 +0200, Guillaume Cottenceau wrote: >> >> >> We don't use soundwrapper for cpu-intensive applications because >> >> >> it has an important cpu overhead. >> >> >> >> >> >> Moreover, FB uses SDL and SDL can use (theoretically) arts. >> >> > >> >> > O if every app would just use ao... ;o) >> >> >> >> I agree, that would be nice. Unfortunately that means they'd all be crashing >> >> right now in some circumstances (aRts has the device open). Correct? >> > >> > No, ao (you can check my xmmsao output plugin for a demo of this) tries >> > (by default, this can be configured in /etc/ao.conf, IIRC) to open ALSA, >> > if that fails, then it tries OSS, and if that fails, then it tries >> > ESD or aRts. >> >> Looking at the code, the order it tries them depends on the directory entry for the >> plugins directory. > > Interesting... the documentation indicates a hierarchy of preferred > output devices... Well there is that also. Each plugin has a priority value. What it does is this. The order it tries them is based on the directory entry for the plugins directory. It tests them until it finds one that works. Then as it goes through the rest of them, it only tests them if they have a higher priority. So ultimately, the one that gets picked is the one with the highest priority, out of all the ones that work. OSS and ALSA have the highest priority, ESD and ARTS have the lowest.
Re: [Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
On Thu Jul 10 14:19 -0400, Levi Ramsey wrote: > Normally, I put an RPM in contribs a few days before non-Mdk release of > it, but I haven't been able to login to klama the past few days > (password is accepted according to ssh -v, but the connection is then > closed). If Austin (or anybody else who can login to klama) wants to upload xmmsao-0.6-1mdk, I have an SRPM at: http://cygnetnet.net/~levi/xmmsao-0.6-1mdk.src.rpm -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] Take due notice and govern yourselves accordingly. Currently playing: Rush - Grace Under Pressure - Red Sector A Linux 2.4.21-0.15mdk 15:48:00 up 6:12, 7 users, load average: 0.19, 0.23, 0.16
Re: [Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
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/
[Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
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
[Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
Levi Ramsey wrote: > On Thu Jul 10 13:15 -0400, David Walser wrote: >> Guillaume Cottenceau wrote: >> >> > Lonnie Borntreger <[EMAIL PROTECTED]> writes: >> > >> >> > I agree, that would be nice. Unfortunately that means they'd all be >> >> > crashing right now in some circumstances (aRts has the device open). >> >> > Correct? >> >> >> >> Yup. The menu is useless if I have to start it from the command line to >> >> give it the correct DSL options. >> >> >> >> Maybe soundwrapper needs to be re-written to include the ability to >> >> detect an SDL linked binary, then add the correct SDL sound options >> >> instead of running (arts/esd)dsp. >> > >> > Rather than that, SDL should use esd or arts instead of no-sound, >> > if any of them is using the dsp at that time. It should do that, >> > I don't know if it's currently bugged regarding that. >> >> 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. > > All we need to do with SDL is have it output to libao... Indeed.
Re: [Cooker] Re: Re: Re: frozen-bubble, pysol need soundwrapper
On Thu Jul 10 14:07 -0400, David Walser wrote: > 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? urpmi xmmsao, though that will get you 0.5, which has a major bug which is fixed in 0.6. new version can be downloaded from http://cygnetnet.net/~levi/xmmsao-0.6.tar.bz2 Normally, I put an RPM in contribs a few days before non-Mdk release of it, but I haven't been able to login to klama the past few days (password is accepted according to ssh -v, but the connection is then closed). -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] Take due notice and govern yourselves accordingly. Currently playing: Rush - Vapor Trails - One Little Victory Linux 2.4.21-0.15mdk 14:16:00 up 4:40, 6 users, load average: 0.20, 0.28, 0.26
