Commit this now. I know not all reviewers here have replied, but I think that's a straight forward and apparently wanted change.

Everyone in the MLs agrees with this change. I think we should go forward with this.

In D38825#1136408, @markj wrote:

I will spend some time testing this again within a week. My recollection from last time is that there were some edge cases where probes didn't fire when I expected. One thing I didn't test yet but am a bit suspicious will not work properly is stack unwinding -- did you test that the stack() action prints reasonable output when used within an inline function probe?

I'm inclined to abandon this one in favor of D50070.

Allow printing individual channel controls without specifying the -v option.

Rebase with 02d61f27585f52d422fc1e235ac6226e27145162 applied.

The devd approach: D50070

This is a WIP and needs more testing.

This is a WIP and I'm waiting for @adrian to test this on his Macbook, but I'm leaving it here so it's easier for more people to see/test.

Address Mark's comments.

@dev_submerge.ch As a proof of concept, the devd + virtual_oss solution I proposed earlier, with a small snd_hda(4) patch, already works, albeit with a few bugs that I'm trying to resolve. I think that solution is probably the better one, because it is way more extensible, the tech debt/complexity is significantly smaller, and can be adapted easily in userland. This way we also avoid reinventing the wheel inside sound(4) to get hot-swapping. This might indeed introduce some small overhead, but as I said in the last message, if the user wants as low latencies as possible, they can still just open the device(s) directly as always. And to get automatic hot-swapping we can just add a devd script that switches on attach/detach. I think we should follow through with that approach instead of this one here.

Rebase on top of main

• Address Adrian's comments. Stop leaking strduped strings.
• Remove "PCM_CAP" from capmap strings.
• Support AFMT_F32_LE and AFMT_F32_BE.
• Improve channel printing when -v is set.
• Sort mod functions better.
• Fix bug in first sysctlbyname() call in sysctl_str().
• Update COPYRIGHT dates.
• Print device name in some error messages.
• Merge play|rec.autoconv into a single control for both play and rec.
• Modify play|rec.vchans to match changes introduced by 02d4eeabfd73 ("sound: Allocate vchans on-demand")
• Update fetching of PVCHAN and RVCHAN to match changed introduced by D49980.
• Rename hwchans to pchans (primary channels), and stop printing it; only use it internally. It's not really relevant to the user as a standalone property.
• Do not print chan.name, it's redundant for now, since the channel name is always printed before the property name.
• Re-read device at the end to make sure we reflect the new state if a property has been changed.
• Add hwbuf.rate and swbuf.rate controls. Depends on D49983.
• Print the hardware buffer format and rate if vchans are disabled.
• Improve man page.

nvlist_add_number() -> nvlist_add_bool()

I think we need to decide on a trade-off. I haven't yet tested the virtual_oss + devd approach I proposed (I will shortly), but the current approach will inevitably require lots of fine tuning, caveats and possibly bug reports, if we want to achieve the best possible functionality to cover the use-cases you mention, whereas the other approach might introduce some latency and complication with now having an audio server running by default, but we might save up on development/maintenance time. As a side note, I would expect very specialized applications to access devices directly, so this is still always an option anyway.

In D49216#1139633, @dev_submerge.ch wrote:

I'm sorry to say this, but after some consideration I'm not sure we should follow through with this approach. We cannot keep / recreate the buffer properties, we lose audio data when swapping, and we break a whole lot of assumptions that are baked into the OSSv4 API. I expect this to provoke many subtle problems with buffers and timing, and it will be hard to tell which applications work well with swapping, and which do not. For me it's just not worth all the bug reports, when device swapping should actually be done in userland where applications / sound servers can handle it properly.

It's fine to let users decide whether they want this feature or not, that's FreeBSD philosophy. But the outcome should be predictable, IMHO.

In D49216#1136549, @dev_submerge.ch wrote:

On a side note, I tried to test exclusive and bitperfect mode yesterday, as on request by the application through ioctl. Both are completely ineffective. When did we break this, and was that intentional?

In D49216#1135617, @dev_submerge.ch wrote:

Hi there, I'm still short on spare time but did some very brief tests.

First this lock order reversal, don't know how to reproduce yet and whether it is related to this patch:

Address Lorenzo's comments.

In D49804#1135648, @markj wrote:

So should the priv->sc field be removed entirely?

Remove unit argument from vdsp_open_dev() and vdsp_get_dev() and figure
it out inside the functions instead. It's cleaner in combination with the
follow-up patch.

tinderbox build on the cluster done with no errors.

@kib Any comments regarding the use of dev_ref() and dev_rel()?

• Do not ignore return values in vdsp cdev methods.
• Address kib's comments.

In D49490#1132702, @diizzy wrote:

You can't commit this without consent from maintainer, this could possible fall under blanket but to avoid unnecessary friction I'd suggest that you submit it to bugzilla too.
https://docs.freebsd.org/en/books/porters-handbook/book/#porting-submitting

https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-maintainer
https://docs.freebsd.org/en/articles/committers-guide/#ports-qa-misc-blanket-approval

In D49490#1132647, @diizzy wrote:

Looks reasonable but you need to file a bug report in bugzilla for Porter's Handbook and Committer's Guide to apply