[PlanetCCRMA] about Fedora updates

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Sat Mar 13 10:06:14 PST 2010


On Sat, 2010-03-13 at 02:35 -0800, Niels Mayer wrote:
> 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.

Hmmm, you should be able to use Planet CCRMA's Jack without installing
or using the rt kernel. 

Do you still have the error messages you were getting? Or a pointer to
them? (and which soundcard you were using?). I have somehow missed this
and should work on fixing it as soon as I can get a f12 machine to test.

-- Fernando


> 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
 
> 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 princicple of least privilege and
> privilege separation.
> 
> 
> -- Niels
> http://nielsmayer.com




More information about the PlanetCCRMA mailing list