Is There a Common File Used as Identification by Dependent Apps to Search and Call Pulseaudio?
 

Greetings
I thought this deserved it's own thread since it looks like I'm not alone in wanting to go "pure alsa" and it already looks like some are having minor issues with updates of some apps. I'm wondering just how specific the call for Pulseaudio is as in whether apps just seek a qualifying pulse name and use whatever resources it has to offer. If this were so it might be possible to duplicate Jack files and rename them so they "answer the call". Jack does essentially the same job (and more) as Pulseaudio and with a LOT less overhead.

I may be grasping at straws but I hope it is possible and intend first to discover if there is some standard convention used by all or even most apps to determine if something it needs is present, and if so, I intend to try with Jack.

Am I way off base in that there is no consistency? or is this simply as I'm hoping, SOP?

well I'd think so, if firefox is dropping alsa for Pulseaudio, and others are using Pulseaudio for the sound connections, then yes their is a provision within the code of same said app to seek out some Pulseaudio config file or in /dev/sdn or some such other place to verify that the sound that it is using it there.

to try and fake it out into thinking you have Pulseaudio and then try to get it to use alsa in place of it, that might be a struggle depending on how that app then connects to the Pulseaudio it thinks it has, if it is not compatible then again you will get a fail to connect. that is just a off the top of my head logical answer. W/O any real investigation.

You're trying to swim upstream, so yes, you're going to have struggles.

Hello,

Sorry for the OT, but there seem to exist ways to make PA and JACK peacefully coexist. Caveat: I didn't try.

Links:
https://forum.manjaro.org/t/how-to-r...as-friend/2086
http://jackaudio.org/faq/pulseaudio_and_jack.html
https://github.com/jackaudio/jackaud...er_PulseOnJack

Best,

Perhaps you could just consult the provided documentation to help implement what you want (I googled for "pulseaudio api"). A simple version is shown at:

https://www.freedesktop.org/software...en/simple.html

with more features/information/examples available from the index there.

chris

Thanks for responses so far but it appears I need to expand on what I'm trying o accomplish. I am aware that there is a version of Jack that plays nice with Pulse but I fairly often do DAW work and don't want the latency inherent in Pulse and don't wish to give up the handful of features in the pulse-friendly version of Jack

I'm thinking that it is fairly commonplace that apps call for support apps and/or libraries much as Unix Law (paraphrased) of "make apps that do one thing and do it well and chain them with other similar apps to extend the reach". An example of how this is used in all operating systems in browsers, when we navigate to. a YouTube video url containing say an mp4 encoded video the browser will use whatever is established as the default app for handling mp4 or ask us which we would like to use currently.

I am also aware that when MS took over Skype and required an update to a newer version simply renaming the version allowed the previous version to work just fine. Software does such things from time to time.

Steam seeks Pulseaudio as well as NetworkManager, neither of which I have installed and active, but marches right along and works just fine on my also-only plus /etc/rc.d/rc.inet1 system. Regarding that I should point out to some here that Pulseaudio is NOT a sound server. It is utterly dependent on some sound server such as ALSA. Remove ALSA but keerp Pulse and you have no audio. Frankly I don't know that it orchestrates OSS or eSound (and don't much care) but the salient point is Pulseaudio is just a manager of a server... as is Jack. One asks it to deliver Input/Output data to assigned locations and resources, and if properly set.. voila! Sound! To be perfectly clear the software assignments from Pulseaudio are not needed with my sound card as it has hardware mixing and adding another layer of software is largely redundant and Jack does it at far less "cost".

So I'm wanting to discover if many or most apps have a consistent method of searching and being satisfied an extension app exists. Do they look in "/usr/bin" for the executable? or do they seek some config file in either $HOME or /etc?

I'm not altogether confident that I can "fool" apps into using the essentially same resources provided by Jack in place of Pulseaudio but I am willing to wrestle with it to find out. I just don't yet know what search terms are used for an app to be satisfied it has found what it seeks - a specific manager of the resources or any manager that offers the same "workforce" capable of almost identical work, but "cheaper".

From what I can find out, pulseaudio libraries expect to talk to a server. https://www.freedesktop.org/wiki/Sof.../FAQ/#index6h3

The format for the server URL is described at https://www.freedesktop.org/wiki/Sof...ServerStrings/

You'd have to implement the interface pulseaudio code expects to see when it talks to that server.

It's up to you to decide how to spend your time, but whatever you did would be dependent upon that interface being stable. Sisyphus comes to my mind for some reason.

Thank you Richard Cranium, those are some useful, if a bit confusing links. The first page does clear up that pulseaudio can work with a variety of sound servers but it also says Pulseaudio is is a drop-in replacement for eSound which I don't understand since I am under the impression that pulse requires an external, direct sound server to manage what only such a server can accomplish.

It still seems to me that there doesn't have to be a hard dependency on pulse. As long as an app can get to the ultimate destination, the sound hardware's resources, it shouldn't "care" what facilitates that. A simpler solution could be hinted at in the line -----

I've tried this and without knowing (yet) how to define "needed" many apps are written so that if it finds pulseaudio exists it will just grab it up and use it, looking no further. It seems a very loose definition of "need" so unless there is a way to force trying to connect to ALSA (or whatever other sound server anyone uses) FIRST, which seems to me in the code of each external app seeking sound resources, not in either ALSA or Pulse, and only fallback on Pulse if that doesn't work, it isn't yet a solution for me so despite being a struggle, I will continue but now at least I have an alternate to consider and research. It baffles me why Pulseaudio behaves or is looked to as a hard dependency so quickly by such a large part of the Linux Community when it obviously isn't required to make audio work. Oh well... Thanks again.

You can set up pulse to expose a DBus endpoint, but that doesn't appear to be the default anybody uses.

I didn't delve into the pulse client library very deeply at all, but the underlying idea appeared to be that if you've linked in the pulse client code, then you expect to use PulseAudio. I can think of ways to make that more-or-less optional by an application, but you'd normally control that by some type of configuration; either you tell the app that you want to use X for sound or you provide an ordered list of providers that the application will attempt to use and will stop on the first one that appears to work.

But all of that is work. Easiest for the app to use Pulse and be done with it.

That might be a valid solution if I could force Pulse to be the very last in line so it never spawns unless it is absolutely necessary ie: the app will stall if it isn't present. So far I have been unable to do that and have preferred pure alsa. Apparently there are enough who think similarly since the pure-alsa alternative is officially a part of Current and slated for the next Full Release. I have no problem with people choosing pulseaudio for whatever reason, but I do want the ability to choose.

If I don't assign some kind of "helper app" to handle say PDF documents (and those are somewhat proprietary as I recall) in browsers, they simply ask me what I want to use... doesn't seem like Rocket Surgery.

The difference is this is all handled by the WM/DE and/or xdg based on the file extension. I haven't dug into the resources posted in this thread, but I imagine there's nothing in place like that for sound output. Most programs I've used that have the ability to output to multiple sound systems (pulse, alsa, etc) usually have to be physically changed in that program's options. I'd be curious what kind of checks could be used to determine if a particular sound system would work other than verifying it is running...