C++ Monitoring OSS/mixer

charlie137 · 2026-02-09T18:38:19+0000

Is there a way to listen for volume changes? I wrote an OSS service for Quickshell, which relies on manual controls refresh. It would be nice to drive signals through events, but kqueue cannot listen for mixers, and devd does not emit any mixer-related events.

services/oss: add freebsd sound module by charlesrocket · Pull Request #474 · quickshell-mirror/quickshell

This adds OSS support on FBSD targets. Tested with Realtek ALC257 (Analog 2.0+HP/2.0)> on hdaa0 (play/rec) (default), T480 (FreeBSD 15.0-RELEASE-p1 GENERIC). // audio RowLayout { spacing: 8 ...

github.com

kent_dorfman766 · 2026-02-09T22:44:14+0000

define what you mean by "volume change". Are you referring to someone manually changing the volume level, or the loudness of the source changing?

charlie137 · 2026-02-10T00:21:19+0000

kent_dorfman766 said:
define what you mean by "volume change". Are you referring to someone manually changing the volume level, or the loudness of the source changing?

the loudness/muteness of the source

unitrunker · 2026-02-10T01:08:20+0000

Take a look at how mixertui does this. I'm guessing it polls the mixer controls. Run two instances of mixertui, change one of the volume controls in one mixertui instance, and see the change also take place in the other instance. If so, you can model your code after mixertui.

charlie137 · 2026-02-10T01:58:31+0000

unitrunker said:
Take a look at how mixertui does this. I'm guessing it polls the mixer controls. Run two instances of mixertui, change one of the volume controls in one mixertui instance, and see the change also take place in the other instance. If so, you can model your code after mixertui.

I am trying to avoid polling, (in this case) this should be done in the QML if required (better control, less code to maintain).

unitrunker · 2026-02-10T06:19:43+0000

Polling isn't as bad as it sounds. Most of the time these controls don't change. Somewhere between 5 and 30 times a second should be more than enough. You could write a polling agent that fires the events you desire when the agent detects changes.

charlie137 · 2026-02-10T13:56:58+0000

unitrunker said:
Polling isn't as bad as it sounds. Most of the time these controls don't change. Somewhere between 5 and 30 times a second should be more than enough. You could write a polling agent that fires the events you desire when the agent detects changes.

I am not saying it is bad (tho I always tend to avoid it). It's just out of scope here. QS does not poll anything, so if the user wants to poll audio values, it has to be done at the QML level. Timer is a perfect component for polling, and my module has refresh() just for this:

Code:

MouseArea {
    id: hoverDetector
    anchors.fill: parent
    hoverEnabled: true

    onEntered: {
        OSS.refresh();
        volumeMenu.show = true;
    }

    onExited: {
        volumeMenu.timer.start();
    }

    onClicked: {
        if (root.control) {
            root.control.muted = !root.control.muted;
        }
    }
}

kent_dorfman766 · 2026-02-10T18:27:04+0000

When op clarified "loudness or muteness of the source" that precludes "kernel event trapping" and moved into the realm of DSP programming and pattern filtering of PCM data. loudness of a PCM signal is directly related to the amplitude of the PCM values being sent/received and is a function of the mean/average of their amplitude. That type of analysis is not a function of OSS or kernel drivers: ie looking for quiet spots in an audio stream. So, it becomes a user mode programming problem, addressed through a sound pipeline.

charlie137 · 2026-02-10T20:25:30+0000

kent_dorfman766 said:
When op clarified "loudness or muteness of the source" that precludes "kernel event trapping" and moved into the realm of DSP programming and pattern filtering of PCM data. loudness of a PCM signal is directly related to the amplitude of the PCM values being sent/received and is a function of the mean/average of their amplitude. That type of analysis is not a function of OSS or kernel drivers: ie looking for quiet spots in an audio stream. So, it becomes a user mode programming problem, addressed through a sound pipeline.

okay to be more clear, i am looking for a way to "subscribe" to `mixer` changes (which are sound levels (loudness in this context) and mute states). DSP would be a completely different (higher) level. the linked pull request should highlight the scope i am in.

kent_dorfman766 · 2026-02-10T21:11:13+0000

charlie137 said:
okay to be more clear, i am looking for a way to "subscribe" to `mixer` changes (which are sound levels (loudness in this context) and mute states). DSP would be a completely different (higher) level. the linked pull request should highlight the scope i am in.

OK. That makes it clear what you are trying to do. IMHO, as much as I don't like the linux sound daemons infrastructure, their way of handling things would make your job much easier: a sound daemon that ALL OSS must go thru, and where you can intercept and/or filter sound related functions.