As a follow up to bug 211893 and to aid in using FreeBSD as a desktop OS, it would help enormously if mpv could include support for sndio by default. The reason it would work is it would integrate well with the documentation provided at https://wiki.freebsd.org/Sound#For_Firefox.2FChrome_video_conferencing:_sndio_integration_for_userspace_programs for using sndio for Firefox. Would this be possible?
I strongly disagree. The sndio backend has problems and was removed upstream [1]. We should enable OPENAL by default instead. We can turn on sndio support in audio/openal-soft by default. [1] https://github.com/mpv-player/mpv/commit/71d218eae4b4d93ada34ff74906f71ad359c84bc#diff-7ea2892c97fb115fc8ed8f8e6574e022 > The reason it would work is it would integrate well with the > documentation provided at > https://wiki.freebsd.org/Sound#For_Firefox.2FChrome_video_conferencing:_sndio_integration_for_userspace_programs > for using sndio for Firefox. The "simple" setup is way too complicated: sndiod defaults to using rsnd/default which is mapped to /dev/dsp, so just `sndiod` is enough and should be equivalent to `sndiod -f rsnd/$(sysctl -n hw.snd.default_unit)`. While I'd recommend running sndiod because of bug #218188, it does not need to be running at all for simple stuff to work.
\o it looks like that'd make sense, I'm testing audio/openal-soft with SNDIO (and all audio options disabled) and multimedia/mpv with OPENAL (and all other audio options disabled). Will be reporting back over May 26th CEST time :-). Hopefully nothing will get in the way.
Comment 2 As long as it means I can get audio from mpv without having to switch things around or use pulseaudio (which also requires switching things around for me), I'll be happy. :) Having checked your suggestion, I've adopted the other documentation a bit. I don't think there's a need to discuss it further in this report, as I'm not sure it's related.
Hello, reporting back on my tests with mpv + openal with sndio stupport. On the mpv side of things, which is relevant for this PR, it seems fairly uncontroversial (no extra dependencies, no side-effects) to have the OPENAL option enabled by default and it works fine. It does require --ao=openal, else it defaults to using OSS (which also works even with sndio enabled), a user could also set this option system-wide or user-wide in the corresponding configuration files. Regarding audio/openal-soft, I've opened bug 246741 because it looks to me like that discussion is worth having in a different place. Hope that's useful.
(In reply to Tobias Kortkamp from comment #1) > We should enable OPENAL by default instead. OPENAL is not usable after https://github.com/mpv-player/mpv/commit/d27ad9654218 $ mpv --no-config --msg-level=ao=v --ao=openal foo.mp3 [...] [ao] Trying audio driver 'openal' [ao/openal] requested format: 44100 Hz, stereo channels, floatp [ao/openal] broken. [ao] Failed to initialize audio driver 'openal' Could not open/initialize audio device -> no sound. Audio: no audio Exiting... (Errors when loading file)
(In reply to Jan Beich from comment #5) Yikes... There is still the SDL backend for now which we could use like OpenBSD does.
That's probably just going to be removed too? :(
Maintainer reset.
Obsolete after ports r556071.
We should enable OSS by default: https://github.com/mpv-player/mpv/pull/8312 :) There is no issues with OSS and sndio except wm4 does not want spent time to convert it to new internal API.
SNDIO: https://github.com/mpv-player/mpv/pull/8314
A commit references this bug: Author: jbeich Date: Wed Nov 25 10:56:19 UTC 2020 New revision: 556287 URL: https://svnweb.freebsd.org/changeset/ports/556287 Log: multimedia/mpv: restore --ao=oss and disable OPENAL (like before r556071) PR: 246726 Submitted by: rozhuk.im@gmail.com Changes: head/multimedia/mpv/Makefile head/multimedia/mpv/distinfo