Bug 475206

Summary:	Sound crackles with SDL_mixer using programs
Product:	[Fedora] Fedora	Reporter:	Hans de Goede <hdegoede>
Component:	pulseaudio	Assignee:	Lennart Poettering <lpoetter>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	lkundrak, lpoetter, pierre-bugzilla
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-12-08 19:32:01 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 Hans de Goede 2008-12-08 14:51:50 UTC

Description of problem:
The sound crackles when using SDL_mixer using programs, see bug 474745. I can reproduce this on my fully up2date F-10 x86_64 system.

The funny thing is if I edit /etc/pulse/daemon.conf and then
uncomment these 2 lines:

realtime-scheduling = yes  
realtime-priority = 5  

And then kill pulseaudio and restart it, the problem goes away. Even though when started from a terminal pulseaudio complains it cannot get RT permission and according to top, indeed it has not gotten realtime permission.

This is not a glitch, re-commenting the lines and restarting pa again, reintroduces the crackling. The crackling happens the most with certain usage patterns. For example hovering the mouse over the X to close a window, so that it gets highlighted, causes the crackle. Note I'm not using compiz, just plain metacity.

It seems that these 2 config options change pa's behavior in some (possitive) way even if it could not get RT priority.

To reproduce do "yum install creack-attack" and then either start crack-attack, or play its music using the SDL_mixer cmdline player:
playmus /usr/share/crack-attack/music/prelude.xm

Comment 1 Lennart Poettering 2008-12-08 19:32:01 UTC


*** This bug has been marked as a duplicate of bug 474450 ***