Bug 469335

Summary:	[pulseaudio] no request for real-time/high-priority scheduling through PolicyKit
Product:	[Fedora] Fedora	Reporter:	Joachim Frieben <jfrieben>
Component:	pulseaudio	Assignee:	Lennart Poettering <lpoetter>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	10	CC:	bgamari, home, leigh123linux, lkundrak, lpoetter, pierre-bugzilla, robertdaleweir, sameer.subscriptions
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-12-08 19:29:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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?