bsnes v0.032 released

[FitzRoy]

C

In the only cases where you would arguably need anything between full and nothing (running a second sound program while running bsnes but still wanting to hear what you're doing ingame), even a giant ugly list of subjective presets is not going to be sufficiently flexible.

Inconvenience from not having mute in the menu can only exist if you manage to have all of these characteristics:

a) you need to mute and unmute more than once every hour
b) your muting is needed while gaming (else pause emulation would work)
c) your muting is needed for bsnes specifically, else a systemwide hotkey could be set up externally

[byuu]

I'll definitely add hotkeys for volume up and down.

The main thing I was wanting to avoid was having both a mute and volume slider. If one were to set the volume to zero, mute and later unmute, it'd be kind of annoying that there was no sound. Yes, I know televisions tend to do that now, so it's not all bad, but still ... mute is the same as volume 0%, so no need to have two ways to silence audio.

Also, I tend to use mute a lot. I listen to music all the time. This isn't quite as redundant as the power cycle menu option ... I could see myself getting annoyed having to go into the config settings window all the time.

[FitzRoy]

I don't suppose you could rig the hotkeys to tap for intervals of one and move very rapidly when a hold-down is sensed? Then it wouldn't be so inconvenient for you to go from 100 to 0 and back using the hotkeys.

[creaothceann]

In that case it'd be useful to have visual feedback, e.g. the current volume displayed in the title / status bar if it's not 100%.

EDIT: Fixed.

[FitzRoy]

Speed? We're talking about volume.

[krom]

The main thing I was wanting to avoid was having both a mute and volume slider. If one were to set the volume to zero, mute and later unmute, it'd be kind of annoying that there was no sound.

I am totally with you on this, hence me going for poll option C, because it keeps the mute functionality, and optimizes the ui by removing a chunk from the Settings menu list.

There is something I have only noticed recently in bsnes that I want to ask you guys about:
If you delete the config file for bsnes so that it creates a new one, you will find it sets the statusbar and menubar to the "escape" key.
If you then untick Show Statusbar in the Misc menu (to get rid of the statusbar) and then press escape, you will see the menubar disappears and the statusbar comes back alternately.
I have to put the statusbar on another key for this functionality to seem correct for my preference of getting rid of the statusbar and pressing escape to see bsnes without the menubar.
I am obviously fine with the way this works because it makes sense why it is happening, but for a new user it might be confusing that they have unticked statusbar and pressing escape makes it alternate like this...

Also I have had another idea which might be good:
We could have a fast forward button that sets the frame skip to 9 and emulation speed to Uncapped, when the button is released it will make the emulator revert back to the original frame skip and emulation speed settings before the fast forward button was pressed.

[FitzRoy]

I will slightly agree that show statusbar should probably come unassigned by default, but I understand why it was done. People who use the statusbar want an easy way to hide both in fullscreen mode. People who don't use the statusbar are having to unassign it.

How about combining the two as a hotkey only, like the fullscreen/windowed action? Are there people who will be pissed that the only way to hide the statusbar is to hide the menubar as well?

[Deathlike2]

A hotkey seems out of place. What you want is an option to auto-hide the statusbar while under full screen.

[FitzRoy]

Hmm, seems too long to word that in the menu, and I can't think of a good place to put it other than the advanced settings, where it is likely to get missed.

[Verdauga Greeneyes]

... the advanced settings, where it is likely to get missed.

To be fair, I think most people expect the status bar to be hidden in 'full screen mode'. Little do they know it's not -true- full screen

[Deathlike2]

FS Hide Status is the best that I can do.

... the advanced settings, where it is likely to get missed.

To be fair, I think most people expect the status bar to be hidden in 'full screen mode'. Little do they know it's not -true- full screen

Most emus do this anyways.

[FitzRoy]

To be fair, I think most people expect the status bar to be hidden in 'full screen mode'. Little do they know it's not -true- full screen Wink

So you don't want it to be possible at all to see the FPS in fullscreen? Remember, bsnes has a statusbar to avoid the complexity of having to draw text in the video display area.

I don't think a hotkey is out of place, they're both bars and esc is standard behavior in many programs to hide the menu bar.

[Verdauga Greeneyes]

So you don't want it to be possible at all to see the FPS in fullscreen?

I didn't mean that, but you're right that it should be accessible. Still, status bar text is currently in the advanced options, so why not this too?

[DancemasterGlenn]

I almost never worry about framerate when fullscreened, myself (if I'm checking framerates in an emulator I almost always have it windowed), but I guess that's not true for everyone. Just seems like it doesn't take that much work to un-fullscreen to see your framerate, and if you've seen your windowed framerate you'll probably be able to tell if it's running noticeably slower in full.

I'm sure that logic isn't air-tight, but it's the way it runs in my head.

[FitzRoy]

So you don't want it to be possible at all to see the FPS in fullscreen?

I didn't mean that, but you're right that it should be accessible. Still, status bar text is currently in the advanced options, so why not this too?

I don't even know why that's there, to tell you the truth. Internal names are garbage and no one's eccentric enough to care about the order. I guess it can be used for ingame motivation.

misc.status_text = "Enough, you're embarrassing yourself!"

I do think that "%n : %f / %m" should be changed to "%n : %f / %m fps" though.

[DancemasterGlenn]

I know that would motivate me, for sure...

[tetsuo55]

As i said im my previous menu changes post, i vote for sliders option C

[RedDwarf]

This proves ALSA is junk, since compatibility is low when I tried my best to make a driver, spending several hours on it. Contrast this to the fact that I also wrote the OSS, OpenAL, and libAO drivers for bsnes too, and that I didn't spend much time on any of them, and they work great (well, except for libAO with ultra high latency).

If the ALSA driver works fine for you, great, otherwise, try something else. Odds of it working great for you are low. If you know how to fix it, byuu and myself would appreciate a patch.

By default libao ALSA backend (default at least in Debian/Ubuntu and openSUSE) uses 500ms latency, but it can be changed. Do you mean that lowering it there are problems? (web documentation is wrong in both variable name and units).

This untested (edit:now tested, works correctly*) patch should reduce latency from 500ms to 100ms

Code: Select all

--- src/lib/ruby/audio/ao.cpp
+++ src/lib/ruby/audio/ao.cpp
@@ -47,16 +47,20 @@
 
   bool init() {
     driver_id = ao_default_driver_id(); //ao_driver_id((const char*)driver)
-    if(driver_id < 0) driver_id = ao_default_driver_id(); //fallback on default if driver doesn't exist
     driver_format.bits = 16;
     driver_format.channels = 2;
     driver_format.rate = settings.frequency;
     driver_format.byte_format = AO_FMT_LITTLE;
 
-    audio_device = ao_open_live(driver_id, &driver_format, 0);
+    ao_option *options = NULL;
+    ao_info *di = ao_driver_info(driver_id);
+    if (di != NULL && !strcmp(di->short_name, "alsa")) {
+      ao_append_option(&options, "buffer_time", "100000");
+    }
+
+    audio_device = ao_open_live(driver_id, &driver_format, options);
     if(!audio_device) return false;
 
-    ao_info *di = ao_driver_info(driver_id);
     return true;
   }

But if you use libao with the OSS backend you should have the "default" latency... that should be a "normal" value.

For ALSA the patch is in the other thread. I would say it is better than the original (does pretty much the same than the ao backend), but since for some people the original worked some more testing would be good.


* But snd_pcm_hw_params_set_buffer_time_near() is exactly the function that openSUSE has patched in his RPM package. If doesn't works in your distro probably that's what the patch fixes.

[byuu]

This worked great, thank you. libao is now tolerable on ALSA. Now I just need to add support for disabling "Audio::Synchronize" (by disabling sound output, since libao is a blocking API.)

---

EDIT: posted a new WIP, with RedDwarf's ALSA and libao fixes. Both work very well for me, your mileage may vary.

No Windows binary, as it would be exactly the same as v032a, anyway. This one's mainly for Linux users who can compile from source.

[RedDwarf]

Now the stupid question. How it is that zsnes hasn't the 500ms latency when it uses libao+alsa with the default buffer size?? Is video also delayed? And if so, also controls?

[Verdauga Greeneyes]

posted a new WIP, with RedDwarf's ALSA and libao fixes. Both work very well for me, your mileage may vary.

No Windows binary, as it would be exactly the same as v032a, anyway. This one's mainly for Linux users who can compile from source.

The only changes are in ./lib/ruby/audio, right?

[byuu]

Yes. And anyone posting ports or whatever can use the new WIP as a base if they like.

[neo_bahamut1985]

What's in the new WIP?

[FitzRoy]

Look a couple posts up.