[opensuse] Sound dropouts with Pulseaudio
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Dec 2013, in Message-id: <52B480E3.5020108@barrowhillfarm.org.uk> I complained about intermittent sound dropouts on my system. At the time, I blamed Pulseaudio, but I may have been wrong ... I started by completely removing PA from my system (not just disabling it), but though the problem improved, it didn't go away completely. That seemed to exonerate PA, even if having it installed aggravated the underlying problem. So I reinstalled PA. I listen to my music through Music Player Daemon (MPD), so the next thing was to try another player. MPlayer behaved flawlessly, even through PA, so that pointed the finger at MPD. I monitor my computer with gkrellm, and I noticed that there was very little disk activity during playback with MPlayer, whereas MPD reads data from the disk in 262k chunks. Maybe a buffer somewhere is being emptied faster than it fills when using MPD, compared to MPlayer. MPD's configuration file has an entry #buffer_before_play "10%" so I uncommented this line, and increased the value to 20%. buffer_before_play "20%" So far, so good, music is playing perfectly. I realise that other people who've experienced similar problems with sound may not be using MPD, but this may help them find a similar solution in their setup. Bob - -- Bob Williams System: Linux 3.11.6-4-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.12.1 Uptime: 18:00pm up 3:13, 3 users, load average: 0.38, 0.39, 0.48 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLqqKkACgkQ0Sr7eZJrmU6slwCbBnI8H7TtftgtGdr7TDWhUZQW WBEAn3HfCva0HhFFGKmkpmDdcGcLio+B =smZc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b30cc69aec1406a21388113ff50b7f2e.jpg?s=120&d=mm&r=g)
Bob Williams <linux@barrowhillfarm.org.uk> writes:
I listen to my music through Music Player Daemon (MPD), so the next thing was to try another player. MPlayer behaved flawlessly, even through PA, so that pointed the finger at MPD. I monitor my computer with gkrellm, and I noticed that there was very little disk activity during playback with MPlayer, whereas MPD reads data from the disk in 262k chunks.
I am a long time user of MPD and have never had any problems. Do you see any MPD or ALSA errors in /var/log/messages?
Maybe a buffer somewhere is being emptied faster than it fills when using MPD, compared to MPlayer.
Your can try increasing the buffer_before_play size in /etc/mpd.conf. Charles -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power)
![](https://seccdn.libravatar.org/avatar/b4047644c59f2d63b88e9464c02743fd.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/30/2014 12:04 PM, Charles Philip Chan wrote:
Bob Williams <linux@barrowhillfarm.org.uk> writes:
I listen to my music through Music Player Daemon (MPD), so the next thing was to try another player. MPlayer behaved flawlessly, even through PA, so that pointed the finger at MPD. I monitor my computer with gkrellm, and I noticed that there was very little disk activity during playback with MPlayer, whereas MPD reads data from the disk in 262k chunks.
I am a long time user of MPD and have never had any problems. Do you see any MPD or ALSA errors in /var/log/messages?
Maybe a buffer somewhere is being emptied faster than it fills when using MPD, compared to MPlayer.
Your can try increasing the buffer_before_play size in /etc/mpd.conf.
Charles
Its still a pretty dumb player that you have to be making these tweaks on. Its bound to get in trouble in any I/O intensive environment. Most of these things dynamically adjust their cache size and try to keep cache full. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlLquiMACgkQv7M3G5+2DLJqVgCfcC6P3mlFoA9Ew1DzvgFYHbML txcAniBdCBkKaXFWcwCcCdOio7hON8Yz =PFv+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b30cc69aec1406a21388113ff50b7f2e.jpg?s=120&d=mm&r=g)
John Andersen <jsamyth@gmail.com> writes:
Its still a pretty dumb player that you have to be making these tweaks on. Its bound to get in trouble in any I/O intensive environment.
I only suggest it- I never have to make any changes myself. I have no drop out problems even when my machine is under heavy load. Charles -- "...and scantily clad females, of course. Who cares if it's below zero outside" (By Linus Torvalds)
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/01/14 20:46, John Andersen wrote:
Its still a pretty dumb player that you have to be making these tweaks on. Its bound to get in trouble in any I/O intensive environment.
I'm not trying to defend or advocate mpd. If you look back at the original thread that I quoted (it's in the archives) you will see that several other people have experienced similar problems. I was reporting my observations in case my findings were pertinent to them. Bob - -- Bob Williams System: Linux 3.11.6-4-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.12.1 Uptime: 18:00pm up 3:13, 3 users, load average: 0.38, 0.39, 0.48 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEARECAAYFAlLq5AgACgkQ0Sr7eZJrmU4rhwCfQ/IGYU35loNldWaghpwdG7fq 4e0AlRa616m1AQ4sRAQoEnkiBud3nu4= =k0vX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b30cc69aec1406a21388113ff50b7f2e.jpg?s=120&d=mm&r=g)
Bob Williams <linux@barrowhillfarm.org.uk> writes: Hi Bob:
I'm not trying to defend or advocate mpd. If you look back at the original thread that I quoted (it's in the archives) you will see that several other people have experienced similar problems. I was reporting my observations in case my findings were pertinent to them.
Strange, I have never encountered this (the "buffer_before_play" directive is commented out in mpd.conf and sound is outputting directly to my M-Audio Revolution 7.1) . For example, for a stress test, I am currently listening to music with mpd, while compiling the git version of ffmpeg, watching TV on my Hauppauge 2250 with mplayer and writing this in Emacs with no sound dropping. This is all on a lowly core2 duo machine. I have never had the sound dropping even on my old P4 Prescott machine. Do you see anything strange in /var/log/messages? Charles -- "Whip me. Beat me. Make me maintain AIX." (By Stephan Zielinski)
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/01/14 00:16, Charles Philip Chan wrote:
Bob Williams <linux@barrowhillfarm.org.uk> writes:
Hi Bob:
I'm not trying to defend or advocate mpd. If you look back at the original thread that I quoted (it's in the archives) you will see that several other people have experienced similar problems. I was reporting my observations in case my findings were pertinent to them.
Strange, I have never encountered this (the "buffer_before_play" directive is commented out in mpd.conf and sound is outputting directly to my M-Audio Revolution 7.1) . For example, for a stress test, I am currently listening to music with mpd, while compiling the git version of ffmpeg, watching TV on my Hauppauge 2250 with mplayer and writing this in Emacs with no sound dropping. This is all on a lowly core2 duo machine. I have never had the sound dropping even on my old P4 Prescott machine. Do you see anything strange in /var/log/messages?
Charles
:~> sudo grep mpd /var/log/messages 2014-01-31T08:23:16.680825+00:00 barrowhillfarm sudo: bob : TTY=pts/1 ; PWD=/home/bob ; USER=root ; COMMAND=/usr/bin/grep mpd /var/log/messages and :~> sudo grep pulseaudio /var/log/messages root's password: 2014-01-30T14:34:22.253070+00:00 barrowhillfarm sudo: bob : TTY=pts/3 ; PWD=/home/bob ; USER=root ; COMMAND=/usr/bin/systemctl pulseaudio restart 2014-01-30T14:34:44.048740+00:00 barrowhillfarm sudo: bob : TTY=pts/3 ; PWD=/home/bob ; USER=root ; COMMAND=/usr/bin/systemctl restart pulseaudio 2014-01-30T14:35:38.491227+00:00 barrowhillfarm rtkit-daemon[29369]: Successfully made thread 29368 of process 29368 (/usr/bin/pulseaudio) owned by 'bob' high priority at nice level -11. 2014-01-30T14:45:13.163845+00:00 barrowhillfarm pulseaudio[29368]: [pulseaudio] sink.c: Default and alternate sample rates are the same. 2014-01-30T14:45:13.187672+00:00 barrowhillfarm rtkit-daemon[29369]: Successfully made thread 30330 of process 29368 (/usr/bin/pulseaudio) owned by 'bob' RT at priority 5. 2014-01-30T14:47:53.023065+00:00 barrowhillfarm rtkit-daemon[2918]: Successfully made thread 2917 of process 2917 (/usr/bin/pulseaudio) owned by 'bob' high priority at nice level -11. 2014-01-30T14:47:53.964500+00:00 barrowhillfarm rtkit-daemon[2918]: Successfully made thread 2970 of process 2917 (/usr/bin/pulseaudio) owned by 'bob' RT at priority 5. 2014-01-30T14:47:54.263648+00:00 barrowhillfarm pulseaudio[2917]: [pulseaudio] sink.c: Default and alternate sample rates are the same. 2014-01-30T14:47:54.267378+00:00 barrowhillfarm rtkit-daemon[2918]: Successfully made thread 2975 of process 2917 (/usr/bin/pulseaudio) owned by 'bob' RT at priority 5. 2014-01-30T14:47:57.243526+00:00 barrowhillfarm rtkit-daemon[2918]: Successfully made thread 3029 of process 3029 (/usr/bin/pulseaudio) owned by 'bob' high priority at nice level -11. 2014-01-30T14:47:57.244212+00:00 barrowhillfarm pulseaudio[3029]: [pulseaudio] pid.c: Daemon already running. 2014-01-31T09:30:07.453382+00:00 barrowhillfarm sudo: bob : TTY=pts/1 ; PWD=/home/bob ; USER=root ; COMMAND=/usr/bin/grep pulseaudio /var/log/messages There is nothing helpful in the mpd.log file, either Should I be looking for something else? Bob - -- Bob Williams System: Linux 3.11.6-4-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.12.1 Uptime: 06:00am up 15:13, 3 users, load average: 0.24, 0.19, 0.15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLrdAIACgkQ0Sr7eZJrmU665QCfdNKl6geWpCJ9zEXH3hf9l3Pa p08An1yPEE4HV2fX46/dx2KvsPTwKjb6 =u1OS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b30cc69aec1406a21388113ff50b7f2e.jpg?s=120&d=mm&r=g)
Bob Williams <linux@barrowhillfarm.org.uk> writes: Hi Bob:
There is nothing helpful in the mpd.log file, either Should I be looking for something else?
Hum, what is mpd's cpu usage when playing music. Also, uncomment the "log_level" line in /etc/mpd.conf change it to verbose, restart mpd, play some music and post the log. Charles -- A Linux machine! because a 486 is a terrible thing to waste! (By jjs@wintermute.ucr.edu, Joe Sloan)
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Charles, On 31/01/14 19:34, Charles Philip Chan wrote:
Bob Williams <linux@barrowhillfarm.org.uk> writes:
Hi Bob:
There is nothing helpful in the mpd.log file, either Should I be looking for something else?
Hum, what is mpd's cpu usage when playing music. Also, uncomment the "log_level" line in /etc/mpd.conf change it to verbose, restart mpd, play some music and post the log.
Charles
With buffer_before_play back at 10% (you'll remember the problem was solved by increasing this value), the sound dropouts returned and the verbose log shows several lines like this: Feb 01 10:05 : client: [0] process command "status" Feb 01 10:05 : client: [0] command returned 0 Feb 01 10:05 : client: [0] process command "idle" Feb 01 10:05 : client: [0] command returned 1 Feb 01 10:05 : client: [0] process command "status" Feb 01 10:05 : alsa: Underrun on ALSA device "hw:0,0" Feb 01 10:05 : client: [0] command returned 0 Feb 01 10:05 : client: [0] process command "idle" Feb 01 10:05 : client: [0] command returned 1 Feb 01 10:05 : client: [0] process command "status" Feb 01 10:05 : client: [0] command returned 0 I then commented out the alsa audio_output stanza, leaving just the pulse audio_output stanza and buffer_before_play = 10%. Restarted mpd, and ran a cpu intensive perl script that does a lot of reading from the same partition that stores all the music files. Playback went well, until gmpc lost its connection to the mpd server (not really the same problem as before). Feb 01 11:21 : client: [3] process command "status" Feb 01 11:21 : client: [3] command returned 0 Feb 01 11:21 : client: [4] opened from [::1]:52981 Feb 01 11:21 : state_file: Saving state file /home/bob/.mpd/state Feb 01 11:21 : client: [5] opened from [::1]:52982 Feb 01 11:21 : client: [6] opened from [::1]:52983 Feb 01 11:21 : client: [5] expired Feb 01 11:21 : client: [5] closed Feb 01 11:21 : client: [4] expired Feb 01 11:21 : client: [4] closed Feb 01 11:21 : client: [3] expired Feb 01 11:21 : client: [3] closed Feb 01 11:21 : client: [6] process command "commands" Feb 01 11:21 : client: [6] command returned 0 Feb 01 11:21 : client: [6] process command "notcommands" Feb 01 11:21 : client: [6] command returned 0 Feb 01 11:21 : client: [6] process command "tagtypes" Feb 01 11:21 : client: [6] command returned 0 Feb 01 11:21 : client: [6] process command "outputs" Feb 01 11:21 : client: [6] command returned 0 Feb 01 11:21 : client: [6] process command "status" Feb 01 11:21 : client: [6] command returned 0 Feb 01 11:21 : client: [6] process command "idle" Feb 01 11:21 : client: [6] command returned 1 All this is very interesting, and definitely points to my mpd configuration being the problem. I shall continue to play with it. Thanks for your suggestions. Bob - -- Bob Williams System: Linux 3.11.6-4-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.12.1 Uptime: 06:00am up 1 day 15:13, 3 users, load average: 0.22, 0.21, 0.27 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLs2/wACgkQ0Sr7eZJrmU5KMACfeXw7pq5uToMiT4mZZFhlNu2Z KlgAn2cwPnPPsGdGVmZyN3aEY5jTJc7z =VwY7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b30cc69aec1406a21388113ff50b7f2e.jpg?s=120&d=mm&r=g)
Bob Williams <linux@barrowhillfarm.org.uk> writes: Hi Bob:
Feb 01 10:05 : alsa: Underrun on ALSA device "hw:0,0"
I turned on verbose logging and I don't see any underrun in my log. My ALSA output stanza is very simple: ,---- | audio_output { | type "alsa" | name "My ALSA Device" | device "default" # optional | format "44100:16:2" # optional | # mixer_type "hardware" # optional | # mixer_device "default" # optional | # mixer_control "PCM" # optional | # mixer_index "0" # optional | } `---- You can try playing with the "period_time" directive, according to the mpd.conf manpage: ,---- | period_time <time in microseconds> This sets the time between hardware | sample transfers in microseconds. Increasing this can | reduce CPU usage while lowering it can reduce underrun | errors on band- width-limited devices. Some users have | reported good results with this set to 50000, but not all | devices support values this high. Most users do not need | to change this. The default is 256000000 / | sample_rate(kHz), or 5804 microseconds for CD-quality | audio. `----
Playback went well, until gmpc lost its connection to the mpd server (not really the same problem as before).
There should be a timeout option in your frontend- increase it. Charles -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/02/14 04:37, Charles Philip Chan wrote:
Bob Williams <linux@barrowhillfarm.org.uk> writes:
Hi Bob:
Feb 01 10:05 : alsa: Underrun on ALSA device "hw:0,0"
I turned on verbose logging and I don't see any underrun in my log. My ALSA output stanza is very simple:
,---- | audio_output { | type "alsa" | name "My ALSA Device" | device "default" # optional | format "44100:16:2" # optional | # mixer_type "hardware" # optional | # mixer_device "default" # optional | # mixer_control "PCM" # optional | # mixer_index "0" # optional | } `----
You can try playing with the "period_time" directive, according to the mpd.conf manpage:
period_time is an optional alsa output parameter. I have disabled alsa output, as I want to direct my mpd output through pulseaudio. Having an alsa output stanza enabled sends the mpd output direct to alsa, bypassing the pulseaudio server.
Playback went well, until gmpc lost its connection to the mpd server (not really the same problem as before).
There should be a timeout option in your frontend- increase it.
Yes, good point. Increasing the buffer_before_play parameter still seems to be the best way to stop the underruns. Music playback is good here, since doing that. Bob - -- Bob Williams System: Linux 3.11.6-4-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.12.1 Uptime: 12:00pm up 3 days 21:13, 4 users, load average: 0.20, 0.42, 0.58 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLvr5MACgkQ0Sr7eZJrmU7uzwCfeb8FjFsrAoBUBPtg5gUFPUzC p7IAoIcBUcRNNTkrFYDqWAgzyG9fqw9W =jceT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/01/14 20:04, Charles Philip Chan wrote:
Your can try increasing the buffer_before_play size in /etc/mpd.conf.
which is what I did, if you re-read my original post. - -- Bob Williams System: Linux 3.11.6-4-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.12.1 Uptime: 18:00pm up 3:13, 3 users, load average: 0.38, 0.39, 0.48 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLq40oACgkQ0Sr7eZJrmU6ACgCfRfpQesfVDXmn/phfam97zQkO VDMAmwY5A0sXBO1hRKtYUuN+7QkVznqM =Uwm/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Bob Williams
-
Charles Philip Chan
-
John Andersen