Perhaps I was less than clear by not reiterating my position that I understand it's convenience value to those who find it helpful. That you can use and enjoy it is perfectly understandable and fine with me. That doesn't change that the manner in which it has so far been implemented caused me huge problems that took a tremendous amount of work to fix. From other threads and posts, while those like me are in a small niche minority, I am not entirely alone in this.

Please understand that I am in no way campaigning to destroy PA or ignore it's value to many. I'd just like to see the whole area of audio in Linux improve while maintaining options and without power plays that remind me of The Highlander. Yes. It is a strong opinion but it in no way threatens anyone. It is simply a plea for use case.

Tying into this thread, Slackware does not disappoint me since as can be seen it always works hard, thanks to Pat V's drive and wisdom, to stand up and be counted for freedom of options. I'm hoping hazel now is beginning to feel that, too, having now experienced how evern in controversial areas Slackware responds to continue to be what it has always been - adaptable and configurable without constant upheaval and re-inventions of "the wheel".

2 members found this post helpful.

It's history repeating. Remember when ALSA was foisted upon us by the kernel developers?
Yes, but sometimes he has to work within constraints from upstream. That's the way it has always been and always will be. Thankfully, PV makes sane design choices.

1 members found this post helpful.

I don't think that analogy works. OSS and ALSA do exactly the same jobs. They are both simple sound servers and ALSA does not depend on OSS. The kernel development team has covered why ALSA won top honors in the sound server department one aspect of which was ALSA supported OSS but OSS didn't support ALSA. You may need to review that controversy.

By comparison, PA is NOT a sound server, is not in direct competition with ALSA and in fact depends on ALSA or something like it, which is entirely hypothetical at this stage of the game since ALSA is still the default server.

Imagine you'd bought a car whose system computer required some input from you to setup the fuel injectors to what manner of performance (Urban, Highway, High Performance, etc.), fuel preference (Premium, Unleaded, or Regular) and you chose Economy getting 30 miles per gallon at 100 horsepower, but it also allowed drivers who wished to race to set it up for High Performance that increased horsepower to 130 HP at 25 miles per gallon. Then imagine a forced firmware update dropped your car's horsepower to 85 HP and got 20 miles per gallon as well as making it impossible to select any different performance profile, but required no initial setup or input from you. That would likely make some happy but not everyone... just sayin'...

Maybe you guys could just agree to disagree...

ALSA (and OSS) are not sound servers. They are sound subsystems of the OS. Puulseaudio and Jack, and ARTs and ESD, are sound servers.
See also https://en.wikipedia.org/wiki/Advanc...d_Architecture

9 members found this post helpful.

pulseaudio comprises a per-user daemon and 2 APIs: libpulse and libpulse-simple. It's based on a client/server model so it's definitely appropriate to use the term "server" to refer to the daemon component. The fact that it relies on the use of the ALSA kernel interface on the back end doesn't change that.

I wouldn't refer to the in-kernel ALSA sound subsystem as a 'server' myself. But "server" is one of those terms that has been commonly misused and now has multiple meanings, so I suppose the argument could be made, but not by me.

4 members found this post helpful.

Thank you Gazl for pointing out that the term 'server" has been clouded from use/misuse. From my POV "a rose by any other name" applies here. If one substitutes OSS for ALSA sound works. If one substitutes ALSA for OSS, obviously sound works. PA with ALSA works but remove ALSA and sound does not work but remove PA and sound still works. There is a very distinct difference. I'm curious as to how and why PA has not yet included some means of creating it's own loadable module, sub-system of the OS if you prefer, and working to have it accepted by the kernel dev team but that doesn't change the simple fact that choosing the Pure Alsa approach is "closer to the metal" and more efficient and malleable. PA, OTOH, with a subsystem, is more convenient. Perhaps if PA had it's own subsystem it could have more flexibility and less of a performance hit.

I don't understand why there is any disagreement in function or choice whatever nomenclature one prefers to apply. The only possible disagreement I can imagine is that of more options or less options, freedom or restriction. So if I am missing something other than nomenclature, something to do with actual function, I'd actually like to know what that might be.

I also don't understand why there is any perceived conflict here at all since I don't see my view threatening any use case. It reminds me of a line from quintessential Rock 'n Roll....

1 members found this post helpful.

That's beside the point... which is that the change was forced by upstream with no consideration for the end user's freedom of choice.

That's what you were talking about, no?

I'm on very shaky ground here since I've never used OSS and I do feel bad for those who prefer OSS but AFAIK OSS not only didn't accommodate Linux kernel devs as well as ALSA did but OSS also received substantial damning criticism from major Linux audio developers such as the Linux audio giant, Paul Davis. So from my POV as a semi-pro recording enthusiast ALSA serves my purposes better than OSS not only does but apparently ever could. PA doesn't move that effort forward but in fact hampers it which is why I'd like it to be a simple choice without severe penalty for either choice.

That said, I do realize that one similarity between ALSA and OSS does exist, and that is that the OSS devs could have conceivably worked to fix the problems kernel devs faced with OSS yet chose not to. Similarly ALSA devs could have added a layer for simple software mixing/routing (dmix is a bit of a pita and rather clunky so doesn't really compete effectively against PA) to fill the hole that PA did, and they apparently chose not to as well.

Maybe Linux needs a new, coordinated, all-inclusive sound system. That would certainly make all our lives easier and happier, but until such time, if ever, that occurs, if I'm going to be stuck with what we now have, I prefer being stuck with ALSA only and just don't understand why PA apparently requires such exclusivity. Maybe I didn't put enough effort into apulse but I did try really hard to make it work for me and it was very hit or miss, not viable in my work environment. FWIW back when I had an SBLive sound card it was easy to use the better OSS driver module with ALSA, a lot easier than preferring ALSA-only on 14.2.

I could have just stuck with 14.0 but when 14.2 was forced to cave in to PA by Bluetooth it seemed the writing was on the wall where Linux was headed so it appeared only a matter of time until ALSA became "the red-headed stepchild". It may still ultimately be so but that remains to be seen and I take time to point out the lack of viability for PA in some serious niche work so that whatever transpires will hopefully address those issues.

Once again I am not "lobbying" to remove PA. I'm sincerely glad for those of you who like it. I'd just like to see FOSS continue to play nice with it's "compatriots" while it seems some prefer to lock it down.

The default ALSA setup uses DMix.

The reason that ALSA was pushed to the front seat, replacing OSS, was mainly driven by the fact that OSS version 4 was released as proprietary software.
It took 5 years for the OSS developers to realize their catastrophic mistake but then the damage had already been done.

1 members found this post helpful.

So true. I love(d) OSSv4 (I maintained a distro with OSSv4 for years), it is/was superior to ALSA in most ways. But when PA arrived OSSv4 lost most of it's reason to exists in the consumer space (OSSv4 still has better support for several high-end sound cards like RME etc).

PA has had it's share of issues, but in 2019 it's the best (consumer) audio solution on Linux, with JACK for "professionals".

1 members found this post helpful.

Thanks Eric. That was my recollection of the facts as well... That and the laggy sound in Circuslinux after switching... On a near new 3.4GHz P4...

I've been saying it for years. How I wish OSS supported the Intel hd audio in my laptop... I'd switch back in a heartbeat.

Which distro were you maintaining?

Since I always and immediately create a ~/.asoundrc I did in fact miss that /etc/asound.conf does come with DMix as default. Thank you for that clarification.