My latest desktop build.

smithi said:
What's wrong with supporting native OSS, i.e. sound(4) ?
Click to expand...
Afaik, Pipewire is made with the aim to provide a common API for both audio and video streams. It handles capture, redirection, has various processing plugins, etc. You are welcome to try implementing all this functionality with OSS if you so desire, of course.
 
OSS is not a proper demon that does mixing and dispatching. FreeBSD's OSS is slightly better than Linux' because FreeBSD has an in-kernel mixer, but only for 16 streams and only for output.

My equivalent question would be what is wrong with just using jackd everywhere :) But Chrome disagrees.

Pulseaudio is not bad as a concept, but the implementation is just too intransparent and fragile.
 
cracauer@ said:
OSS is not a proper demon that does mixing and dispatching. FreeBSD's OSS is slightly better than Linux' because FreeBSD has an in-kernel mixer, but only for 16 streams and only for output.

My equivalent question would be what is wrong with just using jackd everywhere :) But Chrome disagrees.

Pulseaudio is not bad as a concept, but the implementation is just too intransparent and fragile.
Click to expand...
And then everyone wonders why I use ports and turn EVERYTHING on... yes, Pulseaudio/ALSA/JACK/GStreamer/Pipewire/whatever... If one thing doesn't work, at least I have the option to just switch to something different without missing a beat. :p
 
shkhln said:
Afaik, Pipewire is made with the aim to provide a common API for both audio and video streams. It handles capture, redirection, has various processing plugins, etc.
Click to expand...

Thanks. What's its status under FreeBSD?

shkhln said:
You are welcome to try implementing all this functionality with OSS if you so desire, of course.
Click to expand...

Of course. But I don't need all that, just good sound. My old 9.3 system's KDE4 works happily with sound(4); must 'progress' on one level mean 'regress' on another?

(rhetorical question, of course)

astyle said:
And then everyone wonders why I use ports and turn EVERYTHING on... yes, Pulseaudio/ALSA/JACK/GStreamer/Pipewire/whatever...
Click to expand...

Does $whatever include OSS, either sound(4) or the port, if I build the KDE5 port?

I'm hoping to more or less duplicate my working 9.3 laptop on 12.4, later 13.x, primarily used to generate (up to) 24 bit 96kHz .wav files programmatically, post processed to .mp3 by lame.
 
astyle said:
And then everyone wonders why I use ports and turn EVERYTHING on... yes, Pulseaudio/ALSA/JACK/GStreamer/Pipewire/whatever... If one thing doesn't work, at least I have the option to just switch to something different without missing a beat. :p
Click to expand...

Jack support should, in my opinion, be turned on for the ports that support it. There is no dependency hell here and jack is a much more robust and debuggable demon than the alternatives.
 
smithi said:
Does $whatever include OSS, either sound(4) or the port, if I build the KDE5 port?
Click to expand...
It usually does.

But if not, there's usually another option supported. That's why I turn EVERYTHING on when I compile ports... and then I shake my head at ppl who first complain about lack of sound on FreeBSD, then complain that GStreamer breaks everything, and then complain that ALSA sucks, and get political about it. Open Source software is about having options, and giving yourself options, rather than getting political about it... wow.
 
To borrow a phrase from an old movie "Some men you just can't reach"...Sigh

I know what all these multimedia daemons "try" to do. Point of contention is that I dont want them to do it, specifically if I'm gonna be forced to use the whole stack later on because someone made a poor decision that all distro supported multimedia goes thru that service.

If I can access a sound card using read() write() and ioctl() to manage PCM data thru it then I'm happy and need none of this extra fluff.

But what about surround sound and inserting mixer effects and accessing my electronic keyboard and my external sound mixing board, etc?

So what you're telling me is that the majority of us who only have a set of stereo headphones with a boom mic attached to a 48khz soundcard to listen to MP3s and participate in teleconferences, are gonna be forced to absorb stupid and innefficient (usually buggy if you use poetterisms as an example) abstrations that complicate our lives just so the niche sound processing subculture can have their cake and the devs can pad their resumes with FOSS activities.

An old saying that I find value in in the 21st century goes something like this: "If you cannot do it in fortran then do it in assembler. If you cannot do it in assembler then it isn't worth doing". Real Programmers Dont Use PASCAL, Datamation, July 1982. Now I know this saying will be taken out of context, but the essense that is important to me is that they are stressing minimally two layers: human readable logic and machine code...and no, I don't need a lecture on machine code vs assembler neumonics. Anything more than ALSA should ALWAYS BE OPTIONAL!

Anyway, sorry for the soapbox rant.
 
hbsd said:
Please don't let your son work with that monitor. CRT monitors are the enemy of the eyes and cause serious damage to his eyes, replace it with a LED or LCD monitor anti-radiation glasses are also very useful and almost it prevents astigmatism of the eyes.
Click to expand...
Like many I have spent years behind CRT monitors and my eyes are fine except age related nearsightedness.
 
Pecka said:
Like many I have spent years behind CRT monitors and my eyes are fine except age related nearsightedness.
Click to expand...
It's like saying I've been smoking for years and nothing ever happened to me or I don't exercise and I'm healthy!
Are you nearsightedness? who knows, maybe your eyes nearsightedness due to lack of care, not age. I've seen many old people whose eyes are healthy!
 
astyle said:
That's why I turn EVERYTHING on when I compile ports...
Click to expand...
When you do just need things to work, I do understand this (and often do similar myself). However I tend to use FreeBSD because it typically has *one* standard, well documented, stable way to do things (mostly because it is a full OS rather than a mish mash of random free software projects).

It is just annoying when this Linux nonsense bleeds over into FreeBSD via ports. I think OpenBSD's efforts into adding sndio support into most ports is quite admirable. Likewise, you rarely find ports of FOSS software to macOS or Windows dragging in ~5 different sound systems as dependencies.

mickey said:
Why do port maintainers always have to enable each and every crap by default? Seriously.
Click to expand...
I feel that potentially it has to do with i.e autotools and other build scripts compiling in features depending on what they find at build time. In turn this makes it difficult to create deterministic packages and plists without ensuring a completely clean system for each port (including development libraries from dependencies).

Perhaps rather than finding ways to explicitly disable features in the scripts, it is easier to simply add to the depends line in the Makefile and force it to exist to be found?

Or at least this was the most difficult thing I noticed when I used to maintain some larger ports.
 
kent_dorfman766 said:
I haven't installed windoze on a machine I own since win-7! My anti-windoze stance is making it harder to do consulting work because my principles of not using a locked down M$ machine or being treated as a security risk are more important to me than the money.
Click to expand...
I cannot understand that anti-windows obsession. I hope you are not using Android as well, because it is much stupid OS than Windows. But billion people use it somehow and even do not mutter.
 
kent_dorfman766 said:
An old saying that I find value in in the 21st century goes something like this: "If you cannot do it in fortran then do it in assembler. If you cannot do it in assembler then it isn't worth doing". Real Programmers Dont Use PASCAL, Datamation, July 1982.
Click to expand...

When I started coding in FORTRAN in 1968, it was always spelled in all caps.

When I was porting Tiny (aka People's) Pascal p-code VM to Signetics 2650 assembler in 1978, it was never spelled in all caps.

Guess I must be an unReal Programmer <&^}=
 
kent_dorfman766 said:
So what you're telling me is that the majority of us who only have a set of stereo headphones with a boom mic attached to a 48khz soundcard to listen to MP3s and participate in teleconferences, are gonna be forced to absorb stupid and innefficient (usually buggy if you use poetterisms as an example) abstrations that complicate our lives just so the niche sound processing subculture can have their cake and the devs can pad their resumes with FOSS activities.
Click to expand...
Well said. And the niche processing subculture has had JACK for decades, which solves all these problems. Well, I hear it does anyways. The rant LibreQuest posted confirms this. So why is Linux onto a third sound daemon?

I'm in the "I just need my headphones to work" camp. I installed Pipewire. Sound promptly stopped working. I uninstalled Pipewire. Sound started working again.

Yeah, yeah I'm probably doing something "wrong", and if I just spent a couple of hours going blind reading documentation and doing Google searches, I could probably get some whiz bang results. This kind of blame-the-victim excuse used to be one of Microsoft's favorite tricks, but it's now become common in the Linux world.

This might be Freebsd's greatest strength on the desktop. Sound just works for the 99% of us that just want to watch Youtube videos or whatever.

mickey said:
Why do port maintainers always have to enable each and every crap by default? Seriously.
Click to expand...
I read somewhere that this is intentional to support most use cases out of the box. Basically if an option doesn't have any exclusionary effects (e.g., it precludes using something else) it is turned on by default. I believe it was bapt@ referring to Wayland in the ports mailing list, but I may be misremembering.

astyle said:
But if not, there's usually another option supported. That's why I turn EVERYTHING on when I compile ports... and then I shake my head at ppl who first complain about lack of sound on FreeBSD, then complain that GStreamer breaks everything, and then complain that ALSA sucks, and get political about it. Open Source software is about having options, and giving yourself options, rather than getting political about it... wow.
Click to expand...
I take the exact opposite approach. I turn everything off, except what I absolutely need. This is because all software has bugs, and the more software you have installed, the more likely it is you'll run into some.

It was insane that net/netatalk3 wanted to install Dbus on my headless server just because net/avahi needs it for some desktop use case. Problem solved with dns/mDNSResponder.
 
Jose said:
I take the exact opposite approach. I turn everything off, except what I absolutely need. This is because all software has bugs, and the more software you have installed, the more likely it is you'll run into some.
Click to expand...
I'd rather not spend time figuring out what I 'absolutely need'... yeah, all software has bugs. My take is that it's better to have options open to me - if one option(like JACK) has a bug that is a showstopper, I could switch to the next option (like sndio) that has that bug resolved. Yeah, it will have a different set of problems/bugs... Threading the needle is not my objective, my objective is to have sound working, and to have options.
 
I'd rather spend the time up front and figure out what I actually need, than spend the time fixing problems with an update gone bad. To each his own.
 
cracauer@ said:
OSS is not a proper demon that does mixing and dispatching. FreeBSD's OSS is slightly better than Linux' because FreeBSD has an in-kernel mixer, but only for 16 streams and only for output. My equivalent question would be what is wrong with just using jackd everywhere :) But Chrome disagrees. Pulseaudio is not bad as a concept, but the implementation is just too intransparent and fragile.
Click to expand...

What improvements could be made to bring OSS in base to feature parity with other open alternatives? jackd looks nice, but I'd rather hack on BSD licensed stuff in base.
 
kent_dorfman766 said:
But what about surround sound and inserting mixer effects and accessing my electronic keyboard and my external sound mixing board, etc?

So what you're telling me is that the majority of us who only have a set of stereo headphones with a boom mic attached to a 48khz soundcard to listen to MP3s and participate in teleconferences, are gonna be forced to absorb stupid and innefficient (usually buggy if you use poetterisms as an example) abstrations that complicate our lives just so the niche sound processing subculture can have their cake and the devs can pad their resumes with FOSS activities.
Click to expand...
Imagine thinking sound capture is some exotic concern. Or, say, noise suppression.
 
You must log in or register to reply here.
Back
Top