Lennart Poettering has an interesting discussion on JACK vs. PulseAudio, “PulseAudio and Jack“. I like his table of comparison:
| Consumer Audio (i.e. PulseAudio) | Pro Audio (i.e. Jack) |
|---|---|
| Reducing power usage is a defining requirement, most systems are battery powered (Laptops, Cell Phones). | Power usage usually not an issue, power comes out of the wall. |
| Must support latencies low enough for telephony and games. Also covers high latency uses, such as movie and music playback (2s of latency is a good choice). |
Minimal latencies are a definining requirement. |
| System is highly dynamic, with applications starting/stopping, hardware added and removed all the time. | System is usually static in its configuration during operation. |
| User is usually not proficient in the technologies used.[1] | User is usually a professional and knows audio technology and computers well. |
| User is not necessarily the administrator of his machine, might have limited access. | User usually administrates his own machines, has root privileges. |
| Audio is just one use of the system among many, and often just a background job. | Audio is the primary purpose of the system. |
| Hardware tends to have limited resources and be crappy and cheap. | Hardware is powerful, expensive and high quality. |
I only wish I could qualify in that last corner cell. My hardware is underpowered, cheap, and of dubious quality.
PulseAudio gets a lot of grief on the consumer-audio side already, so I’m not going to pile on it here.
The big gripe I have with PulseAudio on the pro-audio side is that I have to kill it to bring up JACK to do audio work. And that leads me to another point Mr. Poettering makes that I find interesting:
Well, I think we should put the focus on cooperation instead of amalgamation: teach PulseAudio to go out of the way as soon as Jack needs access to the device, and optionally make PulseAudio a normal JACK client while both are running. That way, the user has the option to use the PulseAudio supplied streams, but normally does not see them in his pipeline. The first part of this has already been implemented: Jack2 and PulseAudio do not fight for the audio device, a friendly handover takes place. Jack takes precedence, PulseAudio takes the back seat. The second part is still missing: you still have to manually hookup PulseAudio to Jack if you are interested in its streams. If both are implemented starting Jack basically has the effect of replacing PulseAudio’s core with the Jack core, while still providing full compatibility with PulseAudio clients.
Perhaps I’ll have to revisit how I do things, because I had gotten in the habit of killing PA before even starting JACK, but this makes it sound like that might not be necessary any longer? It’s been a while since I’ve done some recording on my home machine, but I’ll pay special attention to this area next time.
I do agree that “seperation” might be “handy”, because I generally shut down everything outside of the audio apps when recording / mixing. Maybe it’s my equipment, but I don’t feel like I have the horsepower to mess about with non-audio applications at this time. I sure don’t need their audio – although I suppose some of those freaky experimental electronic music dudes might like to mix in system beeps and VoIP calls.
Recent Comments