[PlanetCCRMA] about Fedora updates

[Niels Mayer]

On Wed, Mar 10, 2010 at 7:28 AM, Peter Kirn <peter at createdigitalmedia.net>wrote:

> I just want to put in my own vote here to say -- no, it's not
> necessary to shut down pulseaudio in order to run JACK.


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.

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
http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-January/016334.html
*Fernando Lopez-Lezcano* states:

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


As I'm using stock Fedora12, not the CCRMA RT kernel, the CCRMA jack doesn't
work for me:
http://comments.gmane.org/gmane.comp.audio.planetccrma.general/9373 --
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

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.

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

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.

It'd be
> interesting to have a custom package that ran JACK as a service, I
> suppose; I could see this being an interesting way of doing easy-on
> performance/installation machines, but even that wouldn't be strictly
> necessary.
>

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.

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 security
<http://en.wikipedia.org/wiki/Principle_of_least_privilege>princicple<http://en.wikipedia.org/wiki/Principle_of_least_privilege>of
least
<http://en.wikipedia.org/wiki/Principle_of_least_privilege>privilege<http://en.wikipedia.org/wiki/Principle_of_least_privilege>
and
privilege separation <http://en.wikipedia.org/wiki/Privilege_separation>.

-- Niels
http://nielsmayer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20100313/f55a9c9e/attachment-0001.html