An odd issue with Display.sync()

[elias4444]

I just can't figure this one out... so I'm wondering if it's a bug?

I've noticed that whenever I set display.sync(true) (in my screenmanager) or use Display.vsync() in my loop, that the games get choppy for some reason. I even play my audio in a seperate thread and it get crackly (and sometimes even cuts out completely). Funny thing is though, when vsync is off, everything runs beautifully. I use timer to sync everything to the system clock, so FPS shouldn't be an issue. I was just wondering if perhaps the vsync code was doing something weird with the CPU.

Any ideas?

[elias4444]

Just for a quick update... I've been trying my code on multiple machines. It only happens on some of them (the less powerful ones). But it doesn't make much sense to me, as even the less-powerful machines are still getting 60fps (in sync'd mode). Only thing I can think of is if the CPU is spiking (so it's not noticable on more powerful machines), or the timer doesn't have high enough resolution - which I've never had a problem with yet.

[elias4444]

Another update... looks like the issue may be in the sound code - although why it only shows up when vsync is enabled is beyond me. I think I was able to fix it though... by using thread.yield instead of thread.sleep... quite the coincidence I'm thinking considering I just posted a topic about that a few days ago.  

[princec]

Most strange. Could you try Ultratron on the dodgy machines? That's vsynced and also uses Thread.sleep(0).

Cas

[tomb]

The LWJGL timer will degrade to 14 ms resolution on some computers. Might explain what you are seeing.

[elias4444]

Yeah, Ultratron ran just fine.

I'm really looking into the Ogg Vorbis code now (the stuff that I hoarked from Tomb's site). I went through and synchronized more of the methods, as well as customizing it specifically for my purposes. After doing all that, things seem to be settling down substantially on the troubled machines. I'm still baffled by why Vsync causes that behavior, but I'm glad I'm getting it fixed.

Thanks everyone!

BTW, I would have responded sooner, but got a little caught up in testing with Ultratron.  :oops: Cas, do you make your living from making and selling those games?

[princec]

I make so little money from selling games it barely covers the hosting and the cost of the various bits of software I bought to develop them over the last few years Ultratron sells nicely by our standards (about 1 copy a day on average) but split 50/50 between me and Chaz it's never going to make us rich at $9.95 a pop!

Cas

[elias4444]

OK... I just can't get the Ogg Vorbis stuff to work without bombing out on occasion... What do you guys use for your background music? FMOD? If so, is there an example anywhere of some FMOD background music playing code? I think I'm willing to pay the money just to make sure my stuff is stable.

[tomb]

You get crackle when you don't update the sound often enough. To solve the problem you can:
1) increase the size of dataBuffer
2) call update from your main game loop aswell as the sound update loop.

It is not unlikely that the sound thread is starved by the main thread. You can mesure the time between updates if you want to check if this is the case. If it is more than what fits in the buffer, you'll get crackly.

[elias4444]

Well, here's a few of things I've tried:

I've tried setting the OggPlayer playerThread to Thread.yield() instead of sleep. I've tried doubling the dataBuffer. I've tried setting it to MAX_PRIORITY (which kills my game). Any time there's something else doing something with the CPU or hard-drive, the sound crackles and sometimes just bombs out completely. I've set the system to throw the error and to restart the music, but discovered that after a long time of playing, the game just locks up. I've also tried not using it as a seperate thread, and placing the update() directly into my game loop, but the exact same problem still occurs. I've tried Cas' games, but they don't seem to have the problem. Any ideas? I'm desperate. I was only about a week or two away from release.

[elias4444]

Ok, I've spent a hours on this problem, and I think I know what I did:

Often, when playing an Ogg in playInNewThread(), upon release() it would bomb out with an OpenALException for the Update() routine. It looks like it does that because once it's released, the buffers are cleared, but update() is still called. I had originally fixed that synchronized some of the other methods, so that they would fire in order (hence why it became so CPU dependant). Instead, I've now placed a try-catch sequence around the update() method, so, in case of an error, the catch statements tells the method to return a "false". So far, so good. Man, I hope this works. If I'm off-base on this solution, please let me know. This OpenAL stuff just baffles me at times.

[elias4444]

Ah HA!!! The reason why it happens with Display.sync() is because my application isn't trying to hog up enough CPU cycles! The OggPlayer takes over the CPU whenever it begins to refill it's buffer! SO... How do I make sure that my game will not get choppy when OggPlayer goes to refill the buffer? I've discovered that I can't set OggPlayer to anything less than MAX_PRIORITY however, as otherwise it'll timeout while trying to fill the buffer.

Do you guys set your games also to be MAX_PRIORITY? Or is that bad?

[princec]

Very bad indeed!!

I'm having no trouble at all when I'm just spinning on a Thread.sleep(0) in my main loop - it leaves the sound thread enough time.

Cas

[elias4444]

Ok, some questions then... because I'm getting crackling sound all over the place.

Does it matter where in the loop you call Thread.sleep(0)?

How do you start your game? (What's your "main" function like)? Do you start your game in it's own thread? Change it's priority?

How do you implement synched frames? I'm currently using Display.sync(true). Should I use the per-loop method?

I've tried Thread.sleep() and Thread.yield, but my sound just likes to crackle a lot.

[elias4444]

New interesting observation (hopefully it helps)...

When the sound crackles, the CPU is no where near 100% utilization... it's around 34%.

If that thread has max_priority, shouldn't it be using the CPU if it's having troubles grabbing the sound?

Update: And when Vsync is off, I'm hitting 100% CPU, and the crackling goes away.  Any ideas now?