Re: Tragic State of FreeBSD Audio/Sound

On Tue, Jul 21, 2026 at 7:51=E2=80=AFAM 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-question=
s@. That's the mailing list for asking questions like "Is anyone else seein=
g this problem?", "What can I do to help debug this problem?", "How did thi=
ngs 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 networki=
ng
(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 th=
en
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 por=
ts (e.g. PulseAudio).
> 7. Understand that the way you configure your system may be very differen=
t 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
>