ZSNES OSS/libao sound issues with pulseaudio

dfreer · Post by **dfreer** » Wed May 14, 2008 6:18 pm

*sigh* So ubuntu is now shipping hardy with pulseaudio, AKA POSaudio, and I can't manage to get zsnes to output sound with OSS like in all previous versions of ubuntu.

I've tried following the instructions here:
http://www.pulseaudio.org/wiki/PerfectSetup
Specifically the libao, OSS and installed all the pulseaudio programs like pavucontrol, pavumeter, etc.

Is it a problem with pulseaudio, or am I just an idiot? Using SDL with libsdl1.2debian-all I hear works:
https://bugs.launchpad.net/ubuntu/+sour ... bug/188567

Code: Select all

sudo apt-get install libsdl1.2debian-oss
pasuspender -- zsnes -ad auto

But I always thought that OSS w/libao sounded better than this, would rather not go back to SDL.

Also, zsnes -ad pulse doesn't seem to work either although I've never used it before and probably am just doing it wrong.

Can anyone help?

Post by **Nach** » Wed May 14, 2008 9:43 pm

It actually might be a thread issue, I'll have to look into that, if you don't mind waiting a few days. Also use zsnes --help to see if you have a pulse AO option.

dfreer · Post by **dfreer** » Wed May 14, 2008 10:47 pm

Thanks a lot nach! I'll check on the --help option when I get home from work in about 2 hours.

Once I can get zsnes to play nicely with pulseaudio, I'll be making new i386/amd64 packages for my Ubuntu/Debian repository.

DataPath · Post by **DataPath** » Wed May 14, 2008 10:56 pm

Is that back up again?

I used to use a couple things from your repo, but it went down for a long while, and I gave up and pulled it from the list.

Post by **Nach** » Wed May 14, 2008 10:59 pm

Try this:

Code: Select all

--- zsnes_1_51/src/linux/audio.c     2007-01-10 03:19:12.000000000 +0200
+++ zsnes_1_51b/src/linux/audio.c    2008-05-15 01:03:20.000000000 +0300
@@ -33,8 +33,8 @@

 #ifdef __LIBAO__
 static pthread_t audio_thread;
-static pthread_mutex_t audio_mutex;
-static pthread_cond_t audio_wait;
+static pthread_mutex_t audio_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_cond_t audio_wait = PTHREAD_COND_INITIALIZER;
 static ao_device *audio_device = 0;
 static volatile unsigned int samples_waiting = 0;
 #endif
@@ -181,14 +181,6 @@
     {
       puts("pthread_create() failed.");
     }
-    else if (pthread_mutex_init(&audio_mutex, 0))
-    {
-      puts("pthread_mutex_init() failed.");
-    }
-    else if (pthread_cond_init(&audio_wait, 0))
-    {
-      puts("pthread_cond_init() failed.");
-    }
     InitSampleControl();
   }

dfreer · Post by **dfreer** » Thu May 15, 2008 1:18 am

Nach wrote:It actually might be a thread issue, I'll have to look into that, if you don't mind waiting a few days. Also use zsnes --help to see if you have a pulse AO option.

Here's what zsnes --help gave me:

Code: Select all

  -ad <>  Select Audio Driver :
                  auto = Automatically select output
                  null = Null output
                   nas = NAS output
                   oss = OSS audio driver output 
                  alsa = Advanced Linux Sound Architecture (ALSA) output
                   esd = ESounD output
                 pulse = PulseAudio Output
                  arts = aRts output
                   sdl = Simple DirectMedia Layer output

I'll get back to you hopefully tonight on whether that patch worked for me, thanks!

@DataPath: Yeah, sorry about the repo being down. I moved into a new apartment in late Jan/early Feb, didn't have internet for awhile, finally got internet but had to deal with port 80 being blocked by Verizon, and then got a new full-time job which leaves me with little time to deal with things. Hopefully the repo will be up and running fulltime soon

Post by **Nach** » Thu May 15, 2008 1:49 am

Try some of the stuff here: http://board.zsnes.com/phpBB2/viewtopic.php?p=168959

Post by **Nach** » Thu May 15, 2008 4:41 am

Hey, dfreer, I find your lack of faith disturbing.

I decided to recheck the Ubuntu Forums and tracker to see what is the latest ZSNES and related cluelessness going on over there.

It's really hilarious how people don't understand the libsdl1.2debian-* packages. And then PulseAudio? Haha! They use it and wonder why they have latency.

However I thought you knew better than to write this: https://bugs.launchpad.net/ubuntu/+sour ... bug/227475

Do you really think we're dumb enough to hard code to weird locations like that? Especially when I was the one who pointed out you needed to symlink? Why wouldn't I make a proper fix?

I'd be nice if people would stop pointing fingers at ZSNES all the time, and realize many bugs are in various libraries and sound servers.

You can do: "strings /usr/lib/libao.so | grep /usr"
To see the hardcoded path within libao itself, of course replace "/usr/lib/libao.so" with the proper location. If you want it fixed for a 32 bit on 64 bit system, go compile it yourself, and not hard code the wrong location into libao.

Regarding current issues, it's due to Linux recently changing the scheduling, and making the less than stellar threading fail, which should be fixed with the above patch.

Regarding libsdl1.2debian-*, installing the all package is going to install everything but make the default ALSA, ESD, or PA. To use one in particular, only install that one, or set the environment variable for SDL Audio to another SDL driver. ESD and PA (and aRts or other stuff for that matter) by their very nature are high latency, not what you want in an emulator. ALSA wrappers in most things are also pretty bad.

libao has a config file to set which driver is the auto driver that ZSNES sees. Contrary to stupidity you see on the Ubuntu forums, the -ad driver options are completely unrelated to which libsdl1.2debian-* you install.

If you have OSS installed, and use OSS, you generally get the best sound. If you have ALSA installed, but talk to ALSA via the ALSA API (or a wrapper such as libao or SDL) it's usually worse than talking to ALSA through the OSS API (or wrapper -> OSS -> ALSA). You can call FUD on that last one, but I've done so many tests on it, I find it documented fact.

Recap:
libsdl1.2debian-oss is your best SDL driver (usually).
If you're using ALSA, make sure you have the OSS API enabled.
If you're using a newer Linux, make sure you have the above patch, to use libao.
Don't use sound servers for applications which create the audio on the fly.
Bugs in SDL and libao are not our fault.
Try OSS related drivers, then try ALSA if the first has issues.
Learn about all the related components before pointing fingers.

dfreer · Post by **dfreer** » Thu May 15, 2008 6:40 am

Nach wrote:However I thought you knew better than to write this: https://bugs.launchpad.net/ubuntu/+sour ... bug/227475

Do you really think we're dumb enough to hard code to weird locations like that? Especially when I was the one who pointed out you needed to symlink? Why wouldn't I make a proper fix?

I'd be nice if people would stop pointing fingers at ZSNES all the time...

The objective of the bug report was that I can no longer put enough time into keeping my repository online, and since I host it myself I can't guarantee that it would stay active forever (bills, hard drive crashes, etc). In effect, I'm trying to pull myself out of the loop.

I wanted to share what little I knew to the Ubuntu package maintainers, so that they could fix the ia32-libs / libao package. If they could do that, then people would no longer need to use my repository, they could just download a zsnes binary and run it without problems.

The reason it affects zsnes only is that I couldn't get the goddamn launchpad to accept multiple affected packages (zsnes/libao/ia32-libs). I didn't honestly think it made a difference which package it affected, I figured a maintainer would come along and correctly tag it if I did it wrong.

The wording does sound like it blames zsnes, I didn't intend it that way and after I posted it realized there's no fucking way to edit a post. At no point in time did I intend this to sound like "zsnes devs are to blame for fucking up libao". Sorry Nach, I've seen some of the flak you guys get on this forum, and if I sounded like I was complaining it definitely wasn't intentional.

Regarding the patch: I just tried it with 1.51, and it seemed to work just fine on my 32-bit install. I'm going to try it with 64-bit here in a few minutes.

Post by **Nach** » Thu May 15, 2008 6:57 am

dfreer wrote: The wording does sound like it blames zsnes, I didn't intend it that way and after I posted it realized there's no fucking way to edit a post. At no point in time did I intend this to sound like "zsnes devs are to blame for fucking up libao". Sorry Nach, I've seen some of the flak you guys get on this forum, and if I sounded like I was complaining it definitely wasn't intentional.

Nah, it's okay, I think you were doing a great job with your repository, it's mostly everyone else who is clueless. Especially this http://www.pulseaudio.org/wiki/PerfectSetup, perfect setup, yeah right. Even developers seem to be clueless as to what the issues are. I just hope you can take what you learned here and screw some people's heads on straight over at Ubuntu.

dfreer wrote: Regarding the patch: I just tried it with 1.51, and it seemed to work just fine on my 32-bit install. I'm going to try it with 64-bit here in a few minutes.

Excellent.

Regarding this patch here, it's actually a back port from SVN from many months ago. While teaching pthreads to my UNIX class, and I got asked a few questions, it dawned on me that the thread code in ZSNES needed some fixing. Teaching is a great way to improve your own understanding

So thanks my class, and I hope the patch here, and my experimental builds work for everyone, especially on newer Kernels.

dfreer · Post by **dfreer** » Thu May 15, 2008 7:13 am

Just tried the patch, seems to work beautifully on my 64-bit hardy install. Thanks so much! On a side note, zsnes doesn't show up in the pavucontrol, but I could hardly care less as long as it works.

Sorry for all the questions, but about the 1.51b experimental builds, should I be using them instead of 1.51 patched?
Also:

configure: WARNING: If you intend to distribute this binary, make sure you use force_arch and set to i586 (or whichever CPU Arch you intend for)

Should the binaries I compile intended for 64-bit users have a specific force_arch? Never saw/noticed this warning before I saw your experimental build packages

Post by **Nach** » Thu May 15, 2008 7:25 am

dfreer wrote: Sorry for all the questions, but about the 1.51b experimental builds, should I be using them instead of 1.51 patched?

It should amount to the same thing. I just wanted to know if those binaries work for you.

However if you're giving out source, my sourceball has a few other tweaks to allow it to build on GCC 4.3+

dfreer wrote:
configure: WARNING: If you intend to distribute this binary, make sure you use force_arch and set to i586 (or whichever CPU Arch you intend for)
Should the binaries I compile intended for 64-bit users have a specific force_arch?

Yes. Which one however is a good question. I think you should do force_arch=x86-64. Strangely though I no longer see x86-64 in the documentation for GCC.

dfreer wrote: Never saw/noticed this warning before I saw your experimental build packages

It's been there.

We first mentioned it here: http://zsnes.com/index.php?page=news under the v1.50 release, when we first added CPU auto-detection to the build process.

Post by **Nach** » Fri May 16, 2008 2:24 am

Wow man alive, you post a link to a fix, and the next posts are more Ubuntu idiots who don't even read the post above them. And it happens in multiple threads too!

Gotta love a distro which attracts people who are too stupid to own a computer.

DataPath · Post by **DataPath** » Fri May 16, 2008 2:28 pm

Nach wrote:Wow man alive, you post a link to a fix, and the next posts are more Ubuntu idiots who don't even read the post above them. And it happens in multiple threads too!

Gotta love a distro which attracts people who are too stupid to own a computer.

Now, now, Nach. Windows users who are too cheap to keep paying for an OS license, and not smart enough to be able to pirate it, need to have SOMEWHERE to go.

dfreer · Post by **dfreer** » Fri May 16, 2008 3:05 pm

Yeah, you guys should see the thread where I posted intructions on how to download an NES emulator three times before they finally figured it out.

Anyways, I tried out the zsnes 1.51b core2 binary, worked just fine as expected. I've got a family member graduating from college in another state this weekend, so I probably won't be able to get much done until Sunday.

Post by **Nach** » Fri May 16, 2008 4:04 pm

DataPath wrote:
Nach wrote:Wow man alive, you post a link to a fix, and the next posts are more Ubuntu idiots who don't even read the post above them. And it happens in multiple threads too!

Gotta love a distro which attracts people who are too stupid to own a computer.
Now, now, Nach. Windows users who are too cheap to keep paying for an OS license

Actually, I feel stupid for paying over and over again for the same OS. I own like a dozen Windows licenses.

dfreer:
Yeah, I can relate.

Glad to hear it worked good. Enjoy your weekend.

Post by **Nach** » Sat May 17, 2008 6:58 pm

BTW dfreer, if you're going to be telling clueless people to get one of my binaries, make sure they download the appropriate one for their CPU (list which one they downloaded and their CPU if they happen to get a segfault or invalid opcode/operation).

Otherwise you know, they might think they have a problem with their mouse

RedDwarf · Post by **RedDwarf** » Mon Jun 02, 2008 5:13 pm

Nach wrote:Nah, it's okay, I think you were doing a great job with your repository, it's mostly everyone else who is clueless. Especially this http://www.pulseaudio.org/wiki/PerfectSetup, perfect setup, yeah right. Even developers seem to be clueless as to what the issues are.

Perhaps this one is better? http://pulseaudio.org/wiki/WhyIHateALSA

Deathlike2 · Post by **Deathlike2** » Mon Jun 02, 2008 7:49 pm

That's hilarious. I guess someone finally said the truth pro-ALSA people won't want to admit to.

RedDwarf · Post by **RedDwarf** » Mon Jun 02, 2008 10:18 pm

Deathlike2 wrote:That's hilarious. I guess someone finally said the truth pro-ALSA people won't want to admit to.

I only posted that link like a joke since I know Nach opinion about ALSA (and even if ALSA 1.0.17 will have fixes for hda-intel codecs, I have also found myself with embarrassing things like ALSA working better through OSS API with a SDL game, and I don't like the fact that it's a Linux-only API).

The guy that wrote that talks to ALSA devs and they fix the problems (http://thread.gmane.org/gmane.linux.alsa.devel/52498)... but it takes some time.
And if you click in the "timer-based scheduling" link you can see that:
- I'm the first one to avoid sound servers. I don't want an extra layer adding latency and I will always remember the day SUSE patched KDE to eliminate any use of ARtS like a happy day. But seems like PulseAudio devs know what they are doing and will gave us good latencies.
- Even if the author has some complains about ALSA, he *IS* a pro-ALSA guy. When in the comments someone asks about OSS4 support for PulseAudio the answer from the same author is:

Older versions of PA have been ported to non-Linux systems (the BSDs, Solaris, Windows). The current code has not, although a lot of glue code is in place and the code should generally be friendly to porters. Patches welcome.

OSS is supported as backend. However, OSS4 tends to be less compatible with the established OSS API ("3") than ALSA. (Yes, this is not a joke) So running PA an OSS should generally work, but YMMV.

Also, I consider OSS to be more like a zombie. Dead but still coming back to haunt people. It would be great if it finally died a silent deth. But I guess due to intensified support from the Solaris camp it won't be so easy. I do think that ALSA is by far the more capable system, and while it has issues it still is not as fucked up as OSS, not by a far margin. (And I say that as someone who knows both APIs very, very well on a technical level, and is not a lame fanboy with no clue)

Anyway, I am a Linux developer, payed to bring Linux forward. I only care about ALSA. Basic OSS support is there. It's not as fancy as the ALSA code, i.e. can't do glitch-free and stuff. If anyone wants to see support for this in PA, then he is welcome to contribute. But for myself I don't see any reason why I should invest more time on this than the most basic housekeeping.

byuu · Post by **byuu** » Mon Jun 02, 2008 10:53 pm

The part that should've been bolded:
"Anyway, I am a Linux developer, payed to bring Linux forward. I only care about ALSA."

Translation: "Interoperability? Who needs it? I'll take a page from Microsoft's book -- BSD, Solaris and Unix can take a hike."

Deathlike2 · Post by **Deathlike2** » Mon Jun 02, 2008 11:45 pm

byuu wrote:The part that should've been bolded:
"Anyway, I am a Linux developer, payed to bring Linux forward. I only care about ALSA."

Agreed, on many levels. Gee, it's not supposed to be anti-OSS? What spin!

F-3582 · Post by **F-3582** » Sat Jul 19, 2008 4:53 pm

Could some one please clear something up for me:

Is the native pulseaudio API capable of competing to OSS in terms of latency? By that I mean Pulseaudio on top of some undocumented and very special ALSA functions no one used before as pointed out here and here.

Because whenever someone rants about Pulseaudio I have to think about the statement that using the Pulseaudio API directly provided nice low latencies and stuff. Or that the 'glitch-free' extension would be the next CoreAudio and of course the latencies would be as low as possible.

What's your opinion on this?

Oh, and is there some practical data of how much CPU OSS4 uses compared to ALSA+Pulse under similar conditions?

Post by **Nach** » Sat Jul 19, 2008 8:19 pm

F-3582 wrote: Is the native pulseaudio API capable of competing to OSS in terms of latency?

I don't know any hard facts on the matter, nor have I done any testing.

Although from what I have heard and tested, OSS 4 seems to have the lowest latency available on Linux, except perhaps OpenAL when running directly on creative sound cards.

Unless this unknown ALSA API is a real significant improvement over the rest of the API, it's not even a contest.

F-3582 · Post by **F-3582** » Mon Jul 21, 2008 12:00 am

Well, after some reading/thinking I have to say that I'm pretty impressed with what Pulseaudio achieved and is trying to achieve. First I thought that it really was just some sound server, but the more I think about it the more it seems like the AUHAL component in CoreAudio while ALSA is the HAL counterpart.

I think that this might really work for reducing both latency and CPU usage.

Let's see how this is working out. After all this functionality is still to be added to the next version.