Re: Tragic State of FreeBSD Audio/Sound

--00000000000085af870657085d7c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yeah,me too. I feel your frustration. That's also mine. Because I'm trying
to fix the audio distorsions coming from the 4 inches display that I want
to use in the FreeBSD based phone that I'm building. I'm working with
Claude and I'm spending a lot of tokens asking Fable 5 to fix the problems.
Report after report,it seems very hard to obtain a clean and robust sound.
I imagine how hard it is to do it without using advanced AI.

On Mon, Jul 20, 2026 at 11:55=E2=80=AFAM <[email protected]> wrote=
:

> I understand the frustration behind this report. Audio failures are
> difficult because the symptom is simple, a bad sound, while the cause can
> exist anywhere from the driver to the application. When the system provid=
es
> no useful indication of where the failure occurred, debugging becomes
> guesswork.
>
> I have encountered this same class of problem while working on audio
> software. Awase started from the same motivation: I wanted an audio syste=
m
> that I could understand, control, and improve when something went wrong. =
It
> is intended to become a replacement for existing desktop audio stacks, bu=
t
> it is still in the early alpha stage. semasound handles audio processing
> and playback. audiofs handles audio asset access. The separation is
> deliberate because systems are easier to maintain when their
> responsibilities and failure boundaries are clear.
>
> This does not solve the specific FreeBSD regression you describe today. A
> new design still has to mature, gain users, and prove itself. However, it
> represents one possible response to the larger problem: when existing
> solutions become too difficult to debug or modify, building a simpler
> system can be a practical path forward.
>
> The immediate problem remains localization. The important question is not
> whether the fault is OSS or PulseAudio in isolation. The important questi=
on
> is where the failure first appears. The investigation should narrow the
> path. Test direct device output. Test through user-space layers. Compare
> players. Compare releases. Each result removes another possibility.
>
> The recording is valuable because it demonstrates that the failure exists=
.
> It gives developers something concrete to reproduce. The next step is to
> gather enough information to identify the responsible component.
>
> I do not know whether the cause is related to how many developers use
> FreeBSD as a desktop system. There may be several contributing factors,
> including how desktop issues are prioritized and who takes ownership of
> them. I do know that regressions on common hardware deserve attention. A
> ThinkPad T480 is not an unusual machine. A desktop operating system depen=
ds
> on predictable behavior after upgrades.
>
> The goal is not a system that never fails. That is unrealistic. The goal
> is a system where failures leave enough evidence that they can be
> understood and fixed.
>
> -vic
>
>
> On Mon, Jul 20, 2026, at 09:04, vermaden wrote:
> > Hi.
> >
> > For a start lets define some TERMS. I use UPPERCASE not to shout - but
> > to underline a part of the sentence that is needed to be underlined -
> > this is plain email - I do not have Bold/Underscore/Italic options -
> > keep that in mind - now - to the core of the issue ...
> >
> > I always considered FreeBSD OSS audio/sound subsystem superior to all
> > ALSA/PulseAudio/PipeWire and other dramas from the Linux world ... but
> > not anymore.
> >
> > Somewhere between 14.3-RELEASE and 14.4-RELEASE things begin to get
> > broken - I thought that upgrade to latest and greatest 15.1-RELEASE
> > would solve my issues - as there were LOTS of sound/audio related
> > things.
> >
> > I will not even start about PITA syntax of mixer(1) which went into thi=
s:
> >
> > % mixer -f ${DEV} vol.volume=3D+0.05
> >
> > ... from MUCH MORE friendly syntax.
> >
> > But these random 'boozing' sounds are just unacceptable ... and I can
> > not even tell where they came from ... is it OSS problem? Is is
> > PulseAudio problem? Something in between? Because there is NOTHING in
> > the logs for audio.
> >
> > Its also possible to get that file from my personal 'mediafire.com'
> > account here:
> > -
> >
> https://mediafire.com/file/jw3cpk8g77rvks2/freebsd-tragic-audio-sound.mp4=
/file
> >
> > ... and its not some fancy laptop from yesterday ... its a ThinkPad
> > T480 from 2018 for fuck sake - hardware like that used to run smooth as
> > Carlos Sainz 'smooth operator' in Singapore GP ... but not anymore.
> >
> > I do not even know what to add here ... its a message send our of
> > despair ... as newer releases only made these things worse ... I have
> > been repeating this over and over again - but its again probably the
> > issue that 'too less' FreeBSD developers use FreeBSD as their daily
> > driver/desktop/laptop system.
> >
> > Sorry to disappoint.
> >
> > Regards,
> > vermaden
>
>

--=20
Mario.

--00000000000085af870657085d7c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yeah,me too. I feel your frustration. That&#39;s also mine=
. Because I&#39;m trying to fix the audio distorsions coming from the 4 inc=
hes display that I want to use in the FreeBSD based phone that I&#39;m buil=
ding. I&#39;m working with Claude and I&#39;m spending a lot of tokens aski=
ng Fable 5 to fix the problems. Report after report,it seems very hard to o=
btain a clean and robust sound. I imagine how hard it is to do it without u=
sing advanced AI.=C2=A0</div><br><div class=3D"gmail_quote gmail_quote_cont=
ainer"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 20, 2026 at 11:55=
=E2=80=AFAM &lt;<a href=3D"mailto:[email protected]">vester.thacke=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">I understand the frustration behind this report. Audio failure=
s are difficult because the symptom is simple, a bad sound, while the cause=
 can exist anywhere from the driver to the application. When the system pro=
vides no useful indication of where the failure occurred, debugging becomes=
 guesswork.<br>
<br>
I have encountered this same class of problem while working on audio softwa=
re. Awase started from the same motivation: I wanted an audio system that I=
 could understand, control, and improve when something went wrong. It is in=
tended to become a replacement for existing desktop audio stacks, but it is=
 still in the early alpha stage. semasound handles audio processing and pla=
yback. audiofs handles audio asset access. The separation is deliberate bec=
ause systems are easier to maintain when their responsibilities and failure=
 boundaries are clear.<br>
<br>
This does not solve the specific FreeBSD regression you describe today. A n=
ew design still has to mature, gain users, and prove itself. However, it re=
presents one possible response to the larger problem: when existing solutio=
ns become too difficult to debug or modify, building a simpler system can b=
e a practical path forward.<br>
<br>
The immediate problem remains localization. The important question is not w=
hether the fault is OSS or PulseAudio in isolation. The important question =
is where the failure first appears. The investigation should narrow the pat=
h. Test direct device output. Test through user-space layers. Compare playe=
rs. Compare releases. Each result removes another possibility.<br>
<br>
The recording is valuable because it demonstrates that the failure exists. =
It gives developers something concrete to reproduce. The next step is to ga=
ther enough information to identify the responsible component.<br>
<br>
I do not know whether the cause is related to how many developers use FreeB=
SD as a desktop system. There may be several contributing factors, includin=
g how desktop issues are prioritized and who takes ownership of them. I do =
know that regressions on common hardware deserve attention. A ThinkPad T480=
 is not an unusual machine. A desktop operating system depends on predictab=
le behavior after upgrades.<br>
<br>
The goal is not a system that never fails. That is unrealistic. The goal is=
 a system where failures leave enough evidence that they can be understood =
and fixed.<br>
<br>
-vic<br>
<br>
<br>
On Mon, Jul 20, 2026, at 09:04, vermaden wrote:<br>
&gt; Hi.<br>
&gt;<br>
&gt; For a start lets define some TERMS. I use UPPERCASE not to shout - but=
 <br>
&gt; to underline a part of the sentence that is needed to be underlined - =
<br>
&gt; this is plain email - I do not have Bold/Underscore/Italic options - <=
br>
&gt; keep that in mind - now - to the core of the issue ...<br>
&gt;<br>
&gt; I always considered FreeBSD OSS audio/sound subsystem superior to all =
<br>
&gt; ALSA/PulseAudio/PipeWire and other dramas from the Linux world ... but=
 <br>
&gt; not anymore.<br>
&gt;<br>
&gt; Somewhere between 14.3-RELEASE and 14.4-RELEASE things begin to get <b=
r>
&gt; broken - I thought that upgrade to latest and greatest 15.1-RELEASE <b=
r>
&gt; would solve my issues - as there were LOTS of sound/audio related <br>
&gt; things.<br>
&gt;<br>
&gt; I will not even start about PITA syntax of mixer(1) which went into th=
is:<br>
&gt;<br>
&gt; % mixer -f ${DEV} vol.volume=3D+0.05<br>
&gt;<br>
&gt; ... from MUCH MORE friendly syntax.<br>
&gt;<br>
&gt; But these random &#39;boozing&#39; sounds are just unacceptable ... an=
d I can <br>
&gt; not even tell where they came from ... is it OSS problem? Is is <br>
&gt; PulseAudio problem? Something in between? Because there is NOTHING in =
<br>
&gt; the logs for audio.<br>
&gt;<br>
&gt; Its also possible to get that file from my personal &#39;<a href=3D"ht=
tp://mediafire.com" rel=3D"noreferrer" target=3D"_blank">mediafire.com</a>&=
#39; <br>
&gt; account here:<br>
&gt; - <br>
&gt; <a href=3D"https://mediafire.com/file/jw3cpk8g77rvks2/freebsd-tragic-a=
udio-sound.mp4/file" rel=3D"noreferrer" target=3D"_blank">https://mediafire=
.com/file/jw3cpk8g77rvks2/freebsd-tragic-audio-sound.mp4/file</a><br>
&gt;<br>
&gt; ... and its not some fancy laptop from yesterday ... its a ThinkPad <b=
r>
&gt; T480 from 2018 for fuck sake - hardware like that used to run smooth a=
s <br>
&gt; Carlos Sainz &#39;smooth operator&#39; in Singapore GP ... but not any=
more.<br>
&gt;<br>
&gt; I do not even know what to add here ... its a message send our of <br>
&gt; despair ... as newer releases only made these things worse ... I have =
<br>
&gt; been repeating this over and over again - but its again probably the <=
br>
&gt; issue that &#39;too less&#39; FreeBSD developers use FreeBSD as their =
daily <br>
&gt; driver/desktop/laptop system.<br>
&gt;<br>
&gt; Sorry to disappoint.<br>
&gt;<br>
&gt; Regards,<br>
&gt; vermaden<br>
<br>
</blockquote></div><div><br clear=3D"all"></div><br><span class=3D"gmail_si=
gnature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">Ma=
rio.<br></div>

--00000000000085af870657085d7c--