Bug 494747 - tsched=0 does not fix sound in vmware server 2.0 fedora guest
tsched=0 does not fix sound in vmware server 2.0 fedora guest
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-07 19:45 EDT by Jason
Modified: 2009-04-13 17:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-13 17:05:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jason 2009-04-07 19:45:57 EDT
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 15:56:25 EDT
Please explain what you mean by 'does not work'.
Comment 2 Jason 2009-04-10 16:17:55 EDT
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 11:56:40 EDT
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 15:31:18 EDT
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 17:05:16 EDT
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.

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