Bug 479775 - pulseaudio sound "jumps" all the time
Summary: pulseaudio sound "jumps" all the time
Keywords:
Status: CLOSED DUPLICATE of bug 466314
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 10
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-13 00:44 UTC by Daniel
Modified: 2009-02-25 03:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-25 03:16:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
audacious has just core-dumped when playing through pulseaudio, F10 (531.53 KB, text/plain)
2009-02-08 14:57 UTC, Chris Rankin
no flags Details

Description Daniel 2009-01-13 00:44:45 UTC
Description of problem:
Since F10 sound "jumps" every few seconds when using pulseaudio "glitch-free" versions (beginning from 0.9.10-2).

Version-Release number of selected component (if applicable):
every pulseaudio release after 0.9.10-2

Steps to Reproduce:
1. Install some application like e.g. audacious, try to play a song. Every few seconds sound "jumps" ahead.
2. Try to reconfigure player (like e.g. audacious try to increase audio buffer size) or try another player: nothing helps.
3. Take the last updated pulseaudio version from FC9 (0.9.10-2) recompile it for F10: everything is fine!
  
Actual results: sound "jumps"

Expected results: no jumps 


Additional info: I use an "old" Creative SoundBlaster Live! and had never problems with no Fedora version to play (problem free) sound with it. 
Now, I took the last updated pulseaudio version from the FC9 x86_64 srpms, recompiled it in F10 and installed the packages:

# rpm -qa | grep -i pulseaudio | sort
pulseaudio-0.9.10-2.fc10.x86_64
pulseaudio-core-libs-0.9.10-2.fc10.x86_64
pulseaudio-esound-compat-0.9.10-2.fc10.x86_64
pulseaudio-libs-0.9.10-2.fc10.x86_64
pulseaudio-libs-devel-0.9.10-2.fc10.x86_64
pulseaudio-libs-glib2-0.9.10-2.fc10.x86_64
pulseaudio-libs-zeroconf-0.9.10-2.fc10.x86_64
pulseaudio-module-bluetooth-0.9.10-2.fc10.x86_64
pulseaudio-module-gconf-0.9.10-2.fc10.x86_64
pulseaudio-module-jack-0.9.10-2.fc10.x86_64
pulseaudio-module-lirc-0.9.10-2.fc10.x86_64
pulseaudio-module-x11-0.9.10-2.fc10.x86_64
pulseaudio-module-zeroconf-0.9.10-2.fc10.x86_64
pulseaudio-utils-0.9.10-2.fc10.x86_64

Everything is fine now.

Comment 1 Daniel 2009-01-16 11:21:15 UTC
Have the same problem on i386 architecture as well. 
With new pulseaudio (0.9.13-6) sound player jump when playing .ogg or (in rare cases) .mp3. 
Integrating the FC9 pulsaudio (0.9.10-2) however is somewhat tricky and does not always work.
Without pulseaudio (yum erase pulseaudio) most sound applications will not play any sound. Although gnome-sound-properties do yes play a test sound.

Comment 2 Daniel 2009-01-16 12:33:57 UTC
yum erase pulseaudio pulseaudio-esound-compat pulseaudio-libs-devel pulseaudio-libs-glib2 pulseaudio-libs-zeroconf pulseaudio-module-bluetooth pulseaudio-module-gconf pulseaudio-module-jack pulseaudio-module-lirc pulseaudio-module-x11 pulseaudio-module-zeroconf pulseaudio-utils xine-lib-pulseaudio

make the problem disappear. Now sound has no "jumps" at all

Additionally I cleared all stored config/gnome files in ~/.config, ~/.gconf, ~/.gconfd, ... etc. for sound applications and rebooted (cleared /tmp as well)

Even audio in firefox flashplugin works.

BTW, with pulseaudio xine was always crashing after a few seconds. Now it starts normally.

To summerize this: pulseaudio or its system integration seems to be a cause of lots of problems. Firing it ... lets the sun in again! ;-)

Comment 3 Devan Goodwin 2009-01-23 21:51:37 UTC
Experiencing this same problem with X86_64 F10, my sound very frequently cuts for a very quick spurt, extremely disorienting when trying to listen to something.  (usually mp3 in my case)

Also using a Creative SoundBlaster Live Value. 

No problems with past versions of Fedora or PulseAudio.

Comment 4 Chris Rankin 2009-01-26 21:13:42 UTC
Hi,

I have just upgraded from F9 to F10 and have noticed this problem too, with a home-compiled version of libxine. In extreme cases, xine can even core-dump:

(gdb) where
#0  0xb7f0d424 in __kernel_vsyscall ()
#1  0x418e1460 in raise () from /lib/libc.so.6
#2  0x418e2e28 in abort () from /lib/libc.so.6
#3  0x418da40e in __assert_fail () from /lib/libc.so.6
#4  0xb4e512a8 in snd_config_iterator_end ()
   from /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
#5  0x4ff69720 in ?? () from /lib/libasound.so.2
#6  0x4ff20b88 in snd_pcm_delay () from /lib/libasound.so.2
#7  0xb4e59410 in ao_alsa_delay (this_gen=0x9384eb8) at audio_alsa_out.c:662
#8  0xb7ec3a65 in ao_loop (this_gen=0x9395008) at audio_out.c:1093
#9  0x41a6451f in start_thread () from /lib/libpthread.so.0
#10 0x4199a04e in clone () from /lib/libc.so.6

This corresponds to the following code in libxine's ALSA audio output plugin:

File: audio_alsa_out.c

static int ao_alsa_delay (ao_driver_t *this_gen)  {
  snd_pcm_sframes_t delay = 0;
  int err = 0;
  alsa_driver_t *this = (alsa_driver_t *) this_gen;
#ifdef LOG_DEBUG
  struct timeval now;
  printf("audio_alsa_out:delay:ENTERED\n");
#endif
  err = snd_pcm_delay( this->audio_fd, &delay );  << LINE 662

I am currently working around the problem by configuring xine to use the Audigy2 device directly (since the Audigy2 supports hardware mixing).

Comment 5 Chris Rankin 2009-02-08 14:57:43 UTC
Created attachment 331242 [details]
audacious has just core-dumped when playing through pulseaudio, F10

The sound was glitchy through PulseAudio anyway, but audacious gave up and crashed when I tried compiling something.

I have told audacious to use the ALSA hardware device directly instead (like I did with xine!) The Audigy 2's hardware mixing seems to beat PulseAudio hands down.

Comment 6 Lennart Poettering 2009-02-25 03:16:23 UTC
The Audigy drivers are known to be buggy.

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


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