Bug 496714

Please provide an output of pulseaudio -vvvvv when this happens. (You might need to kill PA first with -k)

PA has no special support for virtualized machines. If this is a bug, then in the kernel or the vm host software that fails to emulate the sound hw properly.

I would be willing to believe something to do with the kernel. I can take a fully updated system and boot it using the kernel shipped on the Fedora 11 Beta DVD and get working sound. Some of the vm's require the tsched=0 workaround (including KVM guest), while others more or less just work, but in all cases I can get working audio.

On a fully updated system none of them work regardless of this or anything else I've come up with.

As a sort-of workaround pulseaudio can also be uninstalled when booting the newest kernel to get working audio, although that breaks the new volume control applet, and the graphical sound config tools that now rely on pulseaudio.

I guess I can try pulling kernels from koji and try to narrow it down to which version caused the break; right now I know original beta kernel works, current rawhide does not.

I am also attaching the output from pulseaudio -vvvvv

After I started pulseaudio I just backspaced on the terminal (usually causes a 'bell' sound) until sound got stuck, which is easily reproducible on the KVM guest I set up, let it run for about 60 seconds, and then killed the daemon

Created attachment 340436 [details]
output from pulseaudio -vvvvv

The kernel driver is borked. This is probably an overflow similar to bug 472339 but for the ens1371 driver:

E: alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 18446744073709550012 bytes (418293516401 ms).

Reassigning to kernel.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

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

Hi...

I'm using Fedora 11, the release version, as a guest OS in Vmware Fusion on MacOS X 10.5.  It's using the ens1371 driver, and sound goes into an infinite loop of stuttering, fixed by killing the pulseaudio daemon.

This bug report looks exactly like what I'm experiencing.Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c: snd_pcm_delay() returned a value that is exceptionally large: -326959556 bytes (-1853512 ms).
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_ens1371'. Please report this issue to the ALSA developers.
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c: snd_pcm_dump():
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c: Hardware PCM card 0 'Ensoniq AudioPCI' device 0 subdevice 0
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c: Its setup is:
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   stream       : PLAYBACK
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   access       : MMAP_INTERLEAVED
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   format       : S16_LE
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   subformat    : STD
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   channels     : 2
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   rate         : 44100
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   exact rate   : 44101 (1445100000/32768)
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   msbits       : 16
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   buffer_size  : 4408
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   period_size  : 1102
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   period_time  : 24988
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   tstamp_mode  : ENABLE
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   period_step  : 1
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   avail_min    : 1102
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   period_event : 0
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   start_threshold  : -1
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   stop_threshold   : 1155530752
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   silence_threshold: 0
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   silence_size : 0
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   boundary     : 1155530752
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   appl_ptr     : 108547
Jun 30 09:15:15 fedora11 pulseaudio[6597]: alsa-util.c:   hw_ptr       : 59508

For what it's worth I'm using Fedora 12 Alpha on VirtualBox/Vista x64 and sound is absolutely flawless. This setup did not work any better for F11 sound than the ones listed above.

I just upgraded to 2.6.30.5-43.fc11.i686.PAE kernel on Fedora 11 this morning and the sound is still misbehaving as usual under VMware Fusion.

Jeff: Are you sure this is the problem of the guest kernel? Would you mind trying another operating system or maybe playing directly via ALSA, w/o pulseaudio? (Just making sure it is "as usual".) What's your host operating system?

Created attachment 360144 [details]
more output of pulseaudio -vvvv

Lubomir: based on bug 473153 comment 3, I believe this is a guest kernel
problem.  Sound has been broken for me since Fedora 10 was released.  It
worked fine in Fedora 8.  (I skipped F9.)

The host is a Mac running OS X 10.6.0 (although sound was also broken
with 10.5.x) running VMware Fusion 2.0.x.

Attached is a log of 'pulseaudio -vvvv' while playing a flac file using Amarok.  I played 1 minute of audio, but it only took 20 seconds to play and it was stuttering the entire time.

I then tested without pulseaudio and it played the same way.
    sudo sh -c "/sbin/modprobe --ignore-install snd-pcm && \
                /sbin/modprobe snd-pcm-oss && \
                /sbin/modprobe snd-seq-device && \
                /sbin/modprobe snd-seq-oss"
    pulseaudio -k
    flac -sdc music.flac | sox -t wav - -t ossdsp /dev/dsp

I will try with another OS tomorrow.

I just installed OpenSolaris 2009.06 under VMware Fusion, and I added the OSS drivers from 4Front Technologies[1] since OpenSolaris doesn't include drivers for the Ensoniq 1371 (apparently for license reasons), and sound works fine on this virtual machine.  I was able to configure gstreamer to use the ens1371 device and play flac files with totem.

[1] http://www.4front-tech.com/

I can get Windows guests working fine as far as sound goes under VMWare Fusion 2.05 and OS X 10.6, but can not get working sound in Fedora 11/12 guests.

I have VirtualBox 3.04 installed on a Windows Desktop and the same Mac laptop I have VMWare Fusion on and sound generally works much better with Fedora 12 Alpha - flawless on the desktop system. I still have some issues on the Mac; sound more or less works. Not sure why one works so much better than the other.

I had OK results with a Fedora 12 Alpha host/guest setup too - more or less working, but I was running into problems with virt-manager and selinux; basically had to run quemu-kvm from a terminal to get sound (think there is a bug for this too) but haven't had much time to play with it.

Overall things have gotten much better, especially with the ones emulating intel sound hardware; the ones using ens1371 (vmware) still seem to be in bad shape.

I have actual ens1371 hardware and the driver has been a source of problems ever since I upgraded to F10, with PulseAudio triggering asserts all over the place. I think the driver bugs have always been there, but the PulseAudio in F9 somehow didn't notice whereas the one in F10 does. (I tried building the PulseAudio version from F11 for F10, but it just made things worse.)

Created attachment 361093 [details]
This fixes sounds at least in VMWare

Jeff, Jason thanks for your input. I managed to reproduce the problem in Fedora 11 hosted Rawhide installation in VMWare player and it am attaching the patch that fixed the problem for me.

Kevin, could you please be more specific about the issues you encountered? Please just add references to open bugs or report them, if they seem to be an issue different from this, otherwise just try the above patch with your hardware. Thanks!

Assigning the bug to Jaroslav, for some reason I thought it's already assigned to him.

Lubomir,

I tried your patch and the sound still does not work for me (it still stutters and plays extremely fast).  Should I try increasing the min_period to 3?  Or 100?

Here's how I built the patched driver:
1. Applied patch to ens1370.c from kernel-PAE-2.6.30.5-43.fc11 source
2. Copied ens1370.c and ens1371.c to /tmp/ens137x
3. Created /tmp/ens137x/Makefile [1]
4. make
5. Backed up /lib/modules/2.6.30.5-43.fc11.i686.PAE/kernel/sound/pci/snd-ens1371.ko
6. Copied new snd-ens1371.ko to path in step 5
7. Reboot

[1] Makefile contents
snd-ens1371-objs := ens1371.o
obj-$(CONFIG_SND_ENS1371) += snd-ens1371.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

(In reply to comment #16)
> I tried your patch and the sound still does not work for me (it still stutters
> and plays extremely fast).

That might be yet another issue (I'll probably be unable to reproduce, since my patch fixed the issue for my Fedora host and guest).

Could you please attach output of pulseaudio -vvvv (similar to one from comment #10) with the patched driver? Thanks!

> Should I try increasing the min_period to 3?  Or
> 100?

That most likely would not help.

Hmm, not convinced. To my knowledge the real ens1371 can deal with single-period hw buffers just fine. If vmware's fake ens1371 card cannot this should be fixed in their code, not the kernel.

The max. playback buffer size of the ens1371 is limited to 64k already, having to use at least 2 periods thus drives the IRQ rate higher than necessary,

This worked like a charm on Fedora 12 Alpha, VMWare Fusion 2.05, OS X 10.6.1. Listening to music with rhythmbox in the vm and it's working like a charm.

I got my hands on a real card that makes use of the snd-ens1371 driver and it worked properly without modifying the kernel.

02:07.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
	Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort+ <MAbort+ >SERR- <PERR- INTx-
	Latency: 32 (3000ns min, 32000ns max)
	Interrupt: pin A routed to IRQ 19
	Region 0: I/O ports at a400 [size=64]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ENS1371
	Kernel modules: snd-ens1371

Created attachment 362122 [details]
'pulseaudio -vvvv' output from rawhide

I just attempted to use Fedora 12 Rawhide under VMware Fusion 2.0.5 and
OS X 10.6.1, similar to Jason's setup in comment 19, however, the audio
is still not working for me.

With today's rawhide, I got
  kernel-PAE-2.6.31-33.fc12.i686
  pulseaudio-0.9.18-1.fc12.i686

Attached is 'pulseaudio -vvvv' output from rhythmbox attempting to play
a flac file.

Created attachment 362123 [details]
'pulseaudio -vvvv' output with periods_min=2 patch

And here is the output of 'pulseaudio -vvvv' from Fedora 11 with 2.6.30.5-43.fc11.i686.PAE with the periods_min=2 patch.

With both this kernel patch and the Fedora 12 Rawhide setup, I see lots of
   D: protocol-native.c: Requesting rewind due to rewrite.
messages in the pulseaudio output.

There are some discussions on this and other audio problem in the VMware Community forums:
  http://communities.vmware.com/message/1350081
  http://communities.vmware.com/message/1318558

I've been doing more testing on Fedora 12 Beta and KDE:
   amarok-2.2.0-2.fc12.i686
   gstreamer-0.10.25-1.fc12.i686
   kernel-PAE-2.6.31.1-56.fc12.i686
   pulseaudio-0.9.19-1.fc12.i686
   totem-2.28.2-1.fc12.i686
   xine-lib-1.1.16.3-4.fc12.i686

Using amarok to play a FLAC file, I found that PulseAudio with the Xine backend works just fine.  (Yay!)

But when I switch to the gstreamer backend, it doesn't do anything.  (It just won't play the flac file.)

And when I tried totem (which also uses gstreamer), 'pulseaudio -vvvv' spit out hundreds of these messages:
   D: protocol-native.c: Requesting rewind due to rewrite.
   D: alsa-sink.c: Wakeup from ALSA!
   I: alsa-sink.c: Underrun!

So there may be a part of gstreamer that's causing these problems.

I think I spoke too soon: I don't believe Amarok was picking up the changes in the KDE Multimedia Preferences as I switched the Device Preferences between PulseAudio and Ensoniq ENS1371 while testing.

I set it to PulseAudio + Xine and rebooted and tested again and Amarok no longer worked: the audio was fast and choppy, and the pulseaudio logs show lots of the usual "alsa woke us up but nothing to write" errors.

I switched the KDE Multimedia Preferences back to Ensoniq ENS1371 + Xine and rebooted once more, and Amarok started working fine again.  (But ENS1371 + gstreamer still did not play anything.)

So, the good news is the raw ens1371 device works fine.  But PulseAudio and gstreamer still seem to have issues.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

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

Sound 'just works' with the latest kernel/pulseaudio packages in VMware Fusion 3.0; I think all three have had fairly recent updates, so I'm not sure which was responsible. For me, at this time, it is now working in VirtualBox, VMware, and KVM - everything I have access to.

[jason@f12vmware ~]$ uname -r
2.6.31.6-145.fc12.x86_64
[jason@f12vmware ~]$ rpm -q kernel pulseaudio
kernel-2.6.31.5-122.fc12.x86_64
kernel-2.6.31.5-127.fc12.x86_64
kernel-2.6.31.6-145.fc12.x86_64
pulseaudio-0.9.21-1.fc12.x86_64

Likewise, I also upgraded to VMware Fusion 3.0 and Fedora 12 and audio is finally working again.

KDE/Phonon still has issues with gstreamer, but that's another bug (bug 539297), and it was probably throwing a monkey wrench into this bug.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.