So from a quick investigation, the problem with mmap seems to be the fact that the memory used by the mmap is actually a channel's buffer:

static int
dsp_mmap_single(struct cdev *i_dev, vm_ooffset_t *offset,
    vm_size_t size, struct vm_object **object, int nprot)
{
        ...
	*offset = (uintptr_t)sndbuf_getbufofs(c->bufsoft, *offset);
        ...
}

Which means that when we hot-swap, and as a result, we close the previous device's channels, the buffer also gets deleted. I am wondering what a solution to this could be while also avoiding overcomplicating things. Perhaps we could use global (i.e., not per-channel) buffers so that we can point each new device to them?

Do not ignore value from dsp_poll() in vdsp_poll(), otherwise we might block
there forever.

• bus_topo_lock() around uses of devclass_*().
• Pass the unit as argument to vdsp_getdev(). Will be useful in the follow-up patch.

In D49449#1127556, @diizzy wrote:

Out of curiosity, would there be any benefit to add support / replace fftw3 with https://github.com/kfrlib/kfr ( math/kfr ) ?

Committed and created new tag: https://github.com/freebsd/virtual_oss/commit/6d7f60c21497989f1527465f5e9b493174ac9095

Fix 24-bit formats as well.

@mav @markj I have gotten down the functionality of splitting the default into playback and recording already, so I can confirm this is possible, but I still want to finalize this patch first before I submit the next one for review. The main problem currently is how we can trigger vdsp_getdev() from outside the cdevsw context, so that we can account for cases where an application may not call a cdevsw function for a while. Again, as I described in a previous comment, a possible scenario, which sounds a bit ugly IMHO, is to keep our own list of cdevprivs, so that we can fetch them whenever we want. I am not sure however if devfs_get_cdevpriv() would work in those cases, where the cdevsw function is triggered from outside the cdevsw context, though -- I'll need to test this. Do you have any ideas with regards to this?

Abandoning not exactly because of mav@'s comment per-se, but because I didn't realize that this patch could be problematic for people who plug into the headphone jack, but with headphones that do not have a microphone as well. I guess this is better set in /boot/device.hints.

New ALC257 patch: D49396

@wulf Is this change breaking something on your device?

Address Ed's comment.

In D47638#1125676, @darkvincentdude_yahoo.com wrote:

In D47638#1125224, @christos wrote:

In D47638#1125221, @darkvincentdude_yahoo.com wrote:

I forgot to rebase it since I committed some patches. Try again. :-)

Thanks! I can confirm that the patches fix game crashing and sound issues in multiple games on LSU Steam + FreeBSD Proton, such as Tell Me Why, Dishonored 2, and Republique.

Glad to hear that! :-)

However, Cyberpunk 2077 still has broken, static sound output, even with the patch.

Is this related to the sound system? If yes, please open a bug report on Bugzilla and we can investigate it there.

Well, audio works correctly in the game if I choose PulseAudio or Alsa as the Wine sound backends (via winetricks) in the game. So it's only by using the OSS audio backend that sound is all static. Other games with fixed audio (with the patch) are using the OSS backend.

In D47638#1125221, @darkvincentdude_yahoo.com wrote:

I forgot to rebase it since I committed some patches. Try again. :-)

Thanks! I can confirm that the patches fix game crashing and sound issues in multiple games on LSU Steam + FreeBSD Proton, such as Tell Me Why, Dishonored 2, and Republique.

Address Mark's comments.

In D47638#1125021, @darkvincentdude_yahoo.com wrote:

It looks like the patch fails to apply against main:

$ git apply D47638.diff
error: patch failed: sys/dev/sound/pcm/feeder_mixer.c:73
error: sys/dev/sound/pcm/feeder_mixer.c: patch does not apply

Rebase.

Bump.

Merged with D48421.

Merged with D48421.

Is this good to go?

• Address ziaee@'s man page comment.
• Restored hw.snd.basename_clone and dsp_clone(), but instead of cloning /dev/dsp${hw.snd.default_unit}, we are cloning vdsp_cdev, which is defined as /dev/vdsp. This way we preserve backwards compatibility with virtual_oss, since it can override /dev/dsp with its own. Update man page accordingly.
• Check whether the channels are not NULL, as opposed to checking priv->flags and assuming the channels will be non-NULL.
• Check for !DSP_REGISTERED() after acquiring the new cdevpriv in vdsp_getdev(), as well as in vdsp_open().

In D49216#1123613, @ziaee wrote:

Patch does not apply to CURRENT. Also, may I have your permission to post this on the Reddit?{F111680852}

@dev_submerge.ch If I'm not mistaken, your sosso library works with mmap. Could the test case it has be of any use to make sure this patch doesn't break anything?

Reflect changes in D47932.

Reflect changes in D47932.

Return to __always_inline __unused. I think it is better to leave it like
that for now and avoid complicating the code base further.

With the exception of the latest comments I left last time, LGTM.

I think we should just go ahead with using __always_inline __unused for now.