Re: Tragic State of FreeBSD Audio/Sound

On Tue, Jul 21, 2026 at 7:51 AM Jordan Gordeev <jgopensource@proton.me> wrote:
>
> 1. Do not cross post to *three* mailing lists.
> 2. Post to the correct mailing list. In this case that's freebsd-questions@. That's the mailing list for asking questions like "Is anyone else seeing this problem?", "What can I do to help debug this problem?", "How did things become so bad?", etc.
I leave the rest of this, but I will point out that "the correct
mailing list" is not obvious
in many cases. For example, a problem for a release or stable branch maybe
should go to freebsd-stable@. However, I've observed this often doesn't
work, because some developers do not read it.

I do read freebsd-stable@ but I do not read freebsd-questions@, so I never
see anything posted there. (So, if it is NFS related, don't post it to
freebsd-questions@
if you want me to se it.)

I do not have a magic answer w.r.t. what mailing list to use except that,
if you want all the developers to see it, I think a good bet is
freebsd-current@.
(Although cross-posting is discouraged, I understand why some will do it,
since it is difficult to guess what the correct mailing list is.)
NFS related issues are a challenge, since they might be related to networking
(freebsd-net@) or the VFS/VOP interface (freebsd-fs@) or crashes/hangs
(freebsd-current@ or freebsd-stable@ maybe).

> 3. Create problem reports in the FreeBSD bug database.
Personally, I find bug reports that have vague things like "weird noise"
rather useless. Bug reports work well for things like a crash or a specific
outcome that is reproducible or similar.
(Basically things where the problem is clear and probably doesn't need
discussion. If it needs discussion, I'd suggest a mailing list first and then
maybe a bug report once the issue is fairly well defined.

Part of the fun of FreeBSD is there is no one correct way to handle
almost anything (take submitting patches as an example).

I'm sure others will disagree, but this is what I find seems to work, rick

> 4. Don't wait for months or years before reporting a problem.
> 5. Test FreeBSD releases when they are in BETA or PRERELEASE. Don't wait until it's too late.
> 6. Learn the difference between FreeBSD and third-party software from ports (e.g. PulseAudio).
> 7. Understand that the way you configure your system may be very different from the way other people configure their systems. Bugs seen by you might not occur for others. In particular, a developer making a change might not be seeing the behaviour you consider to be a bug at all.
> 8. Always consider the possibility that your hardware might be failing.
> 9. Provide patches and solutions instead of complaining.
>
> Best regards,
> Jordan Gordeev
>