Bug 469335 - [pulseaudio] no request for real-time/high-priority scheduling through PolicyKit
Summary: [pulseaudio] no request for real-time/high-priority scheduling through PolicyKit
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 10
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-31 11:27 UTC by Joachim Frieben
Modified: 2009-01-05 02:42 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-12-08 19:29:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Joachim Frieben 2008-10-31 11:27:21 UTC
Description of problem:
Inspection of file .xsession-errors on a current "rawhide" system reveals a denial of real-time/high-priority scheduling for PulseAudio. There is no other feedback to the user than through this hidden file [and /var/log/messages], thus the issue will remain unknown to the vast majority of them.

Version-Release number of selected component (if applicable):
pulseaudio-0.9.13-4.fc10.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Start GNOME session.
2. Open $HOME/.xsession-errors.
  
Actual results:
Real-time/high-priority scheduling is reported to be denied.

Expected results:
Real-time/high-priority scheduling should have been granted or at least, the user prompted how to proceed in this matter.

Additional info:
- In F8, PolicyKit used to prompt the user for authorization of real-time/high-priority scheduling.
- The system was installed from scratch by means of the F10-Snap3 live image, and the user home directory had been cleaned up beforehand.
- PolicyKit-*-0.9-3.fc10.x86_64.

Comment 1 Lennart Poettering 2008-10-31 18:14:07 UTC
PA mostly  works fine without RT privs. The user doesn't need to know.

Comment 2 Ben Gamari 2008-11-09 20:41:13 UTC
Are there plans to grant RT privileges by default for desktop installations?

Comment 3 Bug Zapper 2008-11-26 04:32:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 4 TR Bentley 2008-11-30 05:56:42 UTC
(In reply to comment #3)
> This bug appears to have been reported against 'rawhide' during the Fedora 10
> development cycle.
> Changing version to '10'.
> 
> More information and reason for this action is here:
> http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This happened on my box upgraded from F9 to F10.  The sound feels like a regression and I get "Phonon" errors on startup seying audio device does not work.

Comment 5 Sameer Naik 2008-12-03 16:53:48 UTC
Seeing the same issue, but i won't call it cracking, but more like audio glitches
when i log into kde4 the login sound starts having these gliches.
when playing audio in amarok, this happens predominantly when the first song start playback, thereafter its alright.
playing files in vlc also produces the same glitches, but not continuously, just sometimes here and there.
in my opinion, audio frames are being dropped.

In gnome i am able to use alsa output instead of pulseaudio, in which case its all perfect. But i am not able select alsa as the backend for phonon.

[sameersbn@sameer ~]$ lspci  | grep -i audio
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)

Comment 6 Robert Weir 2008-12-05 03:50:08 UTC
  I am unable to use VLC, my preferred DVD Player.  The video plays well but the sound is unbearable.  Is there an ETA for addressing this bug? I am using FC10 and X86_64 version.

Comment 7 Lennart Poettering 2008-12-08 19:29:45 UTC
(In reply to comment #2)
> Are there plans to grant RT privileges by default for desktop installations?

No. It's a security issue. Allowing a user process to be RT means allowing a user to freeze the machine.

Comment 8 Joachim Frieben 2008-12-08 20:03:55 UTC
Why not stick with the user interaction through the PolicyKit GUI as in F8? You get prompted, and you decide yourself whether you want real-time/high-priority scheduling for PulseAudio to be enabled or not.

Comment 9 Ben Gamari 2008-12-08 22:12:43 UTC
(In reply to comment #8)
> Why not stick with the user interaction through the PolicyKit GUI as in F8? You
> get prompted, and you decide yourself whether you want real-time/high-priority
> scheduling for PulseAudio to be enabled or not.

Yes, this seems like the sane thing to do. Let the user decide.

Comment 10 Ben Gamari 2008-12-08 22:15:35 UTC
(In reply to comment #7)
> (In reply to comment #2)
> > Are there plans to grant RT privileges by default for desktop installations?
> 
> No. It's a security issue. Allowing a user process to be RT means allowing a
> user to freeze the machine.

It's only a security issue if the code itself is flawed. I'm not familiar with the pulseaudio code base. How many lines of code would be running at RT? If there's a suitable separation between time-sensitive and time-insensitive operations, it shouldn't be too difficult to verify that the code is safe. Wasn't pulseaudio designed to run at RT at some point?


Note You need to log in before you can comment on or make changes to this bug.