Date: Mon, 20 Jul 2026 12:27:44 +0200 From: Mario Marietto <marietto2008@gmail.com> To: vester.thacker@fastmail.fm Cc: vermaden <vermaden@interia.pl>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, "freebsd-hackers@FreeBSD.org" <freebsd-hackers@freebsd.org>, "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: Tragic State of FreeBSD Audio/Sound Message-ID: <CA%2B1FSijmZThPBuXUF=vgT2d04-RTxXwTrUAfoYTCc7OjWu_=Mg@mail.gmail.com> In-Reply-To: <bdf27359-e9be-4a3c-874e-af22bc132809@app.fastmail.com> References: <hkttyyfmuguexmliuhmg@ewtn> <sirudbjwrqwlhpzjpfqf@abqv> <bdf27359-e9be-4a3c-874e-af22bc132809@app.fastmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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 AM <vester.thacker@fastmail.fm> 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 provides
> 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 system
> that I could understand, control, and improve when something went wrong. It
> is intended to become a replacement for existing desktop audio stacks, but
> 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 question
> 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 depends
> 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 this:
> >
> > % mixer -f ${DEV} vol.volume=+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
>
>
--
Mario.
[-- Attachment #2 --]
<div dir="ltr">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. </div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jul 20, 2026 at 11:55 AM <<a href="mailto:vester.thacker@fastmail.fm">vester.thacker@fastmail.fm</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 provides 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 software. Awase started from the same motivation: I wanted an audio system that I could understand, control, and improve when something went wrong. It is intended to become a replacement for existing desktop audio stacks, but 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.<br>
<br>
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.<br>
<br>
The immediate problem remains localization. The important question is not whether the fault is OSS or PulseAudio in isolation. The important question 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.<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 gather enough information to identify the responsible component.<br>
<br>
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 depends on predictable 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>
> Hi.<br>
><br>
> For a start lets define some TERMS. I use UPPERCASE not to shout - but <br>
> to underline a part of the sentence that is needed to be underlined - <br>
> this is plain email - I do not have Bold/Underscore/Italic options - <br>
> keep that in mind - now - to the core of the issue ...<br>
><br>
> I always considered FreeBSD OSS audio/sound subsystem superior to all <br>
> ALSA/PulseAudio/PipeWire and other dramas from the Linux world ... but <br>
> not anymore.<br>
><br>
> Somewhere between 14.3-RELEASE and 14.4-RELEASE things begin to get <br>
> broken - I thought that upgrade to latest and greatest 15.1-RELEASE <br>
> would solve my issues - as there were LOTS of sound/audio related <br>
> things.<br>
><br>
> I will not even start about PITA syntax of mixer(1) which went into this:<br>
><br>
> % mixer -f ${DEV} vol.volume=+0.05<br>
><br>
> ... from MUCH MORE friendly syntax.<br>
><br>
> But these random 'boozing' sounds are just unacceptable ... and I can <br>
> not even tell where they came from ... is it OSS problem? Is is <br>
> PulseAudio problem? Something in between? Because there is NOTHING in <br>
> the logs for audio.<br>
><br>
> Its also possible to get that file from my personal '<a href="http://mediafire.com" rel="noreferrer" target="_blank">mediafire.com</a>' <br>
> account here:<br>
> - <br>
> <a href="https://mediafire.com/file/jw3cpk8g77rvks2/freebsd-tragic-audio-sound.mp4/file" rel="noreferrer" target="_blank">https://mediafire.com/file/jw3cpk8g77rvks2/freebsd-tragic-audio-sound.mp4/file</a><br>;
><br>
> ... and its not some fancy laptop from yesterday ... its a ThinkPad <br>
> T480 from 2018 for fuck sake - hardware like that used to run smooth as <br>
> Carlos Sainz 'smooth operator' in Singapore GP ... but not anymore.<br>
><br>
> I do not even know what to add here ... its a message send our of <br>
> despair ... as newer releases only made these things worse ... I have <br>
> been repeating this over and over again - but its again probably the <br>
> issue that 'too less' FreeBSD developers use FreeBSD as their daily <br>
> driver/desktop/laptop system.<br>
><br>
> Sorry to disappoint.<br>
><br>
> Regards,<br>
> vermaden<br>
<br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Mario.<br></div>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B1FSijmZThPBuXUF=vgT2d04-RTxXwTrUAfoYTCc7OjWu_=Mg>