Re: Tragic State of FreeBSD Audio/Sound

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