mjhjmtu

I see a bunch of claims that Jack is faster than Pulse and has less latency. How is that so? Why does Pulse call itself lightweight, and the Jack guys call it fat? Could anyone break down the internals of these two daemons to a layman?

Jack requires you-- the knowledgeable user-- to configure the server to determine lowest possible processing latency for your machine. (Processing latency is the time it takes the server to move data to/from the client applications and then send/receive the next "chunk" of audio samples outside the system.) Jack will either deliver those chunks of audio data on time, or it will fail and give you a buffer underrun (sometimes called a "dropout", or pops and clicks). If Jack consistently gets underruns then it's your job to either restart the server with different settings, or change something in the client application(s) to make them more efficient so you can meet your audio deadlines. Since your server settings apply uniformly to all clients, Jack is quite useful for routing audio among multiple audio applications and getting predictable results. (I.e., it's like plugging "jacks" into various audio components.)

Pulse is designed to minimize the number of times the audio drops out due to the server not meeting a deadline for sending/receive audio outside the system. It apparently tries to do this by choosing a large buffer for client applications which don't request low processing latency, then "injecting" samples into that buffer for clients applications that have a deadline sooner. If it tries to inject samples so soon that it misses a deadline and causes an underrun, Pulse will automatically increase the shortest amount of time it will let a client send an audio update to the server. Pulse docs explicitly state that ultra low latency-- say, less than 10ms of processing latency-- is not a design goal. Given that Linux itself (and probably your hardware) was not designed for realtime scheduling of audio, I'd be apt to believe them.

In terms of user-configuration, Pulse is "light". (One might say Pulse has low configuration latency, something which unfortunately many Linux Audio apps apparently disregard.) In terms of its underlying complexity as compared to Jack, Pulse is "fat".

To get a definitive answer on which is faster, you'll just have to get a loopback device and measure the round-trip latency on your own system to know the truth. Round-trip latency is the time it takes your system to process audio and receive what it processed back into the system. There are tutorials online which explain how to do this under Linux. That will give you an idea of what you're actually after, which is the perceived latency-- the time it takes from the moment you trigger an event (e.g., strumming the strings of a guitar) to the moment you first hear the sound that results (e.g., hearing the guitar chord).

Finally, keep in mind that both Pulse and Jack sit on top of ALSA on most GNU/Linux distributions. I know you're only asking about Jack vs. Pulse. But if you're using a single audio application that can connect directly to ALSA there is no conceivable way that adding Pulse or Jack will get you lower perceived latency than ALSA alone. In that sense both Pulse and Jack are "fat".

tldr; ALSA alone is fastest, Jack is useful for chaining together multiple audio applications, and Pulse is probably easiest to use when you don't care about ultra low latency. Ignore any documentation or discussions that use the term latency without explaining what type of latency is meant. (Unfortunately, both the official Jack docs and Lennart's blog entries about Pulse fall into this category.)

Note: There could be edge-cases where you want to use a single audio application and it has a crummy ALSA interface and a decent Jack interface. In that case using Jack may get you lower latency. But if we're talking about apps designed to minimize latency those cases should be rare. But do hook up a loopback device and test my hypothesis!

They are actually similar in being sound servers. JACK is designed for real-time/low-latency response, which is required by professional-level audio solutions. PulseAudio is targeted more at general desktop (where less strict needs apply). PA seems to be heavier than JACK - being more complex induces more overhead. On Linux both use ALSA for real output in the end. With PA, data is often routed from ALSA (application output) to PA (processing) to ALSA (output), which is of course slower than the JACK-ALSA route. On the other hand it is transparent for applications that can't use it natively, since it presents them with a virtual sound card with an ALSA interface.

In any case, unless you intend to produce music or can't live without per application volume control (or forwarding sound to another machine over network), plain ALSA will do just fine, with less overhead. Some drivers can do hardware mixing and even if not, ALSA can mix via a plugin (arguably not as snappy as JACK, but "normal" use should be ok).

It isn't really a question of "vs". At first blush we can see they are both "Sound Servers". Thus, perhaps, conclude one simply needs to choose between them. That's not the case. Compare, for example, a video camera and a FLIR camera, both are cameras. But, one doesn't just "choose" between them. They serve very different roles, those roles can be complimentery, but they aren't in any way competitive. One needs jack, or one needs pulse, or one may need both. The choice is driven by the problem domain, not feature-alities like specific latency.

As to "FAT" vs. not, the term is used in too many ways to be truely meaningful. But, generally, the term FAT used when the application "does it all for you", more or less. "Lightweight" tends towards you getting to load the fucntionallity you want, possibly choosing from a pallet of options, and discarding the rest. Pulse is a "big blob" program to which you give a few parameters and, pretty much, off it goes. Need it, or not, a large amount of functionallity is loaded when you start pulse. Jack is one tiny, and useless on its own, program to which you glue on any number of plugins, programs, etc to build what you want. Programmers tend to view the world from the side of machine resources.

So, pulse is a variable latency server and jack is fixed latency one. Those are their specific problem domains. If you're just watching TV, or listening to music over a network, you surely want pulse. If you're trying to play live electronic music, you surely need jack. If you're watching TV and doing some heavy processing on the sound stream(s), you'll surely need both.

I think Jack sucks and Alsa is not as FAT as she appears... I believe it is unfair to use such adjectives when describing Alsa, seeing as the results could vary greatly and are determined on a strictly individual case basis. Hands down, Jack is 'OK' but no hands, ALSA takes the cake. #TEAMALSA