[Solved] [Linux] Crackling Sound Using OpenGL (and XVideo) Graphics

May 5, 2012 at 9:10 PM
Edited May 5, 2012 at 9:13 PM

This thread identifies an issue that I'm having that I mistakenly reported in http://pcsxr.codeplex.com/discussions/233228 (Sound Problems with Linux). There is also an open Issue at http://pcsxr.codeplex.com/workitem/9779 that may be related.

On 32-bit Arch Linux, I'm experiencing a sound problem with this excellent emulator that causes audio to crackle and pop reliably when using the packaged OpenGL plugin as well as Pete's XGL2 plugin and less-reliably (but never-the-less occasionally) with the XVideo graphics plugin. The audio problems occur using PCSXR's packaged SDL audio plugin as well on its packaged ALSA and OpenAL plugins (I didn't try OSS), although they manifest slightly differently with the popping being much, much worse with the ALSA plugin and the popping being replaced with scratched-CD-like audio "skips" with OpenAL.

My video card is an NVidia GeForce 8500 GT, which has 512MB of memory. My CPU is an Intel Core 2 Quad CPU Q6600 with four cores, each at 2.40 Ghz, and I have 3 gigs of RAM. My sound card is in integrated HDA_Intel card, which is fairly garbage, but I don't usually have sound issues like this. dario86 has been kind enough to help me as well as he could and has informed me that these specs are well above the minimum required for running PCSXR smoothly, and I should note that the popping and crackling does not become more or less prevalent when starting PCSXR with max or minimum settings using the OpenGL plugins, nor do I get any indication of any slow-down or frame-skipping at maximum graphical settings, which leads me to believe that the performance of my computer might not be the problem.

Crackling and popping occurs not only when sounds are playing (with several pops per second using the SDL sound plugin), but more rarely (and less-reliably) during periods of total silence, such as loading screens. Visual analysis of recorded waveforms (examples further on) taken during these periods of silence show me that at least some of these audible pops are not simply audio drops but are (glitched) sounds all their own.

At first, I thought that using the XVideo plugin (per dario86's suggestion) resolved the audio issues entirely, but, after noticing occasional, isolated pops in periods of silence, I did testing using the Playstation BIOS's boot sound and recorded a couple of examples where the popping was clearly audible during the sound (although it was also perfect sometimes). Using the XVideo problem almost entirely eliminates this problem during regular play, but perhaps the fact that the problem still exists when using the XVideo plugin will help lead to some resolution.

I do not have this problem with any other software, including the pSX emulator. Never-the-less, I've heard pops like these before as latency issues that I've had to and been able to resolve with other emulators or when processing audio (underruns when using JACK to record music). That doesn't explain, though, why raising or lowering my video settings or running intensive software in the background (recording the following examples) doesn't seem to affect the popping, or why there are pops during periods of silence (clearly not drops, although they could be drop-related).

For any interested developers, here are some recorded examples of sound comparing use of the XVideo plugin (used as a control for the most part, since it sounds perfect 99% of the time) and the packaged OpenGL plugin (where popping is clearly heard). All of these examples are using the SDL sound plugin, although I can record examples using the ALSA and OpenAL plugins upon request; I described their respective issues earlier, and they're probably related.

Playstation BIOS sound

XVideo control: http://dl.dropbox.com/u/13106097/pcsxr_sound/xv_sdl_bios.wav

XVideo second try (with pops): http://dl.dropbox.com/u/13106097/pcsxr_sound/xv_sdl_bios_2.wav

XVideo third try (with pops): http://dl.dropbox.com/u/13106097/pcsxr_sound/xv_sdl_bios_3.wav

OpenGL (with pops): http://dl.dropbox.com/u/13106097/pcsxr_sound/opengl_sdl_bios.wav

pSX emulator with sound latency set slightly too low (40 ms instead of 41ms for my system): http://dl.dropbox.com/u/13106097/pcsxr_sound/psx_bios_latency.wav

Tenchu opening:

XVideo control: http://dl.dropbox.com/u/13106097/pcsxr_sound/xv_sdl_tenchu_opening.wav

OpenGL (extended to show pops during a loading screen at 54 second mark, which do not reliably occur at any point but which sometimes randomly occur): http://dl.dropbox.com/u/13106097/pcsxr_sound/opengl_sdl_tenchu_opening.wav

Tenchu dialog:

XVideo control: http://dl.dropbox.com/u/13106097/pcsxr_sound/xv_sdl_tenchu_dialog.wav

OpenGL (with pops): http://dl.dropbox.com/u/13106097/pcsxr_sound/opengl_sdl_tenchu_dialog.wav

Tenchu stage music:

XVideo control: http://dl.dropbox.com/u/13106097/pcsxr_sound/xv_sdl_tenchu_music.wav

OpenGL (with pops): http://dl.dropbox.com/u/13106097/pcsxr_sound/opengl_sdl_tenchu_music.wav

MegaMan 8 from boot (Capcom splash logo) to first stage music, skipping scenes:

XVideo with minor pops on silent loading screens (I started recording while a long series of pops was playing before the Capcom splash) and during the Capcom splash: http://dl.dropbox.com/u/13106097/pcsxr_sound/xv_sdl_megaman_8.wav

OpenGL with pops, including on some silent loading screens (but not all, as usual, nor does it always occur on the same screens). As with XVideo, there were pops while the disc was loading before the Capcom splash, but I captured more of them this time: http://dl.dropbox.com/u/13106097/pcsxr_sound/opengl_sdl_megaman_8.wav

If any developer visually analyses these examples (which shows that the pops during silence are clearly not drops, which would be weird during silence), ignore the DC offset and audibly-imperceptible noise, both of which are a result of my stringing a cable from my soundcard's output to its line input. These examples illustrate clearly what I hear when I play PCSXR normally, and recording these examples on the same machine that PCSXR is playing on did not affect the frequency of crackles or pops, which is one more thing causing me to wonder if this problem has anything to do with latency.

I should note that my sound card has a power-save mode enabled (that I've been unable to disable in the past) which causes an audible pop when the soundcard is powered on, which happens almost every time that I start any media-playing program, including emulators. PCSXR is the only software, though, that gives me intermittent pops. That being said, I know nothing about how this emulator works sound-wise, and so maybe it's possible that the audio pops during periods of silence ~are~ latency-related and, for some reason, when the audio is dropping, my sound card is being released and reacquired?

It'd be nice to be able to try PCSXR with a much higher sound latency (selectable latency is a feature in many emulators, although, for all I know, this could be impossible or extremely tedious to implement in PCSXR) to see if the problems are resolved.

Thank you so much for all of your work with PCSXR, devs. I believe that emulation doesn't get the respect that it deserves as an extremely important part of gaming culture: preservation of our beloved art form freed from the corporate re-releases on things like compilation discs, Xbox Live, and the Virtual Console. Gaming hardware from the past all will fail, but these games that developers have put their sweat and blood into and which we've all enjoyed during the best times of our lives will live on due to the work of unpaid hobbyists that share their code for the world to own forever. You guys are my heroes, and thank you, dario86, for your personal help regarding this issue.

-David Hernandez

May 6, 2012 at 1:18 AM

I understand that you don't develop the OpenGL plugin, and I imagine that it's possible or likely that the bug is there. I don't know how the plugins work with each other in the architecture such that the graphics plugin could cause audio problems; maybe it has to do with the syncing? The XVideo plugin works, though, although I still do get some (minor) crackling, such as before MegaMan 8's Capcom splash screen and during the Playstation BIOS boot sound in my second and third examples. Is there any way for me to adapt the audio latency that you know of?

I use the proprietary NVidia driver, and I might end up trying it with Nouveau to see if that helps at all, although it's my understanding that I'd have to completely uninstall the NVidia driver (for reasons that I don't understand, I guess that the two can't coexist in the same system and I couldn't simply disable one).

If you never hear any crackling with XVideo using the same settings, it makes me wonder again if the problem could possibly be latency-related. Even if you File -> Run BIOS three or four times, you never hear any crackling? I didn't hear any the first time, but I was able to catch it crackling twice out of three attempts.


May 7, 2012 at 11:54 PM

I started going through the source code and changing values here and there that looked as though they could be related to latency, but none of them had the desired effect, so I began to look for where the audio might be syncing to the video. I couldn't find where this code is, but it led me to wonder if I had missed any setting to asynchronize audio in either the GPU or SPU plugins.

While I was looking through settings, I enabled the framerate display and noticed that XVideo ran at 60 FPS where-as OpenGL ran at 59 FPS. The bug is in the OpenGL plugin's (both the packaged plugin and my own Pete's XGL2 plugin) ability to autodetect the frame limit. As I suspected, the sound crackling was due to audio and video syncing together, and the video was slightly too slow.

Manually setting the OpenGL plugin's frame limit to 60 fixes my audio problems. Sweet, precious crackle-free audio with the OpenGL plugin.

Thanks for all of your help, Dario, and I'm sure that you're right about the skipping with the Xvideo plugin being related to the recording that I was doing in the background. Based on my findings, I'm sure that anything that would cause XVideo's FPS to even barely alter would cause a small, audible click.

If you're the type of person that would rather sound and video occasionally be a few milliseconds out of sync when the FPS gets interrupted rather than hearing a click, it'd be nice to have an option to desynchronize audio from video like the checkbox that many emulators have. I wouldn't use that option now that I know that my issue can be solved by manually setting my frame limit, but maybe it's something to think about for a future feature?

I'm sorry for putting you through so much, dario86, for a problem that did end up being a bug with the non-PCSXR-developed OpenGL plugin (autodetected framelimit off by 1), so thanks again. Maybe this post will help somebody that's having the same problem.

-David Hernandez

May 8, 2012 at 7:39 PM

Patience nothing; I know that you've probably got more interesting things to do, and I enjoyed the testing and probing, and now I get to run PCSXR the way that I wanted, which is a huge pay-off.

Do you mean that you're going to file a bug for the OpenGL plugin? Since the PCSXR team doesn't develop it, can you point me to who does? A quick Google search for peopsxgl just finds me a couple of forum posts by the guy that ported it to Linux. If there's an actual active project for this plugin somewhere, I'd be interested to know, because I've got a few graphical bugs to report that occur with this plugin (but not with XVideo or Pete's XGL2).

I'd rather use an open-source plugin than Pete's XGL2, which is what I'm currently using, but the minor graphical bugs are too distracting for me, so it'd be nice to be able to bring them to somebody's attention.


May 9, 2012 at 6:09 PM

Oh! Well, that makes all of the times that I said, "Although I understand that the PCSXR team doesn't develop the OpenGL plugin," rather silly! I'd have reported the bug myself, then, and I'll report the graphical bugs that I'm having with Tenchu, too, in case any of the other developers want to have a crack at it. Of course, the OpenGL plugin displays enhanced graphics; while I like the look of pSX and PCSXR's Xvideo plugin, and while I enjoyed playing all of these games on my old, grey Playstation, I've actually come to feel like playing with enhanced graphics comes closer to the games original developers' intentions; the low polygon resolution always seems to be hiding details in the textures that are impossible to notice on the original console.

I fell in love with enhanced-graphics plugins when I first played MegaMan Legends with one and saw just how detailed the characters' faces were -- subtleties that were ultimately futile because they're invisible from any angle on the original hardware. Tenchu's graphics are the same way... lots of hidden details that would be difficult or impossible to pick out with the original hardware, which is one more reason that I'm so grateful to emulator developers.

That being said, I can understand the thrill of perfectly emulating the old hardware, not only for nostalgia's sake or because, until you ~can~ perfectly emulate the hardware, you can't improve upon it because you'll be stifled by unpredictable bugs and will require many hacks, but because that grey box was a huge part of our lives, and, although it was only engineered by some Japanese dudes probably as a money-making ploy, deciphering it and perfectly recreating it must feel like putting oneself on footing with the gods, haha. Maybe not. I would if it were me.

Thanks again, dario86. I'll stop bumping this post with my drivel, now. Good luck with future development!


PS: Separating my Playstation games from Sony's hardware is an awesome feeling -- to know that I can go out to a used game retailer and pick up some classics that I never got to play in my childhood for a couple of bucks and then come home to play them on ~my~ terms on ~my~ machine, and to never have to worry about my Playstation going bad or my discs getting scratched, is very liberating. Also liberating is the notion that PCSXR's compatibility is awesome and that, being open-source and actively developed, it's only going to get better, and that the devs are passionate enough about the project to care as much as they do about resolving issues that they'll respond to bug reports in good time or help somebody like me on the forum even though their users are not paying customers.

Thanks guys. If not for you, I wouldn't be enjoying the classic games that I have been, lately, and so you've been directly providing me and countless others with hours and hours of enjoyment taken right from one of the best eras of gaming. I hope that you never feel that the effort is at all vain, because the work that emulator hackers do will live on forever and becomes increasingly important as corporations like Sony lock down their IP more and more, trying to wrangle control over experiences that we've all come to own so that they can sell them to us again and again. When nobody can find a Playstation anymore, they'll be able to use PCSXR or a descendant to play our old games, and it'll be free, and every commit to PCSX, PCSX-df, PCSX-R, etc., will have been to effect, even if no individual is remembered, haha.

...so yeah. Thanks!

May 9, 2012 at 11:01 PM

This is a very nice emulator.  I've been using the version out of the Linux Mint 12 software center for a few days now and have been very impressed, except by the problems decribed here.  I tried everything I could think to get the audio to stop crackling.  Finally I found a thread on the Ubuntu forums where someone dumped the ubuntu version, and went with the latest SVN with success.  So I did the same with mixed results.  The crackling is now limited only to cut scenes and FMV's.  If all I wanted to do was play games it would be absolutely tollerable.  However, I started using this so I can make a few songs with sound samples from all the resident evil games, and I need clear audio which is all FMV and cut scenes.(Again, the SVN version makes this MUCH better, and I see one of the recent commits was a mix for the dialouge in these games.)  There's one more "problem" here as well.  By going to the SVN version, it only includes the Xvideo driver and not the openGL also.  Gotta say, the openGL version looks WAY better.  I've tried adding pete's plugins to my plugin/cfg folders, and they don't show up in the dropdown to choose the video plugin.  Am I doing something wrong?  Is there another step not included in Pete's readme?

All in all great software, if I can work out the audio bugs, and it would be nice but not essential to get better visuals back, cause I gotta say after a few days of awesome openGL rendering, I don't think I can pull my old PSX out of storage ever again!  Thanks in advance if anyone can help

P.S. The fix of frame locking doesn't help in the Xvideo driver!

May 10, 2012 at 3:11 AM

Akavir, I wish that I could help with the crackling that you're hearing with the XVideo plugin, but I don't really get crackling with the XVideo plugin. As for the OpenGL plugin, you have to enable it when configuring by using:

./configure --enable-opengl

after running autogen.sh . You should be able to add your own plugins, though, by placing them into your plugins directory. You have to put the .so file and the cfgPluginName file (or links to those) into .pcsxr/plugins (or whatever your plugins directory is), and then also link or copy the cfgPluginName file into .pcsxr/plugins/cfg . After this, restart PCSXR and you should see the plugin listed. This was how I added Pete's XGL2 plugin as well as some others.

Perhaps the crackling that you're hearing is just a bug with the audio of certain games, in which case you should report the bug. If it's a universal problem, though, perhaps your rig isn't powerful enough to run XVideo at a full sixty frames? I wish that I could help more.


May 10, 2012 at 3:33 AM
Edited May 10, 2012 at 3:37 AM

Thanks for reminding me about enabling the openGL on compile, i do remember reading that somewhere.  And as for my rig being powerful enough, that's definitely not the issue(i7 2.93Ghz Quadcore, 9G of RAM, and Nvidia GFX-260 w/756 vRAM).  I'll try a recompile and hope that it fixes the problem!  Thanks!


EDIT:Though my sound setup is far from standard.  This computer is an audio workstation that's been heavily modified by KXStudio.  Just to give u a basic idea, JACK is always running, Pulseaudio dumps all of it's outputs to a single output into JACK, before JACK  passes it all to a final ALSA out.  So in my case it could be a combination of chaining outputs and/or sampling rates or buffersize being ouput from PCSXR(which as you know has no easy way of being changed.)

May 12, 2012 at 11:33 PM

UPDATE:So I was just testing out Ubuntu 12.04 32-bit.  Tried the version from the software center(which is much newer than the version in the Mint 12[11.10] repos.) and by god everything works AMAZING NOW!  The openGL driver doesn't mess up my sound (had to frame lock it to 60 as earlier suggested)!  And there must be a newer xpad module in the kernel cause to my surprise now I'm GETTING DUAL SHOCK TO MY XBOX 360 controller!  This is amazing.  My hats go off to the PCSX-R team now that I can see just how wonderful everything is!

May 16, 2012 at 6:40 AM

Sorry for the confusion.  It is not a newer build.  I didn't realize til now that the build I got was an SVN build that happened to be in the KXStudio PPA.  Also, the newer version is not the problem.  The Mint 13-rc came out today and I've been testing it with the SAME results of audio with pops and cracks.  What I've come to find is it's a problem somewhere in the 64-bit system.  I downloaded the 32-bit version just to see, and low and behold both the version from the ubuntu main repo and the SVN work just fine.  Guess I have to keep a 32-bit partition for playing PS games for the time being.

May 16, 2012 at 6:21 PM

It's the only explanation for it.

Linux Mint 12(64-bit)-Audio Problems

Linux Mint 13-Cinnamon&MATE(64-bit)-Audio Problems

KXStudio 12.04 Beta(32-bit)-ubuntu repo&SVN PCSXR work without issue

Linux Mint 13-MATE(32-bit)ubuntu repo&SVN PCSXR work without issue

Jun 1, 2012 at 4:50 PM

Confirming what has already been said. Sound is terrible in 64bit Ubuntu, works fine in 32.

Dec 26, 2012 at 5:13 PM

Not sure why this is marked [Solved] when it sounds like the consensus is that sound is broken on 64-bit systems...?  Anyway it's broken for me too, on Mint 12 64-bit.  I guess I'll go try to see if there's any way I can write a plugin to fix it, maybe.

Dec 28, 2012 at 1:50 AM

I just spent a day and a half poring through the code and all I've learned is that this is way out of my league.

The crackle goes away when I put in a hack to silence the XA audio feed, so I guess it's an XA thing.  I found a buffer underrun that keeps happening between the XA thread and the main SPU thread, but I don't even think that's the main source of the problem, because I wrote an adaptive resampler that fixes that problem (as confirmed by feeding a test tone into the XA data) and yet the crackle is still present in actual game audio.

This is effing impossible.  Also, I'm worried whether this project is long dead or something, since there are inexplicably no years in the dates on these forum posts.  I guess I should try a Windows emulator under a VM and see if I have any better luck.

Jan 13, 2013 at 3:59 AM

Oh, just found out how to look at the developers' activity (it shows the year!!), and I see that this project is still actively maintained.  That being the case, I'm jumping back in again.  I've now got it running in a 32-bit chroot and the problem is reduced but not eliminated.  I'll see if I can track down what's going differently in the 32-bit and 64-bit versions by debugging them side-by-side.

Jun 21, 2013 at 7:57 PM
I'm having the same problem of cracking sound.
In Megaman X5, no matter if using Xvideo or OpenGL plugins,
no matter how many different settings I use, I always ave crackling sound.

I'm using Kubuntu 13.04 64-bits, the same problem always ocurred on past 64 bits versions.

Any idea how to solve this?
Jul 10, 2013 at 7:50 AM
This discussion should not be marked as solved. The problem is still quite present in OS X and apparently in Linux as well, and if my understanding of the issue in my latest comment for Issue #9779 is correct, it's a fundamental problem with how the emulator manages SPU and GPU timing, requiring some significant reworking to fix.