@akkana @stargazersmith as i said, pipewire *implements* the pulseaudio API so tools that worked with PA work with PW, but that is done (like most things in PW) via a module. The main tool that has carried over is, as you've noticed, pavucontrol, i think mostly because people didn't think it was worth reimplementing. PW comes with its own better/more focused tools for other kinds of control, and some good patching tools (helvum, qpwgraph). There are several cmd lines tool for PW, notably pw-cli.
pauldavisthefirst@fosstodon.org
Posts
-
I've been fiddling with #PipeWire and WirePlumber, #Linux's latest #audio system, trying to make my sound more reliable. -
I've been fiddling with #PipeWire and WirePlumber, #Linux's latest #audio system, trying to make my sound more reliable.@stargazersmith @akkana it isn't the variance in soundcards. It's the variance in the style of APIs and application needs, plus (most importantly) the inability of anyone in Linux-land to wield a big stick.
When Apple dropped their old (classic macOS) audio APIs for CoreAudio, they just told developers "this is how it's going to be".
Nobody has the power to do that on Linux.
So we developed desktop-style audio APIs like pulseaudio, and pro-audio/music creations APIs like JACK.
-
I've been fiddling with #PipeWire and WirePlumber, #Linux's latest #audio system, trying to make my sound more reliable.@akkana @stargazersmith Pipewire was not added "on top of" pulseaudio.
Pipewire is a reimplementation of: pulseaudio server, pulseaudio API for clients, JACK server, JACK API for clients, plus video streaming, ALSA pseudo-devices and much more.
It unifies both desktop apps using audio, and pro-audio/music creation apps, with a single server. It does more than the audio APIs on other platforms, lots more.
I do find that the configuration side of it is still a bit of nightmare.
-
I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.@inthehands " better solutions to the “Don’t make me decide! Just do something typical!” problem." ... the answer in the Hypercard case was "this is how Hypercard does it". That was pretty awesome for new programmers. But if I had tried to write Ardour with Hypercard's limitations on UI, I'd have gone crazy. So this is a bit nuanced. "Something typical" nearly always comes with a "in this context" clause, and that can make for wildly different solutions/outcomes.
-
I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.@inthehands i wasn't disputing that "a lot of [what makes UI programming hard is layout]". Layout is hard.
Just that the dfficulty really doesn't have much to do with the (relatively new) desire to make layouts work on mobile-sized devices as well as 72" HiDPI displays, though that likely adds to the problems.
-
I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.@inthehands " what makes UI programming hard is layout: you have to make your own very specific application look good on a variety of devices and screens"
UI programming was hard before we got mobile devices. This is not why UI programming is hard (though agreed, it makes it harder if desktop+mobile is in your design remit).
-
I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.@inthehands "The fundamental thing that makes programming hard is bridging the gap between ambiguous natural language and an unambiguous programming language." ... no, what makes it hard is the actual specifications are not really known no matter what language you use to describe them.
this is the entire motivation for the "agile" development pattern of the last 20-30 years.
without the cycle of specify-develop-use-respecify, you cannot approach the "true specification", and that's hard.
-
I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.@inthehands in Klein's interview with Jack Clark (Anthropic) at 06::00 he describes how you need to talk to Claude to get good results he is more or less describing the exact processes of most software engineering. I don't think this is a coincidence
There is software that is easy to develop, because the goal is completely understood; there is software that is much harder to develop because the goal is an evolving dialectic betwene user & developer. You can't make the 2nd one that much easier
-
I wouldn’t say this myself without a whole lot of asterisks, but…there is something to this line of critique for sure.@inthehands i think that what you're saying/reinforcing is between naive and dangerous. What contemporary agentic LLMs are doing is not "stupid work". It is work that most people couldn't do, and now requires GWatts of power & almost unimaginable training sets, & incredibly clever once-human sw engineers to be possible at all.
Should there have been more focus on making programming more possible for "non-programmers" ? The hypercard example is a good one, so perhaps yes. But not 100% clear ...