bsnes vsync development thread

King Of Chaos · Post by **King Of Chaos** » Sun Aug 17, 2008 11:34 pm

Is it just me, or does everything seem to lag a little while Synchronize Video is on? I swear, especially when playing Super Mario World, it kinda seems laggy when jumping and moving.

EDIT: Fixed all problems by enabling vertical sync for my ATI card. I can enable Scale2x and HQ2x with no problems or lag. However, using the NTSC filter does cause a slower framerate.

Dullaron · Post by **Dullaron** » Sun Aug 17, 2008 11:35 pm

I get no more "crackle" now.

Edit: I just now tested Super Mario World. I get a small video lag when the screen move around. I very notice it.

diminish · Post by **diminish** » Mon Aug 18, 2008 12:00 am

Well, nothing helps in my case. My laptop's specs:

Intel Core 2 Duo T7300 (2 GHz, 4 MB L2 Cache);
Intel GM965 Chipset;
2 GB RAM 667 MHz;
Realtek HDAudio ALC268;
Nvidia GeForce 8600M GT 256 DDR2 VRAM + system's;
on WinXP SP3 with Realtek audio driver v2.00, monitor's frequency is 60Hz.

When only Synchronize Audio is on, it rarely cracks a little with a fps drop to 59 or 58. When both are on, video is smooth, but fps drops to ~55 every 2 or so seconds and the audio cracks, making video stutter. For example at the beginning of Super Metroid, standing on the ship, I have ~76 fps when Synchronize Audio is off (Video Filter is Linear, None; Video Mode 2x). When I turn on Synchronize Video, there is crackling and fps fluctuates like 59, 56, 58, 55, 57. Increasing Latency or/and SNES input freq even to the fullest didn't change nothing.

King Of Chaos · Post by **King Of Chaos** » Mon Aug 18, 2008 12:04 am

diminish, set your system.video option to "directdraw", and enable vertical sync in youe nvidia card's control panel and see what happens.

Like I said in my edit, I was able to fix all problems by enabling vertical sync for my ATI card, and I see no lag at all using Scale2x in Super Mario World.

FirebrandX · Post by **FirebrandX** » Mon Aug 18, 2008 12:15 am

FitzRoy wrote:
Firebrand, I was editing my post to fix that typo when you responded, your worries about 44100 were thus edited out. And yeah, if you can't get crackling below 32100, then my suggestion must change to 32000-32200, with 32100 as default. But that's confusing, are you saying this new build didn't benefit you at all? Because 32130 was what you were having to use the last time.

Maybe one day, byuu and co will figure out a way to get vsync working at a flat setting close to 32040 and this extra setting can be wiped, it's kind of confusing.

Well when I tried byuu's default settings, I was getting the occasional hiccup in audio and video at the same time. Once I increased the slider to my previous magic number of 32130, the hiccups went away and I got flawless video and audio. I use fullscreen scale4x and scanlines.

diminish · Post by **diminish** » Mon Aug 18, 2008 1:08 am

After some testing, I found out that the best for my system is wgl with forced vsync in Riva Tuner (Always On) and both Latency and SNES input frequency to the fullest, but it isn't perfect. There is now slight crack but it doesn't make the video stutter and occurs every 40 seconds or so, and boy that looks awesome, especially moving backgrounds

. I can make crack less audible by increasing Prerender limit, but it introduces huge input lag. On directdraw I have the same rubbish as on direct3d (vsync on Auto or Always On). Also wgl seems faster (~83 fps wgl vs ~77 fps direct3d in mentioned SM situation; 177.79 drivers), so I think that makes it better. Oh, and CPU usage on my 'best' settings is about 60%. Nevertheless great work byuu. I'm just not sure, if when I have 200 ms latency and 32200 Hz SNES input freq, is audio way delayed or only a little?

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Mon Aug 18, 2008 2:01 am

Presumably it's delayed by a fifth of a second plus whatever delay your hardware introduces (probably negligible in comparison). Whether or not that's noticeable probably depends mainly on the game you're playing, i.e. for a fast-paced game it should be easy to notice.

FitzRoy · Post by **FitzRoy** » Mon Aug 18, 2008 2:27 am

Latency: anything between 75-200ms
Frequency (PC): 48000hz
Frequency (SNES): anything between 32050-32200

Works fine, no crackle

WinXP SP2
ATI X600SE
C2D 1.86ghz
Onboard IDT audio SigmaTel chip

Something people might want to be aware of: enabling video sync in windowed mode does not carry over into fullscreen, you have to enable it in both modes, just like the other stuff.

byuu · Post by **byuu** » Mon Aug 18, 2008 2:51 am

I can see that overall it's very difficult to configure this, and I apologize for that. But I also see that most people are managing to get it perfect anyway! I knew I could count on my userbase being above the curve :D

----------

diminish, a 2GHz Core 2 should be fast enough, but the symptoms you're describing lead me to believe it's just a tad too slow at rare times.

Some things I would suggest: overclock infinitesimally if you can. I understand if you don't want to for a SNES emulator. Also, set the process affinity (in task manager, right click on bsnes) to high. Make sure absolutely nothing else non-essential is running, perhaps even including services and virus scanning stuff. That should help prevent sudden frame dips. Next, make sure your Scale Nx is not the biggest size your display can support. Make it one smaller. That helps me immensely on Windows.

As for 200ms ... well, I won't lie and say it's fantastic, but it's probably not very noticeable to most people. My favorite example is Zelda 3. Try swinging Link's sword. You're supposed to hear it as it starts moving. When latency is bad enough, you'll hear to sword swing, and only after it's half-way to fully finished, will you hear the sound.

A skew of 32200hz, means that your emulator is running ~0.5% (less than one percent, in other words) faster than a real SNES would. Every 4-5 minutes, the emulator will be one second more ahead of where a real SNES would be.

It's impossible for the games to detect this, by the way. They think they're running at normal speed. So accuracy is preserved :)

I still think it's pointless. Amplifying past max output to compensate for shitty speakers is a dangerous allowance. And it incurs quality hits anyhow.

True, but it's at least rather uncommon. I'd be willing to implement it as an advanced UI option, like power cycle. Cap to 100% volume, unless you set expert mode. Would that be acceptable?

He says that purists want 32000, so I guess 32000,44100,48000 would also work, as 96000 is kind of pointless.

I was mainly worried about the few sound cards that use 96khz native. It's a nice way to bypass the internal sampler. Same for 48khz. It also allows you to lower the SNES input frequency by just a tiny amount, and makes audio resampling a tiny bit more precise. None of that you'll ever notice. But ultimately? Yes, it's a total waste of resources. I thought it'd be nice to add anyway. At the very least, it'll keep people from requesting it in the future. Well, at least until "192KHz" is popular :/

Maybe one day, byuu and co will figure out a way to get vsync working at a flat setting close to 32040 and this extra setting can be wiped, it's kind of confusing.

The skew setting will never go away. I agree it is confusing, though. The best we'll ever have is the value automatically calculated through some sort of calibration setting, combined with dynamic adjustment of the value.

What that skew does, is cause both the SNES video and audio rate to exceed the PC's video and audio rate. It also ensures there is more audio than video. This means that so long as our audio buffer is large enough, even a full ~16ms wait for vsync won't deplete our buffer.

At 32040hz, we simply aren't generating enough audio, and our audio buffer will very slowly drain until it's empty, where you get a crackle and audio recovers.

The reason we can't immediately determine the value is because it's not possible to query exact timings from the monitor. Your monitor may say 60hz, but it's really 59.98-60.02hz (maybe worse), and your sound card may say 32000hz, but it's really 31980-32020hz (maybe worse.) The only way to predict these values would be a calibration tool that runs and averages the delays. The problem is that getting closer to perfection requires exponential gains in testing length. Skew differences of 5hz can take several minutes or hours before an underrun manifests itself.

I'm guessing that most emulators using this same trick rely on fixed, safe values that cause more duplicated video frames. I wanted to give you guys the option to get it as perfect as possible, and it really is something that's best done with a human touch, as confusing as it is.

The formula is essentially:
SNES refresh rate / monitor refresh rate = video skew
SNES audio rate / sound card audio rate = audio skew
SNES input frequency skew = 32000 * video skew * audio skew

blargg, please correct me if I'm wrong on that formula. Too many numbers boggles my mind x.x

But again, the problem is that you literally can't fill in the monitor and sound card rates. Even by reading hardware data sheets.

Also, SNES refresh rate varies. Non-interlace, it's 60.09hz, interlace it's 59.97hz. A value that works for 60.09hz is fine for 59.97hz, but the latter will be a tiny bit jumpier. Having the setting means you can change it when you want to play RPM Racing, for instance.

FitzRoy · Post by **FitzRoy** » Mon Aug 18, 2008 3:27 am

Thanks for explaining. Regarding the amplify, maybe you could just make an audio.amplify setting in advanced and people can put a number there from 0 to 100 which will stack on base volume settings. I still don't condone it, someone could damage their stuff.

Do you agree with anything else? The timings options should be conservative enough to work for most everyone, and be the maximums as well. Vsync should work for all when turned on, crackling should only come a result of a user scaling back to improve it, and knowing that the end of the slider was where he began if he fails. I feel that 150ms and 32200 are good numbers for this.

I was mainly worried about the few sound cards that use 96khz native.

If that's the case, my initial suggestion included 96000 rather than 32000. You'll have to explain why 32000 is more "pure" because it's still different from the base frequency. I guess it's really close, but if your resampling is good enough, there shouldn't really be a difference from upsampled frequencies. And I could not get 32000 to work with video sync enabled. Can anyone else?

byuu · Post by **byuu** » Mon Aug 18, 2008 4:26 am

Okay, some more testing. I didn't want to mess with 50hz on my (very expensive) 24" LCD, so I used Powerstrip on the old Athlon 3500+ box with a cheap 19" monitor.

Aside from displaying "OUT OF RANGE" across the center of the screen, the refresh rate really was 50hz. I was able to get perfect video and audio with Super Mario All Stars (E). And at 60hz, Estpolis Denki (J) (eg Lufia) has perfect video and audio. Both use the stock 32050hz SNES input frequency skew and 120ms latency. I didn't bother trying to lower it any.

I tried the same on my HTPC, but the 2.8GHz P4 was too slow. I can get slightly over 50FPS/PAL and 60FPS/NTSC, but with vsync or audio sync enabled, it's too slow.

Still, good news. Perfect NTSC and PAL :D

Regarding the amplify, maybe you could just make an audio.amplify setting in advanced and people can put a number there from 0 to 100 which will stack on base volume settings.

Seems so much more confusing to have two ways to adjust volume. If you really don't want the main window going to 200%, I'd prefer we make config::advanced.enable control the cap, false = 100, true = 200.

Do you agree with anything else? The timings options should be conservative enough to work for most everyone, and be the maximums as well.

Well, yes and no. The SNES skew is partially based on the monitor, and there are 59hz (and even lower) video modes. Those will require skews less than 32000hz.

I'd honestly like the range extended, but I didn't want to go for the textbox approach. Definitely not as user friendly because then they really have no idea what value to put in there.

If that's the case, my initial suggestion included 96000 rather than 32000.

I've had cheap AC'97 codecs that locked up the application when setting anything above 48khz (yes, sadly that means you can lock the current bsnes by moving the slider to the right and then playing a game.) 32khz would be good for that. Not sure why you're opposed to there being a mere five frequencies ... it doesn't really seem all that excessive, and it covers every possible usage scenario.

I haven't seen a single system that needs latency above 120ms. I like to offer it just in case, but I certainly don't want the default to be higher than 95% of users will need. Latency makes a big impression.

Hmmm, maybe we can work on extending the range such that the default values are always in the middle of the slider?

Heh, here I thought you'd have more to say about the synchronization menu option than the audio panel :)

DancemasterGlenn · Post by **DancemasterGlenn** » Mon Aug 18, 2008 5:06 am

Just got the WIP, still testing it out. I haven't actually had the chance to use a bsnes release in a while, and after compiling this one I've encountered a very odd problem: bsnes looks perfectly normal when I start it up, but when I load a rom, my window becomes very transparent. The dialog windows are not affected. I thought it had something to do with the opacity option in the advanced config, but changing that from 100 to 0 just made the dialog windows the same transparency as the roms I was playing (which makes sense, for what it was doing). Any ideas what may have set this off?

EDIT: Disabling compiz fixes the problem, but it didn't used to be an issue, if I'm remembering correctly. Might just be a compiz bug, though.

Hunter · Post by **Hunter** » Mon Aug 18, 2008 5:16 am

I've just finished a few quick tests w/ my system, using 32khz. Anything below 60ms tends to produce cracklings.

The CPU utilization increased from 30~35% to 50%. Those "problematic" games such as War of the Gems and Super Puyo Puyo 2 keep showing some flickering.

FitzRoy · Post by **FitzRoy** » Mon Aug 18, 2008 5:24 am

Seems so much more confusing to have two ways to adjust volume. If you really don't want the main window going to 200%, I'd prefer we make config::advanced.enable control the cap, false = 100, true = 200.

The expected minimum and maximum for pretty much all users is going to 0 to 100 for volume, not 10 to 200. I'm just going by hundreds of games and emulators that I've used. If this option just locks the 100 ticker in the middle, I don't like it because it will be even more puzzlesome. If it makes 100 and 200 the end of the slider depending on the enable, it's fine.

I haven't seen a single system that needs latency above 120ms. I like to offer it just in case, but I certainly don't want the default to be higher than 95% of users will need. Latency makes a big impression.

I guess that means the default and maximum can be 125ms instead of 150ms. That's the idea, you want to offer the most aggressive that works for everyone by default. The default should not be a middle number that is breaking people's vsync out of the box. Crackling audio is a far worse impression than the difference between 75ms and 125ms.

I would try to do the same for snes frequency, which is why I suggested 32200 max and default. Current range is fine then, I didn't realize the minimum needed to be that low.

Not sure why you're opposed to there being a mere five frequencies ... it doesn't really seem all that excessive, and it covers every possible usage scenario.

Many people who download your program aren't going to have a clue what they're doing. I'm opposed to 22khz because it essentially allows someone to inadvertently debase their audio quality. It has no benefit, it's as justifiable as anything below it, so why include it? Add it when this hypothetical user comes along who can't used standard rates, but not before that. And I question 32000 based on the fact that someone may set it there thinking, wrongly, that they are going to get this huge benefit of being closer to the snes frequency, when in reality it may make vsync impossible for as long as it's set there.

Heh, here I thought you'd have more to say about the synchronization menu option than the audio panel

Damn, thanks for reminding me! Yeah, why, when you have this categorical thing going with "Video" "Audio" and "Emulation" would you choose to deviate from that when you can easily keep it going with "Emulation Sync"? Sync is a word, you know, it's just a shortened version of synchronize. And the very word needs a pair of things. If I stood up and said "I'm synchronizing," everyone's going to be like "to what?" With "Emulation Sync" it is clear that "Emulation" is to "Sync to Audio."

FirebrandX · Post by **FirebrandX** » Mon Aug 18, 2008 5:40 am

In my opinion, screw the general dumbass user. I like power features with advanced settings. Ideally bsnes needs to bring back adjustable X/Y resolutions settings so I can do some 16:10 tricks like 5x4y modes, but that would all be just icing.

blargg · Post by **blargg** » Mon Aug 18, 2008 5:41 am

byuu wrote:A skew of 32200hz, means that your emulator is running ~0.5% (less than one percent, in other words) faster than a real SNES would. Every 4-5 minutes, the emulator will be one second more ahead of where a real SNES would be.

If the PC's display is running at 60 Hz, and you're synchronizing smoothly to it, isn't the emulated SNES running slower than it should? (60 Hz vs 60.09 Hz) I thought that you were basically interpolating extra samples, causing the sound pitch to lower slightly, so that the emulated SNES runs slower in both video and audio. This way the emulator is slightly SLOWER than 60 Hz, so that you occasionally get a frame displayed for two host display refreshes, rather than the equivalent in audio, which is insertion of silence.

byuu wrote:
Maybe one day, byuu and co will figure out a way to get vsync working at a flat setting close to 32040 and this extra setting can be wiped, it's kind of confusing.
The skew setting will never go away. I agree it is confusing, though. The best we'll ever have is the value automatically calculated through some sort of calibration setting, combined with dynamic adjustment of the value.

What's REALLY going on here is that we're adjusting to the host PC's EXACT display refresh and audio rate, since those differ very slightly from the ideal 60 Hz and 44100/48000 Hz. What's being adjusted is the emulator's compensation for the ratio of the deviations these have.

The ideal SNES video runs at 60.09 Hz and audio runs at 32040 Hz. bsnes then slows this down slightly so that they run at 60 Hz/31992 Hz. Then it resamples the audio to the sound card's claimed rate, 44100/48000/whatever Hz. The audio/video synchronization adjustment should be expressed as a factor, where 1.0 is ideal. This factor adjusts the 31992 Hz rate very slightly up or down, WITHOUT affecting the video rate.

If the sound card actually plays fewer samples than claimed, the factor needs to be lowered. If the PC video ran at slightly more than 60 Hz, the factor would need to be decreased as well. So the factor represents audio:video deviation. It could be expressed as a percentage, from -10.00% to +10.00%, with a slider to control it. There's no need to expose integer values that depend on the fixed-point resampler.

Here's a concrete example for clarity:

Ideal SNES: 60.09 Hz video, 32040 Hz audio
Target PC: 60 Hz video, 48000 Hz audio

We want smooth video, so we slow the SNES down to 99.85% of normal. The audible effect will be unnoticeable.

Slowed SNES: 60 Hz video, 31992 Hz audio

Then we just resample the audio to 48000 Hz from the effective 31992 from the emulator, using an interpolator rate (step) of 0.6665.

Let's say the user doesn't know his PC's exact video and audio rates. It claims 60 Hz/48000 Hz, but that has problems. So he just adjusts the synchronization factor slider to the left/right of center until audio clicks are eliminated, and doubled video frames are eliminated (look like slight pauses in scrolling). The closer to ideal, the more demanding it is on the video and audio rates being really stable, and bsnes not losing processor time to other tasks.

EDIT: corrected interpolator rate. Thanks for catching this error, grinvader.

FitzRoy · Post by **FitzRoy** » Mon Aug 18, 2008 6:06 am

FirebrandX wrote:In my opinion, screw the general dumbass user.

Right, because it's great having people running around setting their audio to 22500 and 300% volume thinking this newfound power has made their game better when it's done the exact opposite. Or hey, how about the endless stream of questions from them that I'd be answering here when the useful options are so poorly worded and knee deep in bloat that they couldn't find them.

"Derr, why is my savestate not loading properly, how come too is my sound strange in da Chrono trigger cave. I spent the last hour in the audio section! I tried cubic spline, what is that! I tried all the options. And my graphics packs aren't loading at all, I SET THE PATH RIGHT I KNOW I DID. WHAT IS JMA WHAT IS NSRT> HELp!"

See much of that in the bsnes forum? No, and thank god.

byuu · Post by **byuu** » Mon Aug 18, 2008 6:16 am

bsnes looks perfectly normal when I start it up, but when I load a rom, my window becomes very transparent.

Yeah, isn't that neat? Something screwy with SDL. I think it looks pretty cool, but impractical. Set system.video to "glx" if you have OpenGL acceleration, or to "xv" if not.

Note that your video card driver control panel, probably nvidia-settings, controls sync to vblank. It ignores the software commands on Linux. No idea whose genius idea it was to ignore what the software program requests and bury it in driver config panels that require software program restarts to take effect. Also set system.audio to "alsa" or "openal". That'll get you the best experience.

Compiz seems to need to be off for "xv", but not for "glx". I can't match a 32-bit visual with Xv. If you do use OpenGL + Compiz, be sure to set advanced -> misc.opacity to 75 or so and restart. Really cool looking glass effect in the configuration windows :D

The expected minimum and maximum for pretty much all users is going to 0 to 100 for volume, not 10 to 200.

I'm not going to allow audio to be lowered to 0. I'll get idiots complaining that "mute audio" has no effect, because they set the volume to zero. No need for two ways to do the same thing, and I want a quick way to turn off audio without going into another window.

I guess that means the default and maximum can be 125ms instead of 150ms.

And what if there's cards that need more? No reason to ignore the ~5% edge case users, nor to make the ~95% average case users suffer higher default latencies.

I would try to do the same for snes frequency, which is why I suggested 32200 max and default.

32200hz would be way too much for the general case, it would cause duplicated video frames every 2-4 seconds. It's almost better to leave vsync off at that point :/

This is why I like the idea of putting general case in the middle. That way extreme cases either way aren't left in the dark.

I'm opposed to 22khz because it essentially allows someone to inadvertently debase their audio quality.

Honestly ... I agree. 22khz is the only one that really does decrease fidelity for no real gain. If your card can't set 44khz, then you probably can't run bsnes anyway. Alright, I'll remove 22khz.

A slider with four options is really pushing it, though. Maybe we should group that and one other option into two combo box dropdowns, and leave two sliders ...

Volume seems like one that people like lots of fidelity, and the SNES skew is obviously important to be very precise ... so how about we make latency a dropdown as well?
Have like: {20, 30, 40, 50, 60, 70, 80, 90, 100, 120, 140, 160, 180, 200} ?

Put those two at the top, then volume and SNES skew below as sliders.

when in reality it may make vsync impossible for as long as it's set there.

Video+audio sync at 32khz works just fine on all of my PCs ... hmm ... well, I guess there's not a whole lot of point to it. It is nice offering it though. It's the closest to the real SNES hardware rate, and a lot of people not in the know might even desire that out of habit. If they set it and suddenly audio breaks up, they'll know immediately why. Settings take effect in real-time.

If I stood up and said "I'm synchronizing,"

And "I'm syncing" would make you look less weird? :P
"And now for the next Olympic event, synced swimming!"

All in good fun. Seriously though, what about another name for "Emulation Speed", so we can list "sync to video" / "sync to audio" inside that menu at the bottom?

"Emulation Shit ->"
"50%"
"100%"
"..."
"----"
"Sync to video"
"Sync to audio"

in my opinion, screw the general dumbass user. I like power features with advanced settings. Ideally bsnes needs to bring back adjustable X/Y resolutions settings so I can do some 16:10 tricks like 5x4y modes, but that would all be just icing.

That's what the advanced panel is for :P
Look at video.ntsc/pal_aspect_x/y. You can control the ratios there. Do some fancy maths and you can make it get really close to filling the screen. The only thing I don't allow is arbitrary Y scaling, because it completely destroys the scanline filter and makes the other 2x filters look a lot worse.

It could be expressed as a percentage, from -10.00% to +10.00%, with a slider to control it. There's no need to expose integer values that depend on the fixed-point resampler.

Thanks for the clarifications. Amazing I got it working while still not understand how, heh.

Anyway, I do like the +/-% more for readability. The reason I avoided that was because the percentages will have more rounding issues. I either use too small of an adjust rate and multiple values resolve to the same skew, or I use too large of one and it starts skipping by more than 1 for each adjustment.

I could also leave the internal slider as a number from 31800-32200, and print 32000 / N% as a fraction for the display. But then it'll probably step in non-even increments in each direction. Might annoy people with OCD trying to get a whole number or something :P

Also, since 32050 works so much better in the general case ... should I fake it and list that as +0.0% / 100%, or should I make it start at +0.0003%?

See much of that in the bsnes forum? No, and thank god.

That's because the system requirements alone chase off all the casual gamers. And if not, there's always a lack of: save states, extra peripherals, SuperFX and SA-1 support to finish them off ;)

Of course, the GUI really is quite nice, too. Your advice is a lot like Derrick Sobodash's. I absolutely hate it when it's given to me, but when I finally give in and add it all, the end result really is nice. But don't think I'm just going to hand over free reign without a fight. I have an ego to protect here :P

FirebrandX · Post by **FirebrandX** » Mon Aug 18, 2008 7:06 am

byuu wrote:

That's what the advanced panel is for
Look at video.ntsc/pal_aspect_x/y. You can control the ratios there. Do some fancy maths and you can make it get really close to filling the screen. The only thing I don't allow is arbitrary Y scaling, because it completely destroys the scanline filter and makes the other 2x filters look a lot worse.

I've never liked the ratio-stretching system you used because it doesn't allow me to simply scale the resolution. For example, I want the horizontal res scaled 5 times, while the virtical res is scaled 4 times. There's no easy way to do that with your ratio system since it uses arbitrary numbers and is not telling me exactly what the resolution output will be. I just want to use multiples of the original resolution, or be able to set the resolution myself since I know to keep the virtical in exact multiples for scanlines.

Edit: also there's a bug with the status bar showing up after I switch a couple times from fullscreen to window and back again. It will get to where I can hit escape to get rid of the menu, but then the status bar pops on the bottom. Hitting escape after that just toggles between the two and you can never get rid of both.

DancemasterGlenn · Post by **DancemasterGlenn** » Mon Aug 18, 2008 7:16 am

byuu wrote:Yeah, isn't that neat? Something screwy with SDL. I think it looks pretty cool, but impractical. Set system.video to "glx" if you have OpenGL acceleration, or to "xv" if not.

Thanks byuu, I had completely forgotten about setting it to "glx" and not "opengl". It's working fine now.

Note that your video card driver control panel, probably nvidia-settings, controls sync to vblank. It ignores the software commands on Linux. No idea whose genius idea it was to ignore what the software program requests and bury it in driver config panels that require software program restarts to take effect.

What you're saying here is simply that I had to restart bsnes to see this change, yes? Because I do have sync to vblank on in nvidia-settings, and I did need to restart bsnes after changing to glx. I think that's what you said.

Also set system.audio to "alsa" or "openal". That'll get you the best experience.

I read some of the previous changes that were being added to make alsa better. Is choosing oss really giving higher latency than straight alsa now?

If you do use OpenGL + Compiz, be sure to set advanced -> misc.opacity to 75 or so and restart. Really cool looking glass effect in the configuration windows :D

Yes, very nice :D

But don't think I'm just going to hand over free reign without a fight. I have an ego to protect here :P

Thank Jeebus.

FirebrandX · Post by **FirebrandX** » Mon Aug 18, 2008 7:45 am

Byuu, I got to the bottom of the bug with the status bar. If you close bsnes with the menu turned off, the next time you open bsnes, the status bar will become counter-toggled from the menu bar. The sounds like there is a missing initialization check for the status bar in the code.

Also, I've done some more experimenting with your ratio system and found I cannot get the arbitrary values to equal an output res of 1280x896.

EDIT: I've found a set of numbers that give me 1280x896. They are 5878 and 4700. I must say though, this is a rather bizarre way of trying to set a custom res!

EDIT 2: I found I can lower my latency all the way down to 80ms by keeping the SNES samples slider set at 32131. I tried 70ms and there was an A/V hiccup once every minute or so. Still, 80ms is not bad at all!

Dullaron · Post by **Dullaron** » Mon Aug 18, 2008 7:50 am

I fix the video skipping when the screen move.

I enable 2 things on bsnes and enable NVIDIA Control Panel which was disabled somehow.

Do I need to put something on system.audio?

edit: 1 problem when using directdraw? Linear seem to be broken. Should it be blurry? It showing the same thing on Point setting.

FitzRoy · Post by **FitzRoy** » Mon Aug 18, 2008 8:10 am

byuu wrote: And what if there's cards that need more? No reason to ignore the ~5% edge case users, nor to make the ~95% average case users suffer higher default latencies.

I'm not convinced there is an edge case, I think 125ms is a playable standard for anyone that will incur no crackling, and that having an option to make it as low as 25ms is just a bonus for the advanced users who want to try. Course, we won't know if there are any edge cases unless this happens and they get reported.

32200hz would be way too much for the general case, it would cause duplicated video frames every 2-4 seconds. It's almost better to leave vsync off at that point :/

Are you saying this based on what you see or based on some external calculations? Because I'm using this setting right now, running around in Super Mario World, and I can't see these dupe frames. In any case, if this maximum induces unacceptable costs worse than tearing then it shouldn't be the maximum, there should be a lower maximum. Remember, I only resist your middle default theory because I honestly don't think people know whether left or right is going to make things better. With a maximum as default, the only thing that can go wrong is dupe frames and they'll know that left is how to fix it because it's the only direction you can take.

A slider with four options is really pushing it, though. Maybe we should group that and one other option into two combo box dropdowns, and leave two sliders ...

Nah, looks fine.

And "I'm syncing" would make you look less weird?

What I was trying to say is that you don't synchronize something, you synchronize something to something else. Audio isn't being synced in a vacuum, something is syncing to audio. Emulation Speed? Ah, so that's where it should go...

All in good fun. Seriously though, what about another name for "Emulation Speed", so we can list "sync to video" / "sync to audio" inside that menu at the bottom?

Seems like that's a good name already. Since they have their own checkmarks, they should be divided. Unless you want to force vsync by combining them into one. And you might want to put them at the top, since they act like an override for the other options. If both are off, for example, and the checkmark is at 100%, speed will be uncapped despite the checkmark. A little confusing, but that's what you get for having these percentage options.

creaothceann · Post by **creaothceann** » Mon Aug 18, 2008 9:24 am

I get a relatively stable 30/30 fps here (emulation speed 50%). Oh well.

tetsuo55 · Post by **tetsuo55** » Mon Aug 18, 2008 10:15 am

byuu wrote:At the very least, it'll keep people from requesting it in the future. Well, at least until "192KHz" is popular :/

My card actually has native support for 24bit-192KHz stereo, this is actually the DAC's native resolution.

When more than 2 channels are used, internally everything gets downsampled to 24bit-96khz if 192 is used.

At what bitrate is bsnes (btw i am dumb) outputting? can i select 24bit so i don't get any resampling?

blargg wrote: Here's a concrete example for clarity:

Ideal SNES: 60.09 Hz video, 32040 Hz audio
Target PC: 60 Hz video, 48000 Hz audio

We want smooth video, so we slow the SNES down to 99.85% of normal. The audible effect will be unnoticeable.

Slowed SNES: 60 Hz video, 31992 Hz audio

Then we just resample the audio to 48000 Hz. There's no need to resample twice, from 32040 to 31992, then to 48000, so we just resample once from 32040 to 48000 Hz, using an interpolator rate (step) of 0.6675.

That actually sounds very good and logical, Byuu are you already doing it like this??