I see that there’s already a mute function, so would it be possible to add a volume up / down function too? Ideally the current volume level would be shown via RetroArch’s OSD every time it’s changed with a value between 0 and 100.
The reason being is that I set the system volume level to the maximum level I want my HTPC to play at and then I configure my remote to only control an applications native volume level (my HTPC is directly connected to an amp with no gain controls).
Yeah, I definitely agree with this. I would love to set my volume controls to mouse wheel up and mouse wheel down (one of which I have handily on the left side of my keyboard). I happen to have Windows volume up/down buttons on my keyboard also, so for me, it’s not a big deal, but for others without that luxury, such a control might be handy.
It’s been three months so I thought I’d bump this. This is functionality that would really be quite useful for me as I use RetroArch on my HTPC and it’s not ideal for me to change the system volume level.
Currently I have to try to detect when the retroarch.exe process is created and then force my system volume level down to 10% and have my remote switch to controlling this level instead. While this sort of works, it leaves me unable to see volume changes via an OSD and requires a number of changes to my EventGhost script just to get this all handled properly.
Didn’t see this until now. Anyways, implemented. Check audio_volume config. You can change volume on the fly with keypad +/-. It’s also implemented with zero performance loss, so that’s nice 
It’s dB oriented, and it allows -80 dB to +12dB.
Awesome, thanks for adding this! I think I’ll try my hand at building RetroArch from source today to test it out.
Also, after briefly looking at your commits I’m not sure if the new volume functions were made available for the external command interface (I’ve been using this method with EventGhost with good results), but correct me if I’m wrong.
It wasn’t, but now it is. Forgot it in the first commit.
With some effort I was able to get RetroArch, RetroArch-Phoenix and RetroArch-D3D9 compiled today. The compilation guide on the Wiki helped immensely, so thanks for that.
The volume controls appear to work well with using either the hotkeys or via the command interface and I’m even able to set the default volume level in retroarch.cfg, which is perfect, thanks!
On a separate note, it appears that the latest RetroArch-D3D9 driver can’t be used with the latest RetroArch version as it’s citing an API version mismatch. Out of curiosity I changed the D3D9 driver API version manually and recompiled it and it appears to work fine except for the palette being distorted. I have performance issues with the other video drivers so I guess I’ll wait for this to be resolved before I switch over to using the latest version.
The D3D9 driver was merged in some days ago. Build with HAVE_D3D9=1, and you’ll have the shiny driver. The external D3D9 driver is “dead”, the merged one is better in every way.
EDIT: Actually, you don’t need HAVE_D3D9=1 anymore, because it’s built in by default, weeeee.
For some reason I can’t get RetroArch to build with “HAVE_D3D9 = 1” until I make the following changes in the makefile:
HAVE_XAUDIO = 0 HAVE_DSOUND = 0 HAVE_NETPLAY = 0 HAVE_STDIN_CMD = 0
Yet it will build just fine without making those changes if I build with “HAVE_D3D9 = 0”.
It builds fine here from latest Git. Which errors, and what MinGW toolchain are you using? EDIT: Pushed a possible fix. Try make clean first, and see if it builds now.
OK, I switched to using MinGW-w64 and it built with no problem right out of the box (I was using the original MinGW project before). If I had known this from the beginning I could have saved myself a lot of frustration 
I did try using your recent fix with the original MinGW setup, but it didn’t seem to make a difference, but since MinGW-w64 seems to work without issue it probably doesn’t matter now.
Thanks for the help!