Note that this won't have any effect after a device driver has initialized. snd_mixerdefaults is only used in mixer_init(), so any change with these sysctls will require a driver re-load for the new defaults to take effect. I suppose this is not really an issue if these defaults are set and "forgotten" in a config file, though.

Many translations (e.g., German, Danish, Polish from a quick look) are actually in English.

Bump.

In D52325#1291455, @bz wrote:

In D52325#1291454, @christos wrote:

The patch does not apply cleanly on main:

Yes, it's 7 months old and didn't get much attention.
As said in email, I should rewrite some things and then really push to get it in.

The patch does not apply cleanly on main:

$ git arc patch D52325
Checking patch usr.sbin/fwget/usb/usb_wireless_ralink...
Checking patch usr.sbin/fwget/usb/usb_wireles_header...
Checking patch usr.sbin/fwget/usb/usb_ralink...
Checking patch usr.sbin/fwget/usb/usb_bluetooth_realtek...
Checking patch usr.sbin/fwget/usb/usb_bluetooth_qca...
Checking patch usr.sbin/fwget/usb/usb_bluetooth_intel...
Checking patch usr.sbin/fwget/usb/usb_bluetooth_header...
Checking patch usr.sbin/fwget/usb/usb_bluetooth_brcm...
Checking patch usr.sbin/fwget/usb/usb...
Checking patch usr.sbin/fwget/usb/Makefile...
Checking patch usr.sbin/fwget/pci/pci_wireless_realtek...
Checking patch usr.sbin/fwget/pci/pci_wireless_qca...
Checking patch usr.sbin/fwget/pci/pci_wireless_mediatek...
Checking patch usr.sbin/fwget/pci/pci_wireless_intel...
Checking patch usr.sbin/fwget/pci/pci_wireless_header...
Checking patch usr.sbin/fwget/pci/pci_video_intel...
Checking patch usr.sbin/fwget/pci/pci_video_header...
Checking patch usr.sbin/fwget/pci/pci_video_amd...
error: while searching for:
#-
# SPDX-License-Identifier: BSD-2-Clause
#
# Copyright 2023 Beckhoff Automation GmbH & Co. KG
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted providing that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
# IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.

Fix.

Address Mark's comments.

In D54360#1291229, @meka_tilda.center wrote:

Given it works with umidi, should we close this? I think not as it works for me.

In D54359#1291226, @meka_tilda.center wrote:

Unification first, as this code is mostly "copy" of the umidi code. I think after unification one place will have the kqueue support and that will probably be copied over from umidi. That being said, do you want me to close this one?

In D54359#1291224, @meka_tilda.center wrote:

So, is it smart to work on this before umidi/midi unification? I can work on that, I just think it would be better if unification happened first.

In D54360#1291221, @meka_tilda.center wrote:

I understood that you need to unify umidi and midi, that's why I left this review as is. Please tell me if I got it wrong.

Let me know if you want me to take this over. No problem for me. :-)

Clarify virtual_oss_default_control_device further.

Thanks for this patch. I agree with Ed's comment.

Use an rc variable instead.

I think it'd be good to have some comments explaining what this code does.

In D55670#1283732, @markj wrote:

In D55670#1277863, @christos wrote:

In D55670#1277707, @markj wrote:

In D55670#1276909, @christos wrote:

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.

The thing is that if we want to be flexible, we cannot know which control device the user wants to use. Perhaps the user wants to use a control device for a virtual_oss instance that does not replace /dev/dsp, hence why an environment variable that is easily modifiable might be simpler. Not sure yet.

I don't understand the problem with my suggestion. Can you give an example where it doesn't work?

At the moment we cannot assume two things: 1) which control device belongs to which virtual device, 2) which control device the user actually wants to use in, say, snd.conf. Issue 1 could indeed be solved with something like what you propose. Issue 2, however, cannot, because even if we have a virtual-to-control device mapping for each virtual device, we cannot assume which virtual device the user wants to manipulate. Sure, the most common use-case and predictable scenario is that the user wants to use whichever control device is associated with the virtual_oss-created /dev/dsp, since this acts as the system-wide default device. That being said, I'm not sure if relying on this assumption is robust enough. What do you think?

I see, one can use rc.conf to configure multiple virtual_oss instances. (virtual_oss is not documented anywhere in rc.conf.5, which seems like a bug.)

I don't see a good way to handle it with the current scheme. I would maybe add a new rc.conf variable, virtual_oss_default_control_device, defaulting to "vdsp.ctl", and get the value of that variable in snd.conf using $(sysrc virtual_oss_default_control_device). Then make sure everything is documented in rc.conf.5.

Bump.

In D38825#1213702, @christos wrote:

I have been testing this again recently, and it works fine, at least with the tests I ran. I think we should go ahead and get it into the tree, it's been sitting in review for 3 years almost. releng/15.0 is branched so there is no fear of breaking the release, even though this shouldn't break anything in the first place, it's a kinst-specific change and at worst it won't always yield 100% correct results. Once we have it in tree we can work on remaining issues, but I do not see a point in keeping it here anymore.

In D55670#1277863, @christos wrote:

In D55670#1277707, @markj wrote:

In D55670#1276909, @christos wrote:

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.

The thing is that if we want to be flexible, we cannot know which control device the user wants to use. Perhaps the user wants to use a control device for a virtual_oss instance that does not replace /dev/dsp, hence why an environment variable that is easily modifiable might be simpler. Not sure yet.

I don't understand the problem with my suggestion. Can you give an example where it doesn't work?

At the moment we cannot assume two things: 1) which control device belongs to which virtual device, 2) which control device the user actually wants to use in, say, snd.conf. Issue 1 could indeed be solved with something like what you propose. Issue 2, however, cannot, because even if we have a virtual-to-control device mapping for each virtual device, we cannot assume which virtual device the user wants to manipulate. Sure, the most common use-case and predictable scenario is that the user wants to use whichever control device is associated with the virtual_oss-created /dev/dsp, since this acts as the system-wide default device. That being said, I'm not sure if relying on this assumption is robust enough. What do you think?