Test protocol: ``` # beep # Sound can be heard. # service virtual_oss onestart Starting virtual_oss config: dsp: hw.snd.basename_clone: 1 -> 0 done # beep # No sound can be heard. ``` cuse(3) is loaded and working, used by webcamd(8) for instance. What am I missing? What information can I provide that would help debug?
(In reply to Quentin Thébault from comment #0) Can you please share your virtual_oss config(s)?
Hi, thanks for your response. I just left the default to start with. Is it not supposed to work out of the box?
It is supposed to work, but I still want to see why you don't get sound. The default config should override the built-in /dev/dsp (the default sound device) with a virtual_oss one. Can you share the output of "sndctl -v" after starting virtual_oss?
Created attachment 268197 [details] sndctl -v output
I noticed there was an error in the logs: ``` Starting Virtual OSS config dsp ...hw.snd.basename_clone: 1 -> 0 done hw.snd.basename_clone: 0 -> 0 virtual_oss: Could not create CUSE DSP device ``` That does not seem to prevent the service from starting however. Trying to play sound with aucat or beep doesn't just fail to produce sound, it actually hangs. If I provide a /dev/dspN device with virtual_oss_cmd /dev/vdsp.ctl -f /dev/dsp4 for instance it starts to work. Isn't it just an inappropriate to use /dev/dsp both as the virtual_oss device and the output device in the default config provided by the rc.d script?
/dev/dsp is created only when hw.snd.basename_clone is set. In this case, it first gets unset (see logs), so the sound(4)-created /dev/dsp disappears. This is done so that virtual_oss can register its own /dev/dsp and act as the default device automatically. However, here you are trying to use /dev/dsp which no longer exists, so virtual_oss fails to open it. It's more robust to simply use the actual device you want to use, like you mentioned. But the behavior here is not wrong.
In that case wouldn't it make more sense for the default configuration in the virtual_oss rc.d script to set `/dev/dsp$(sysctl -n hw.snd.default_unit)` as a default recording and playback device? I'll gladly submit a Github PR if that's the case.
(In reply to Quentin Thébault from comment #7) This makes sense to me, yes. Put me as a reviewer in the PR. Thanks.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=06b466526a7fc35cc6fc5bf6f6269e7f3a0a7aea commit 06b466526a7fc35cc6fc5bf6f6269e7f3a0a7aea Author: Quentin Thébault <quentin.thebault@defenso.fr> AuthorDate: 2026-02-23 12:33:33 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2026-02-23 12:33:33 +0000 virtual_oss: use hw.snd.default_unit by default Reviewed by: christos MFC after: 1 week Signed-off-by: Quentin Thébault <quentin.thebault@defenso.fr> Sponsored by: Defenso PR: 293130 Pull Request: https://github.com/freebsd/freebsd-src/pull/2043 libexec/rc/rc.d/virtual_oss | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=960ef72179bd11aad0fe5ec794317030913685a8 commit 960ef72179bd11aad0fe5ec794317030913685a8 Author: Quentin Thébault <quentin.thebault@defenso.fr> AuthorDate: 2026-02-23 12:33:33 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2026-03-02 14:46:00 +0000 virtual_oss: use hw.snd.default_unit by default Reviewed by: christos MFC after: 1 week Signed-off-by: Quentin Thébault <quentin.thebault@defenso.fr> Sponsored by: Defenso PR: 293130 Pull Request: https://github.com/freebsd/freebsd-src/pull/2043 (cherry picked from commit 06b466526a7fc35cc6fc5bf6f6269e7f3a0a7aea) libexec/rc/rc.d/virtual_oss | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)