27

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?

  • 2
    As I understand them they are designed for different purposes which might explain the problem of comparing them. – N.N. Mar 22 '13 at 8:09
30

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!

9

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).

  • Is the link to the PA image misdirected? – N.N. Mar 22 '13 at 11:08
  • @N.N. worked for me, but I changed it now, so hopefully it'll get better. – peterph Mar 22 '13 at 11:18
  • @Sukminder the error seems to be quite random. – peterph Mar 22 '13 at 17:39
  • 1
    I don't think this answer cuts it: first you don't say how Jack is faster, and second you convolute the answer with an example that involves a pseudo-alsa driver, rather than a direct Pulse Sink. The question is pretty clear, but to be more direct -- how is JACK faster at its fastest, compared to Pulse at its fastest? – Evan Carroll Mar 23 '13 at 16:22
  • I'm just tired of hearing the Jack team say it's faster because it is not has heavyweight without explaining why heavyweight -- and, what in heavweight -- makes Pulse slower. This answer feels like a Cartesian reassertion of the premise in the question. – Evan Carroll Mar 23 '13 at 16:23
4

Jack is for applications that needs low latacy, eg: audio enginering/creation for musicans, video makers, etc

  • no resampling!
  • force software mixing sources
  • proper routing things (sound, timesync, etc) between apps, devices, ladspa/lv2/vst plugins, etc
  • can be used with pulseaudio (bridge)

Pulse is for regular desktop applications (do not expect low latacy)

  • provide compatiblility with aRts and esd
  • can be used as alsa and oss output
  • force software resampling
  • force software mixing sources
  • software upmix, downmix, etc
  • gives nice api for plugins (eg: pulseeffects)
  • simple routing (to plug output into another device or app)
  • volume control per app

Alsa userspace layer (not a drivers) do minimum (latacy between[*])

  • [*]hardware resampling, mixing sources, upmixing, etc (you need adequate sound card to use it, otherwise software will be used)
  • ladspa plugins which you can set in ugly config format
  • simple/global volume levels control

In most cases Pulse is the best choice for regular desktop users. Jack is the best choice for musicans, etc.

  • I dropped an upvote, but I'm not sure it's an answer to the question as much as a good comparison. Why is PulseAudio slower if it's not doing re-sampling? – Evan Carroll Feb 26 at 23:36
  • > Why is PulseAudio slower if it's not doing re-sampling? – 3ED Feb 27 at 9:12
  • Not? They do stuff in software eg: force resampling (you can choose between 2). Jack partly bypasses alsa. Jack is something similar to asio. Pulse similar to standard windows sound from vista upward. Not the same but similar concepts. Pulse is brilliant for cheap/integrated/not properly supported sound cards which can't do things in hardware. – 3ED Feb 27 at 9:26
2

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.

  • 1
    Somewhat subjective: I think the sound server should follow the JACK design, since it is impossible to get rid of any latencies added by the server. It is then up to the application developer to use larger buffers for disk or network I/O, sample rate conversion etc. Latencies above the 10 ms mark is to high. – user877329 Mar 8 '17 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.