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 <[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 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.
