virtual_oss.h is required to interact with "/dev/dsp.ctl", that can be used by 3rd party apps, like gtk-mixer: https://github.com/rozhuk-im/gtk-mixer
(In reply to Ivan Rozhuk from comment #0) I'm not sure I understand. What are you trying to do exactly that requires virtual_oss.h?
(In reply to Christos Margiolis from comment #1) It is used inside: https://github.com/rozhuk-im/gtk-mixer/blob/master/src/plugin_oss3.c "/dev/dsp.ctl" have ioctl interface (nice to have man/doc for this), this is used to interact with virtual_oss. In case of gtk-mixer - it switch input and output devices without virtual_oss restart. Also it get current input and output devices.
(In reply to Ivan Rozhuk from comment #2) I don't see where the virtual_oss ioctl interface is being used here. It is just using the OSSv4 mixer interface. Also even if it did use virtual_oss internally, I wouldn't advise hardcoding "/dev/dsp.ctl" - this device is created by the user and can have any name. As a convention, we tend to name the "default" control device as "/dev/vdsp.ctl", but even this is not ideal, to be honest. I want to make this more robust at some point.
I do forgot to push local changes :)
So, I've actually recently pushed three patches [1][2][3] recently. Do these cover your use case? Specifically [3] removes from mixer(8) something very similar to what you're trying to do. [1] https://cgit.freebsd.org/src/commit/?id=d40189f8259e3565c69a40194f7b603d0ca648de [2] https://cgit.freebsd.org/src/commit/?id=428517a7712e44b58e0687fbee4037a8ebe5bf5a [3] https://cgit.freebsd.org/src/commit/?id=d00b32c2d70ce79fddb94dd990d2b162c8fc3a85
gtk-mixer is GUI tool that allow to user change vol, select output devices. mixer is TUI tool for same purposes. No, it does not cover what gtk-mixer do. 1, 2 - may help gtk-mixer to not poll sysctl for default dsp dev. 3 - removes ability to set separate playback/capture devices from mixer. 1,2 - interesting change that I will assimilate into gtk-mixer. Also you can add some thing like mtime change or read event for mixer devices on change, for now I use polling (read value every X second) to detect volume change. Also virtual_oss does not have any events to notify about changes inside it runtime config.
(In reply to Ivan Rozhuk from comment #6) > No, it does not cover what gtk-mixer do. You can do what mixer(8) did, and simply fork() and use virtual_oss_cmd from your application, instead of ioctl(). virtual_oss_cmd is a wrapped for VIRTUAL_OSS_ADD_OPTIONS anyway, so you can just use it. I don't think there is good reason (yet) to expose virtual_oss.h. > 3 - removes ability to set separate playback/capture devices from mixer. The interface was quite complicated to begin with, and I doubt anyone ever used it to be fair. It really is way simpler to just use virtual_oss_cmd directly. > Also you can add some thing like mtime change or read event for mixer devices on change, for now I use polling (read value every X second) to detect volume change. Why would introducing complexity to the kernel be better than doing the simplest thing and just read every X seconds?
(In reply to Christos Margiolis from comment #7) > use virtual_oss_cmd from your application, instead of ioctl(). ioctl - 3 syscalls, virtual_oss_cmd - heavy fork with a lot of syscalls. Since there is no kernel event to detect that device changed in virtual_oss. I do not want every 1-2 second run virtual_oss_cmd. > It really is way simpler to just use virtual_oss_cmd directly. I want GUI, not TUI. I want low res GUI, that do not fork 100500 tools on every mouse move. > The interface was quite complicated to begin with, and I doubt anyone ever used it to be fair. FBSD have very small user base, this argue can be used for everything. I am trying to do things that was done in windows 25 years ago: select playback and capture device using GUI by mouse clicking, and allow to select playback and capture device from different H/W backends, like HDMI playback + WebCam capture. Why this simple thing must be done with wasting of time with virtual_oss_cmd? Where is usability!? User friendly? > Why would introducing complexity to the kernel be better than doing the simplest thing and just read every X seconds? Because it is silly. In that way we should remove inotify(), kqueue(), poll(), select() and just poll every socket and file descriptor, or press F5/refresh in file manager. Probably you should start to use FreeBSD on your workstation in dualboot with windows to see difference in user experience for basic every day things.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d15987cc06192f78a31040f2c142bcaf88e8a1ee commit d15987cc06192f78a31040f2c142bcaf88e8a1ee Author: Christos Margiolis <christos@FreeBSD.org> AuthorDate: 2026-03-04 18:06:17 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2026-03-04 18:06:17 +0000 virtual_oss(8): Expose ioctl interface PR: 293545 Sponsored by: The FreeBSD Foundation MFC after: 3 days usr.sbin/virtual_oss/virtual_oss/Makefile | 2 ++ 1 file changed, 2 insertions(+)
(In reply to Ivan Rozhuk from comment #8) > I want GUI, not TUI. > I want low res GUI, that do not fork 100500 tools on every mouse move. There is a difference between forking 100050 tools, and forking 1. > Why this simple thing must be done with wasting of time with virtual_oss_cmd? Where is usability!? User friendly? The reason I'm pushing back is not to say that "we won't do that", I'm just trying to understand the benefit. The user-friendliness argument here does not make any sense because the user doesn't know if you used fork() & exec() or ioctl() internally. That being said, I will agree with you on the polling part, because unlike mixer(8), your application also wants to show real-time state through VIRTUAL_OSS_GET_SYSTEM_INFO, and exec()'ing virtual_oss_cmd and fetch parsing the string to get that info, is indeed stupid. Here's the patch: https://cgit.freebsd.org/src/commit/?id=d15987cc06192f78a31040f2c142bcaf88e8a1ee
Thanks, hope it will become as part of OS = also will have man/doc. > The user-friendliness argument here does not make any sense because the user doesn't know if you used fork() & exec() or ioctl() internally. I spend a lot of time to optimize xfce4-taskmanager, so it reduce CPU usage from ~5% to less 1%. It was big deal for me while it run on core duo. User does not care how it work until start to watch CPU usage or "expected run time" on battery or get low FPS/lags of GUI.
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0351c21f4f6b45c1003facf6410645763d4cfcf9 commit 0351c21f4f6b45c1003facf6410645763d4cfcf9 Author: Christos Margiolis <christos@FreeBSD.org> AuthorDate: 2026-03-04 18:06:17 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2026-03-07 23:45:03 +0000 virtual_oss(8): Expose ioctl interface PR: 293545 Sponsored by: The FreeBSD Foundation MFC after: 3 days (cherry picked from commit d15987cc06192f78a31040f2c142bcaf88e8a1ee) usr.sbin/virtual_oss/virtual_oss/Makefile | 2 ++ 1 file changed, 2 insertions(+)