Hello Alexandre, hello Brad, Brad Smith wrote on Sun, Jan 26, 2025 at 07:28:26PM -0500: > On 2025-01-21 7:19 a.m., Alexandre Ratchov wrote:
>> Sometimes the audio increase/decrease volume command are stuck to a >> fixed value. This diff fixes this problem. >> >> The hot-keys for above commands are the volume keys of multimedia >> keyboards. These keys are already used by the OpenBSD kernel for other >> volume adjustments; probably, that's why this problem stayed >> unnoticed. Actually, it wasn't unnoticed. For a long time, it feels like multiple years, i was aware of the fact that on my T550, the sound volume hotkeys (F2, F3) did change the volume of the sound emitted by the built-in speaker (considering your explanation, i now think that was likely due to them being interpreted by the kernel driver), but the volume percentage displayed by vlc(1) changed only after the first volume key press in any given direction, so it typically sat at 95% after reducing the volume (no matter how much) and at 100% after increasing the volume (no matter how much). Sometimes, the sound volume was low, but the volume key did not help at all (i now believe that was when the kernel driver was already at full volume). In that case, as a workaround, i moved the volume slider at the bottom of the vlc(1) window with the mouse. Since volume control seemed to (more or less) work, without really thinking about it, i always assumed this was purely a GUI display problem, which was apparently wrongly jumping to conclusions. I further assumed nobody would be interested in hacking on something as disgusting as the GUI of a GUI application program, so i never reported it. Sorry for that. >> OK? I have no idea what that code does, but it compiles for me on amd64 (not cleanly, there are huge amounts of compiler warnings in the build log, but it finished successfully anyway), and it packages, installs, and runs cleanly. Your patch also solves my long-standing problems described above. Alors, merci beaucoup! :-D Hence, OK schwarze@ for whatever that may be worth (if you think an OK purely based on testing with no code review is meaningful). > I can't test this. But I guess it's Ok. > > Also what about the comment just below this in Open(). > > |/* FIXME:set volume/mute here */| > > Does anything else need to be done there or should the comment > simply be removed? No idea, and i don't know whether the following is related. I often run with settings looking roughly like this: $ sndioctl input.level=0.486 input.mute=0 output.level=0.471 output.mute=0 server.device=0(azalia1) app/vlc0.level=1.000 When i now use the the volume keys outside vlc(1), the output.level changes as i would expect. When i use the volume keys inside vlc(1), all of the sound volume, the percentage displayed by vlc(1), and the output.level displayed by sndioctl(1) change in the expected direction. However, the app/vlc0.level displayed by sndioctl(1) always remains at 1.000, which feels dubious (or maybe that's right - i'm not sure). Furthermore, when vlc(1) starts up, the volume percentage it displays is always 100%, even when sndioctl(1) reveals that the kernel driver is set to a very low output.level. In that situation, pressing the "volume up" key results in louder sound and higher output.level (which both feel right), but vlc(1) displays a percentage of 105% (which feels weird). Pressing the "volume up" key again results in even louder sound and even higher output.level (which still both feel right), but the percentage display in vlc(1) remains stuck at 105% (which can hardly be right). When it is stuck at 105%, pressing the "volume down" key repeatedly results in displaying percentage values of 100%, 95%, 90% and so on. The end result is that the percentage displayed by vlc(1) is urelated to the actual volume - only the direction in which the percentage display changes is meaningful, and even that only holds in the subset of cases where it changes at all. But even if you plan to investigate further, it might make sense to commit what you already have right away, because that's already a clear improvement. Yours, Ingo >> Index: Makefile >> =================================================================== >> RCS file: /cvs/ports/x11/vlc/Makefile,v >> retrieving revision 1.278 >> diff -u -p -r1.278 Makefile >> --- Makefile 17 Nov 2024 15:02:05 -0000 1.278 >> +++ Makefile 21 Jan 2025 12:05:05 -0000 >> @@ -9,7 +9,7 @@ CATEGORIES= x11 >> SITES= https://download.videolan.org/pub/videolan/vlc/${V}/ >> EXTRACT_SUFX= .tar.xz >> REVISION-jack= 0 >> -REVISION-main= 0 >> +REVISION-main= 1 >> >> USE_NOBTCFI= Yes >> >> Index: patches/patch-modules_audio_output_sndio_c >> =================================================================== >> RCS file: /cvs/ports/x11/vlc/patches/patch-modules_audio_output_sndio_c,v >> retrieving revision 1.6 >> diff -u -p -r1.6 patch-modules_audio_output_sndio_c >> --- patches/patch-modules_audio_output_sndio_c 1 Aug 2024 11:28:01 >> -0000 1.6 >> +++ patches/patch-modules_audio_output_sndio_c 21 Jan 2025 12:05:05 >> -0000 >> @@ -1,5 +1,6 @@ >> Use sio_flush() instead of sio_stop() to improve controls responsiveness. >> >> +Report the the actual volume, fixes volume increment/decrement. >> Index: modules/audio_output/sndio.c >> --- modules/audio_output/sndio.c.orig >> +++ modules/audio_output/sndio.c >> @@ -12,3 +13,20 @@ Index: modules/audio_output/sndio.c >> sys->started = 0; >> sys->delay = 0; >> sio_start (sys->hdl); >> +@@ -276,6 +276,8 @@ static int VolumeSet (audio_output_t *aout, float fvol >> + if (!sys->mute && !sio_setvol (sys->hdl, volume)) >> + return -1; >> + sys->volume = volume; >> ++ aout_VolumeReport (aout, (float)sys->volume / SIO_MAXVOL); >> ++ aout_MuteReport (aout, sys->volume == 0); >> + return 0; >> + } >> + >> +@@ -287,6 +289,7 @@ static int MuteSet (audio_output_t *aout, bool mute) >> + return -1; >> + >> + sys->mute = mute; >> ++ aout_MuteReport (aout, mute); >> + return 0; >> + } >> +
