Ahh, even better... Vintage test equipment.
Beware, that disease is catching and never entirely curable. Voltmeters are particularly pernicious, being simultaneously easy to obtain and easy to justify. Scopes and signal generators are safer - since they take up more space, it's slightly easier to notice when you have enough only need one more.

Simpson did make nice gear, and I have just realised I don't have any. I'll be right ba...

Ahem, my current "old faithful" bench meter is one of these... And yes, I have used the 5Kv range, and I am still alive.

Project #379 (currently occupying said bench) is to fix the '90s Hameg (yeah, I know, kinda "meh") 40MHz storage scope I got for a song. Digital overlay and analog side don't agree on what range channel B is on, and that's some in-house shift-register data-bus malarkey that looks deliciously entertaining to figure out. Also I'm pretty sure it's the last "hybrid" storage scope with a real tube...
But I digress. I wouldn't want to annoy the locals (more), with off-topic not-conspiracy non-whinging now would I.

Oh, too late. Here they come for amateur philosophy hour.

Righty ho then, seems I'm rolling rocks up Mt. Kruger again. Guess I'll stop now before this gets out of hand.

Shame, audio engineering is a bit of a hobby of mine. Mostly old-school analog stuff mind, but here I was hoping for a real debate and maybe an excuse to unpack some of my pets test equipment. Nevermind.

I see... When rational arguments don't go your way, appeal to, what, garden-shed psychology? philosophy? No thanks.

If you think your ears are a reliable instrument, you might be happy reading tea leaves.

I'm not going to argue this, you'll just keep trotting out the old "if you can't hear the difference" line until we both die of old age.
I've been there before, with many an audiophool convinced that the special crystal power lead stands or $8000 speaker cables they got conned into buying make a real difference. All that happens is abandonment of any kind of scientific method for a bunch of feely-woo about "warmness" "depth" "clarity" and other intangible unquantifiable nonsense. Sound reproduction is not magic, and any parameter thereof that matters can be measured and quantified.

Further, it can be measured and quantified with the kind of equipment that costs very little these days - so you are either intentionally omitting measurements because you know they won't prove your point, or you lack the expertise to conduct them. Either way, I call shenanigans. The burden of proof is on the one making the bold claims, and right now that is you.

It's not so difficult to hook up a scope and show us the difference either. If the ALSA defaults really sound that bad, it should be quite obvious on even rummage-sale grade 10MHz gear.

"If you don''t hear the difference it doesn't mean my gizmo isn't working, you must just not have golden ears" is the standard line of audiophool snake-oil salesmen everywhere, always has been.

Yeah, I know. I've got an old Pi with a DAC hat in my lounge that's set up that way. It only runs MPD, so who cares about stream mixing. vOv

That's... Interesting. I've talked to people having strange issues with the system bell before, and never really figured out what was going on. That might be a useful clue the next time it comes up.

As they say in the industry, 'scope shots (showing resampling artefacts) or it didn't happen. You're writing guides on "bit-perfect" "audiophile" sound, so I assume you have a decent 'scope handy to test your findings, right?
Alternatively, feel free to point out the lines in the kernel sources that do this. I've looked (a long time ago, to be fair), have you?

Again, it is not. Resampling is forced if you use dmix, because dmix can only mix streams at the same (fixed, when you configure the dmix pcm) sample rate. By default, that's 48kHz.
Resampling is also used if there is a 'plug' PCM involved and your input doesn't suit the next component in the chain (likely dmix if you are using any of the "default" devices), because automatically converting formats and sample rates is what the plug PCM does.

Use a 'hw:' PCM directly, and no software resampling will happen, at all. Regardless of what plugins you have installed or not.
If your hardware doesn't support what you're trying to play, it will simply fail.
This, by the way, is what audiophools everywhere have been doing for decades to get that magical "bit-perfect" output. It's a pain in the ass because you can only play one stream at a time and it will lock the output PCM, but that's not a problem for e.g. a dedicated LMS or MPD music player.

Unlike dmix, which always runs at the 48kHz common-denominator unless manually told otherwise, pipewire will intelligently try to find the highest sample rate that works for both the input stream and the output hardware, and set that up dynamically when you start playback. If it later needs to mix in something else, it'll upsample (which is lossless for any sane rate converter) the new stream to suit.

All that happens without the user needing to touch anything, or grub around in arcane and poorly documented ALSA configuration files. While it might not be a benefit to you, I'm pretty sure it's a win for people who just want the best audio they can reasonably expect, with the least hassle.
Bear in mind, the vast majority of normies these days have no idea what sample rate means beyond "bigger number better", get their music from youtube or $streaming_service, and play it back on some horrid little class-d bluetooth speaker. If pipewire makes that miserable experience even a fraction better by doing sane things with resampling by default, it's a service to music everywhere.

Pipewire is not perfect, and yes, it's a product of the "evil" freedesktop crowd... But it is a whole lot better than pulseaudio, and a whole lot less cumbersome to set up than a bunch of ALSA plugins.

Once, I did what you're doing. I wrote complicated asound .rc files, I pored over kernel sources and I hung out on mailing lists trying to make sense of the piss-poor ALSA documentation... Because the alternative was pulseaudio (or ESD, *shudder*), and pulseaudio sucks.
Now, we have a sound-server that sucks a whole lot less. It's still a sound server for better or worse, but there are good reasons every other modern OS uses one. If you don't want it, that's fine, you do you. But don't spread FUD about being "forced" to do things, the choice is yours same as it ever was.

Aww, nesting only goes 3 deep, this board is no fun. *waits patiently for fun-police*

Maybe we have to say his name thrice or something?
...Or it's just nap time.

Wayland/pipewire does just work on other non-systemd distros. Not wanting to run systemd does tend to go well with avoiding modern software trends generally, but it's really not a package deal so-to-speak.
I'm running a bleeding-edge Gentoo openrc install, with X11 and pipewire. There's nothing mutually exclusive there, and mixing-and-matching your preferred components is a tradition as old as GNU/Linux itself. It's not even a particularly unusual combination as gentoo installs go.

If Devuan goes down the "reject anything new" path that certain voices seem to be pushing around here, all that is going to happen is a slow fade into irrelevance.

Yeah, figuring it out was kinda fun while it lasted. Now that OpenRC has user-services, I expect that's the way I'll go next time I feel like messing with it.

IMO, for all its other flaws, systemd user-units aren't inherently a bad idea. The trick is, as usual, implementing something comparable without falling into the same scope-creep tarpit.
Devuan is going to need a generic solution sooner or later, if they're willing to embrace OpenRC as a first-class (or even default) init system, it can just be leeched off Gentoo and the solution already in testing.
If they want to cling to sysvinit as the default, we need something else... Which will likely have to be a Devuan project or a colab with Slackware, since pretty much everyone else has moved on from pure sysv.

At the very least, shipping an interim launcher in shell (aka. nicking gentoo-pipewire-launcher) and packaging some simple xdg-autostart files that work with common DEs would go a long way to alleviating the "I installed the default KDE desktop and stuff doesn't work" pain. It's not exactly a lot of work either.

Yeah, and for what it's worth I'm not usually quite as confrontational as I have been lately... This pattern from the admin(s) has been going on a long while, and today I just had a gutsfull of it.
Sorry that it was your intro to this board and all that.

Ahh, personal attacks. The last refuge of the incompetent. Bye go, I'm done arguing with you.

Nice one nuking the image BTW, did that land a little close to home?

Ahh yes, the old "everything new is bad, we're all doomed, my generation knew better, damn kids get off my lawn, why don't we all just die" line. All very helpful and productive I'm sure.

More productively (but probably not diplomatically), if this thread is anything to go by.
If I count correctly, four five, if I'm being generous users have piped up with technical support for this technical question, and through their efforts the problem is now solved. You are not one of them, nor have you offered any relevant information or technical assistance. Same goes for zapper.

Resampling is necessary in many run-of-the-mill scenarios. If all you want is to play one stream, that can be done with no resampling. If you want the kind of automagic mixing of multiple inputs and outputs with hotplugged devices over bluetooth and dog knows what else that people tend to expect from a modern system... Some resampling will be happening somewhere.

This is one advantage of pipewire over pulseaudio or ALSA DMIX, it tries quite hard to match your stream to a samplerate your hardware supports, and to never downsample anything if it can be avoided.
Whether or not pipewire's spa resampler is suitable for the cases where it is needed... That's up to your (presumably bat-like) ears to decide.

In general though, unless your resampling algo is really bad (or you're using a SoundBlaster 16), your speakers and listening environment will be doing more to screw up reproduction than anything on the source end.