Bug 494747

Summary:	tsched=0 does not fix sound in vmware server 2.0 fedora guest
Product:	[Fedora] Fedora	Reporter:	Jason <nospam>
Component:	pulseaudio	Assignee:	Lennart Poettering <lpoetter>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	lkundrak, lpoetter
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-04-13 21:05:16 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 Jason 2009-04-07 23:45:57 UTC

Description of problem:
Editing /etc/pulse/default.pa and changing the line:
load-module module-hal-detect
to:
load-module module-hal-detect tsched=0 

on a Fedora 10 or 11 Alpha Guest running in VMware Server 2.0 would cause sound to function properly. As of the Beta this is no longer the case.

Version-Release number of selected component (if applicable):
Fedora 11 Beta

How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 11 Alpha as a VMware Server 2.0 guest operating system and notice that sound does not work properly.
2.Edit /etc/pulse/default.pa and change the line:
load-module module-hal-detect
to:
load-module module-hal-detect tsched=0 
3. Reboot
4. Notice sound works.

5. Install Fedora 11 Beta as a VMware Server 2.0 guest operating system and notice that sound does not work properly.
6. Edit /etc/pulse/default.pa and change the line:
load-module module-hal-detect
to:
load-module module-hal-detect tsched=0 
7. Reboot
8. Notice sound still does not work.

Actual results:
Configuration change does not cause sound to work.

Expected results:
Configuration change should cause sound to work.

Additional info:
This problem actually exists under Fedora 11 Beta guest operating system under VMware Server 2.0 running on Windows Vista x86_64, Red Hat Enterprise Linux x86, and VMware Fusion 2.0 as far as I can tell. This is from moving the same install between host systems, not actually installing the guest OS three different times.

Comment 1 Lennart Poettering 2009-04-10 19:56:25 UTC

Please explain what you mean by 'does not work'.

Comment 2 Jason 2009-04-10 20:17:55 UTC

When playing sound in a (vmware) virtual machine without this setting in Fedora 11 Alpha and earlier guest everything sounds sped up by a lot; a few minute long song will appear to play in a matter of seconds. Either removing pulseaudio or using this setting would resolve the issue, however that is no longer the case in Fedora 11 Beta

Comment 3 Lennart Poettering 2009-04-13 15:56:40 UTC

Sounds like a bug in VMWare. PA relies on correct timing information from the audio driver/sound card. In your setup we don't seem to get this correctly.

Please file this bug against vmware upstream.

Comment 4 Jason 2009-04-13 19:31:18 UTC

I disagree with this. From:
http://fedoraproject.org/wiki/Features/GlitchFreeAudio

The PulseAudio sound server has been rewritten to use timer-based audio scheduling instead of the traditional interrupt-driven approach. Timer-based scheduling may expose issues in some Alsa drivers. To turn timer-based scheduling off, replace the line

load-module module-hal-detect

in /etc/pulse/default.pa by

load-module module-hal-detect tsched=0 

Up until Fedora 11 Beta was released (all the way through Fedora 11 Alptha) using tsched=0 to fall back to the interrupt driven approach has successfully resolved sound issues in VMware guests. As of a clean install of Fedora 11 Beta this is no longer the case. It appears that something has changed such that tsched=0 setting either is not being registered or is not working properly.

Comment 5 Lennart Poettering 2009-04-13 21:05:16 UTC

Uh?

Come on! You are complaining that a work-around for a broken sound driver with a closed-source backend doesn't work anymore?

The right fix is to fix VMWare. Please file this bug with VMWare upstream! Thank you.