In D55670#1276915, @meka_tilda.center wrote:

What about alternative approach as in "ask the /dev/dsp* what is its control device"? For hardware devices the answer is NULL, for virtual_oss, it's /dev/dsp.ctl (or whatever is configured). Or maybe get devices through nvlist and /dev/sndstat and see which devices are virtual. In any case, my idea is "ask the kernel". I don't have preferences on the exact implementation.

In D55670#1276620, @markj wrote:

In D55670#1276311, @christos wrote:

I'm thinking about this again and I'm suspecting this will make things very inflexible. I think that instead of patching virtual_oss, it might be better to have an environment variable that specifies the control device name, and let devd use that. @markj What do you think?

As I understand it, the basic problem is that virtual_oss is providing a virtual audio device, and there's an associated control device, and there is no mechanism to figure out the control device name from the audio device name, aside from looking at whatever's configured in rc.conf.

Can virtual_oss create files under /var/run which provide this mapping? Similar to a pidfile, it could create /var/run/virtual_oss.dsp at startup, and the file would contain the path to the control device. Then snd.conf would contain something like action "/usr/sbin/virtual_oss_cmd $(cat /var/run/virtual_oss.${cdev}) -R /dev/${cdev}". I'm pretty sure devd can perform substitutions like that, the devd.conf man page has an example of it.

This is not diff'd against main. Also please address the other inline comment.

I'm thinking about this again and I'm suspecting this will make things very inflexible. I think that instead of patching virtual_oss, it might be better to have an environment variable that specifies the control device name, and let devd use that. @markj What do you think?

Address Mark's comment.

Fix switch case.

In D55605#1274023, @scf wrote:

In D55605#1273962, @christos wrote:

Something is messed up with the file paths here. (dev/sound instead of sys/dev/sound).

I am not sure what happened. The diff starts with:

diff --git sys/dev/sound/pcm/feeder_volume.c sys/dev/sound/pcm/feeder_volume.c
index fc4ed1bbb0a5..c1a33dcdd8a3 100644
--- sys/dev/sound/pcm/feeder_volume.c
+++ sys/dev/sound/pcm/feeder_volume.c
@@ -1,350 +1,360 @@
 /*-
  * SPDX-License-Identifier: BSD-2-Clause

I have not used git-arc, but it looks like I need to try it.

Something is messed up with the file paths here. (dev/sound instead of sys/dev/sound).

Can you please generate the diff with full context or upload it with git-arc?

By the way, there is a typo in the commit title ("vitual").

@ivy Makefile.inc defines:

PACKAGE?=	sound

Is it a problem if the inclusion is removed from here?

Neither lib/virtual_oss nor usr.sbin/virtual_oss build with this patch:

root@freebsd:/mnt/src/lib/virtual_oss # make
Building /usr/obj/mnt/src/amd64.amd64/lib/virtual_oss/null/null.pico
In file included from /mnt/src/lib/virtual_oss/null/null.c:39:
/mnt/src/usr.sbin/virtual_oss/virtual_oss/int.h:33:10: fatal error: 'samplerate.h' file not found
   33 | #include <samplerate.h>

In D54456#1248939, @zarychtam_plan-b.pwste.edu.pl wrote:

Congratulations and thanks for this great solution! It's now 100% compatible with the "WITHOUT_MODULES sound" kernel build and install knob and covers the entire sound toolkit.

@zarychtam_plan-b.pwste.edu.pl @rozhuk.im-gmail.com Opinions?

Should this be committed now?

In D54360#1244384, @meka_tilda.center wrote:

In D54360#1244383, @christos wrote:

The USB stack seems to have a default kqfilter method,so I suppose this is why it works. Does it work properly though?

Almost perfectly in my testing. Problem is that kevent.data is always 0 and as kqueue is advertised as "after the fact" eventing system, it would be nice to get the event after all 3 bytes are ready. I'm speaking strictly about notes and controllers, but similar is true for any MIDI message: I'd like to receive event once the whole message is ready. In this code you'll notice I read 2 more bytes after initial read. That feels like magic, so it would be nice to get event.data = 3 and read the whole MIDI message at once.

Replace MK_VOSS with MK_SOUND after discussion with Mark.

For testing you can use snd_dummy(4), I added some basic MIDI support, although you might need to make it more functional because it basically does more or less nothing currently.