<div class="gmail_quote">On Wed, Mar 10, 2010 at 7:28 AM, Peter Kirn <span dir="ltr"><<a href="mailto:peter@createdigitalmedia.net" target="_blank">peter@createdigitalmedia.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just want to put in my own vote here to say -- no, it's not<br>
necessary to shut down pulseaudio in order to run JACK.</blockquote><div><br></div><div>The stock Fedora version of Jack does not stop pulseaudio or prevent it from interfering with sound devices. Therefore, Peter's statement only applies to those using CCRMA kernel and Jack. My make-or-break moment for giving Pulseaudio the boot was when it started interfering with MIDI devices in Jack that have nothing to do with streaming audio. After uninstallation, this stopped happening.</div>
<div><br></div><div>For those using the stock Fedora Jack and Kernel, uninstalling pulseaudio may be the only reliable solution, as only the CCRMA version of Jack avoids pulseaudio pitfalls: For example, in</div><div><a href="http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-January/016334.html">http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-January/016334.html</a></div>
<div><span class="Apple-style-span" style="font-family: 'Times New Roman'; font-size: medium; "><b>Fernando Lopez-Lezcano</b> states:</span></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
If you are using Jack and the Planet CCRMA jack build then it should not be necessary to disable PA. Pulse will relinquish the card when Jack starts and reaquire it when jack stops.</blockquote><div><span class="Apple-style-span" style="font-family: 'Times New Roman'; font-size: medium; "></span></div>
<div><br></div>
<div>As I'm using stock Fedora12, not the CCRMA RT kernel, the CCRMA jack doesn't work for me:</div><div><a href="http://comments.gmane.org/gmane.comp.audio.planetccrma.general/9373">http://comments.gmane.org/gmane.comp.audio.planetccrma.general/9373</a> -- CCRMA's Jack is incompatible with standard F12 kernels. THis is why I end up having to install CCRMA RPM's manually -- because setting up CCRMA in my yum repos delivers a nonworking Jack and therefore, kills all my music apps. Yet, I'm successfully running all these "manually" w/o RT kernel or CCRMA's Jack: bristol-arp2600-0.40.7-1.fc12.ccrma.x86_64 bristol-obx-0.40.7-1.fc12.ccrma.x86_64 qmidiroute-0.2.1-4.fc12.ccrma.x86_64 timemachine-0.3.1-2.fc12.ccrma.x86_64 bristol-juno-0.40.7-1.fc12.ccrma.x86_64 qmidiarp-0.0.2-4.fc12.ccrma.x86_64 bristol-memory-0.40.7-1.fc12.ccrma.x86_64 bristol-dx-0.40.7-1.fc12.ccrma.x86_64 bristol-prophet-0.40.7-1.fc12.ccrma.x86_64 linuxsampler-1.0.0-2.fc12.ccrma.x86_64 patchage-0.4.4-1.fc12.ccrma.x86_64 bristol-mono-0.40.7-1.fc12.ccrma.x86_64 bristol-mixer-0.40.7-1.fc12.ccrma.x86_64 clalsadrv-1.2.2-1.fc12.ccrma.x86_64 galan-0.3.0-0.beta7.2.fc12.ccrma.x86_64 ffado-2.0.0-1.fc12.ccrma.x86_64 jacktrip-1.0.5-1.fc12.ccrma.x86_64 bristol-poly-0.40.7-1.fc12.ccrma.x86_64 bristol-roadrunner-0.40.7-1.fc12.ccrma.x86_64 bristol-mini-0.40.7-1.fc12.ccrma.x86_64 qmidicontrol-0.0.1b-4.fc12.ccrma.x86_64 lv2-linuxsampler-plugins-1.0.0-2.fc12.ccrma.x86_64 bristol-axxe-0.40.7-1.fc12.ccrma.x86_64 bristol-rhodes-0.40.7-1.fc12.ccrma.x86_64 fweelin-0.6-1.fc12.ccrma.x86_64 libgig-3.3.0-1.fc12.ccrma.x86_64 sndpeek-1.3-2.fc12.ccrma.x86_64 bristol-solina-0.40.7-1.fc12.ccrma.x86_64 bristol-hammond-0.40.7-1.fc12.ccrma.x86_64 gmorgan-0.25-2.fc12.ccrma.x86_64 linuxsampler-dssi-1.0.0-2.fc12.ccrma.x86_64 bristol-aks-0.40.7-1.fc12.ccrma.x86_64 flowcanvas-0.6.0-1.fc12.ccrma.x86_64 bristol-b3-0.40.7-1.fc12.ccrma.x86_64 bristol-odyssey-0.40.7-1.fc12.ccrma.x86_64 mcontrol-0.1.03-2.fc12.ccrma.x86_64 xjadeo-0.4.7-1.svn200.fc12.ccrma.x86_64 bristol-vox-0.40.7-1.fc12.ccrma.x86_64 ams-2.0.0-1.fc12.ccrma.x86_64 libffado-2.0.0-1.fc12.ccrma.x86_64</div>
<div><div><br></div></div><div>The biggest benefit to getting rid of pulseaudio is performance and latency. I'm no longer annoyed at pulseaudio chewing up a few % CPU (on an outrageously fast CPU), and actually raising it's temperature/noise/power consumption, all for no purpose whatsoever. It's simple -- buy a $20.00 USB headset so you can use skype/ekiga and dedicate the headset to that. Use the built in soundcard for all system audio/web/playback, sharable due to ALSA plughw/dmix, and have a proper multichannel soundcard controlled by JACK for audio/video work. I probably get back the $100.00 I spent on hardware in power-bill savings from not running pulseaudio. </div>
<div><br></div><div>On a laptop, w/ one shared soundcard, then I leave pulseaudio running, even though it significantly reduces battery life (take a look at the number of interrupts happening from simply playing a MP3 on a laptop w/ pulseaudio running). </div>
<div><br></div><div>The only feature that pulseaudio gives -- networking remote sound to your desktop -- is one feature I and most other fedora users will never need or use. Pulseaudio is like the SUV of soundservers. You don't need all the performance disadvantages, security risk, and complications it provides for the rare occassion that you need to network sound to your desktop. Just like you don't need an 4WD SUV to increase your rollover risk on California highways, just so you can drive up to the snow a few days every year.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It'd be<br>
interesting to have a custom package that ran JACK as a service, I<br>
suppose; I could see this being an interesting way of doing easy-on<br>
performance/installation machines, but even that wouldn't be strictly<br>
necessary.<br></blockquote><div><br></div><div>It doesn't necessarily have to be a "service" per-se (which usally is associated w/ it's own user, not the user invoking the service). You can simply go to System->Preferences->Startup Applications->Add and setup a command to run Jack when your gdm session starts.</div>
<div><br></div><div>It's the same place, by default, that pulseaudio and kde/pulseaudio get launched on gdm login. Therefore, just like pulseaudio, there's no overt security issue -- you're simply starting a background process/daemon as your user. Which is also exactly where things end up falling apart as well. E.g. when a media process is invoked there's no way of telling whether it's associated with group video, audio, etc, and whatever additional privileges or device access granted via those groups. If pulseaudio was able to do much finer-grain access to devices, as opposed to hogging a whole device unto itself, I would imagine it would run more smoothly, and act more unixy, including allowing multiple users to securely use exactly the hardware they need w/o locking out everything else. IMHO a proper architecture for pulseaudio would make it a standard unix daemon, with each kind of access (MIDI, audio, video) given it's own separate minimum-privilege daemon-user with only access to devices under its own control, following <a href="http://en.wikipedia.org/wiki/Principle_of_least_privilege">security </a><a href="http://en.wikipedia.org/wiki/Principle_of_least_privilege">princicple</a><a href="http://en.wikipedia.org/wiki/Principle_of_least_privilege"> of least </a><a href="http://en.wikipedia.org/wiki/Principle_of_least_privilege">privilege</a> and <a href="http://en.wikipedia.org/wiki/Privilege_separation">privilege separation</a>.</div>
<div><br></div><div>-- Niels</div><div><a href="http://nielsmayer.com">http://nielsmayer.com</a></div></div>