Bug 46296

Summary: Sometimes the PA server needs a restart.
Product: PulseAudio Reporter: Jörg Höhle <Joerg-Cyril.Hoehle>
Component: alsaAssignee: pulseaudio-bugs
Status: RESOLVED MOVED QA Contact: pulseaudio-bugs
Severity: normal    
Priority: medium CC: aeikum, colin, diwic, error, gilboad, kinetik, lennart, spetreolle
Version: unspecified   
Hardware: All   
OS: Linux (All)   
See Also: http://bugs.winehq.org/show_bug.cgi?id=28856
Whiteboard:
i915 platform: i915 features:
Attachments: Lisp FFI declarations, for use with CLISP
pulseaudio -vvvv during crackling

Description Jörg Höhle 2012-02-19 11:52:19 UTC
Hi,

The Wine bugzilla contains several mentions from people managing to restore sound or to get rid of crackling by restarting the PulseAudio server.  The need to restart is an indicator of a bug on the PA or alsa_plugin side.  A user app must not manage to cause harm to a server, much like a kernel panic is undeniably a bug in the kernel, not in the app perhaps feeding bad data.

- http://bugs.winehq.org/show_bug.cgi?id=28856#c17
Vítor Ferreira: "I restarted pulseaudio" running Fedora 16 with pulseaudio 1.1 and alsa stack 1.0.25

- http://bugs.winehq.org/show_bug.cgi?id=28723#c106
Michael Cronenworth: "I have to quit the application and restart PA", Fedora 16 x86_64

I myself have ran into the need to restart PA, using old Ubuntu Intrepid 2008.10 and Lucid 2010.04 however (nothing newer here).  I managed to achieve this by sending a straightforward selection of snd_pcm_* commands from the safe ALSA subset using an interactive Lisp Read Eval Print Loop (REPL).

The server's broken state can be persistent, i.e. you can quit the client app and PA is still in trouble.  My systems are outdated, which is the reason I did not write a bug report earlier, but the above users are running the latest PA and alsa_plugins AFAIK.

Hence I believe this is a long-standing bug.  Alas, I don't have something reproducible.  My sequence of commands is similar to what Wine calls in dlls/winealsa.drv/mmdevdrv.c these days.  During the last months, Wine's ALSA driver was largely simplified.  I don't see anything wrong with it, the only noteworthy issue is that MS' mmdevapi design quasi mandates that we feed data every 10ms instead of writing much larger chunks.

Later I'll attach my Lisp code, already sent to David Henningsson. There's no magic with this Lisp code.  It's just repeating loops of a few snd_pcm_write, followed by printing snd_pcm_avail & delay and some sleep(5ms).

Regards,
	Jörg Höhle
Comment 1 Jörg Höhle 2012-02-20 09:41:08 UTC
Created attachment 57338 [details]
Lisp FFI declarations, for use with CLISP

This is the Lisp file that I've used to perform interactive testing of ALSA behaviour. It contains a mixture of foreign function definitions, sample code and comments about my findings.

What follows are snippets from the file to show how it fits together:

; Initialize once
(load"/path/to/alsa.lisp" :compiling t)
(in-package "ALSA")
(ffi:default-foreign-language :stdc)
(setq *hw-params* (allocate-shallow 'uint8 :count (snd_pcm_hw_params_sizeof)))
(setq *sw-params* (allocate-shallow 'uint8 :count (snd_pcm_sw_params_sizeof)))

(snd_pcm_open "default" 0 (logior snd_pcm_nonblock))
; the pointer is the second value in the special variable named /
(setq *pcm* (second /))
(set-foreign-pointer *pcm* :copy)

; Finalize when you're done
(snd_pcm_close *pcm*)
(setf (validp *pcm*) nil)
(ext:quit) ; to exit CLISP


; set ALSA parameters of your choice
; I typically use 8000x8x1 (because of sineu8)
(multiple-value-call #'list
(snd_pcm_hw_params_any *pcm* *hw-params*)
(snd_pcm_hw_params_set_access *pcm* *hw-params* 3)
(snd_pcm_hw_params_set_format *pcm* *hw-params* SND_PCM_FORMAT_U8)
;(snd_pcm_hw_params_set_format *pcm* *hw-params* SND_PCM_FORMAT_S16_LE)
(snd_pcm_hw_params_set_channels *pcm* *hw-params* 1)
(snd_pcm_hw_params_set_rate_near *pcm* *hw-params* 8000 0)
;(snd_pcm_hw_params_set_rate_near *pcm* *hw-params* 44100 0)
; Wine asks for 10ms and a buffer 4x that period
(snd_pcm_hw_params_set_period_time_near *pcm* *hw-params* 10000 0)
(snd_pcm_hw_params_set_periods_near *pcm* *hw-params* 4 0)
(snd_pcm_hw_params *pcm* *hw-params*))

(multiple-value-bind (err boundary) (snd_pcm_sw_params_get_boundary *sw-params*)
  (multiple-value-call #'list
   boundary
   (snd_pcm_sw_params_set_start_threshold *pcm* *sw-params* 1)
   ;(snd_pcm_sw_params_set_stop_threshold *pcm* *sw-params*  boundary) ; may insert observed buffer size here
   ;(snd_pcm_sw_params_set_avail_min *pcm* *sw-params* 0)
   (snd_pcm_sw_params *pcm* *sw-params*)))


; Repeat any number of times:
;(snd_pcm_recover *pcm* -32 t)
(snd_pcm_prepare *pcm*)

(locally (declare (compile) (special *pcm*))
(time(loop repeat 50
      for e = (snd_pcm_writei_u8 *pcm* (sineu8 *pcm* 440 8000 .1))
      do (print e)
      (print (multiple-value-call #'list (enum-from-value 'snd_pcm_state (snd_pcm_state *pcm*))
                (snd_pcm_avail_update *pcm*) (snd_pcm_delay *pcm*)) )
      (print (multiple-value-call #'list (enum-from-value 'snd_pcm_state (snd_pcm_state *pcm*))
                (snd_pcm_avail_update *pcm*) (snd_pcm_delay *pcm*)) )
      until (minusp e)))
(loop repeat 100
      for v = (multiple-value-call #'list (enum-from-value 'snd_pcm_state (snd_pcm_state *pcm*))
                (snd_pcm_avail_update *pcm*) (snd_pcm_delay *pcm*))
      do (print v) (sleep .005s0)
      until (minusp (second v)))
)

You can vary the number of iterations and sleep delays (in seconds).  It's essential to repeat the loop a few times within a session to investigate underrun recovery.
Comment 2 Jörg Höhle 2012-02-21 12:36:39 UTC
It seems that Chris Robinson of OpenAL fame too experiences the need to restart the PA server here and then:
http://opensource.creative.com/pipermail/openal-devel/2012-February/005861.html
> However, lately I've noticed that I end up getting a lot of breakup in 
> playback when the PA server has been running for a while.
and
> there's nothing OpenAL Soft can do for that (requires killing and restarting 
> the pulse server to fix).
Comment 3 Colin Guthrie 2012-03-13 17:21:31 UTC
Hi there,

Some things to try when crackling occurs.

 1. "pasuspender echo" This should suspend the audio monetarily. This makes PA close and reopen the card.
 2. export PULSE_NO_SIMD=1: Put that in your ~/.bashrc or similar file such that it will be seen by the pulsaudio server when it starts. This disabled SIMD optimisations incase they are at fault.
 3. In multi-channel setups, check that all channels have the same volume (this was an old SIMD related issue.. just want to double check it's not still there.
 4. Disable timer based scheduling: (pass tsched=0 to udev-detect in default.pa). Some sound drivers are pretty buggy in relation to the default timer based scheduling.

This page hasn't been updated for a while but it might contain some info: http://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/BrokenDrivers
Comment 4 Michael Hampton 2012-03-19 03:27:24 UTC
Created attachment 58670 [details]
pulseaudio -vvvv during crackling

I'm one of the people experiencing this issue: Intermittently audio will start crackling, for all streams. It usually will stop and return to normal within a minute, though quitting the Wine app leaves any other streams (in my case, amarok) also crackling.

My system is Fedora 16 x86_64, with ALSA 1.0.25, PulseAudio 1.1 and Wine 1.4. I see this occur when playing World of Warcraft.

I tried the suggestions given the last time I experienced the crackling. pasuspender echo had no effect, nor did PULSE_NO_SIMD=1. However, tsched=0 changed the crackling from intermittent to constant.

The attached log shows PulseAudio's output when starting WoW with tsched=0 set.

In Wine's output, when the crackling starts, I see the following message repeated twice:

ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred

I am not sure if this is a PulseAudio problem or a problem with the ALSA PulseAudio plugin. Please tell me if it's the latter. :)
Comment 5 haskjold+bugs 2012-03-22 12:56:57 UTC
Hi

I'm experiencing the same problems as Michael, with sound stopping altogether or starting to crackle in applications run with wine (World of Warcraft, winecfg, Starcraft 2 as examples).

The distorted sound has happened on:
Ubuntu 11.10 with wine 1.3.30+, alsa 1.0.24 and pulseaudio 1.0
Ubuntu 12.04 with wine 1.4, alsa 1.0.25 and pulseaudio 1.1

The distortion happens with both a Soundblaster Audigy and a Intel 82801I (ICH9
Family) HD Audio Controller.

The messages going to the console when getting distorted sound:
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
...

"pulseaudio -k" will make sound work for a while in wine
again without distortion, but the distortion soon returns.
Comment 6 steubens 2012-10-12 12:15:13 UTC
please, while the cracking is occurring (and while playing, if possible) run "pasuspender true" and see if the cracking stops, even momentarily
Comment 7 GitLab Migration User 2018-07-30 10:15:48 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/306.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.