I am having a similar problem with Pulseaudio 6.0. Pulseaudio tends to either not play at all, or lock up after a few minutes of playback. Also using Arch Linux. Have tried both user mode (running as root) as well as system mode, as I have the Pi set up headless.

The following is the error printed by Pulseaudio whenever it hangs (after about a minute or two of playback, usually)

E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

I too am having terrible issues with the bcm2835 and pulse 6.
If I start up pulseaudio and run paplay locally (on the pi), it starts immediately playing with the audio all garbled. Parts of the PCM sound like they are being played out of order. The longer the audio plays the worse it gets until the audio is almost pure noise.
Killing (CTRL+C) and running paplay subsequent times causes a repeatable pattern of garbling the audio or pure silence, till on the 8th run it plays the audio perfect. Play it again and the cycle restarts.
The pattern is garbled, silent, garbled, garbled, silent, garbled, silent, perfect.
If I use a USB headset paplay works every time.
I have had it where I have audio playing over the USB headset perfect, and then I unplug the usb dongle and audio plays correctly out of the analog port of the pi. Stop and restart audio and it will be garbled.

My setup: pulseaudio+mpd+ncmpcpp.

My test setup is to start a song and play/pause repeatedly. After a maximum 3 times of play/pause pulseaudio will hang and has to be restarted.
This only happens on my Raspberry B+ with the bcm2835 chip, both with Debian and Arch based distributions. I have no problems with exactly the same setup on my desktop PC with an Intel sound chip. The problem did not exist with kernel 3.6 (but I don't want to use an ancient distribution).

None of the workarounds to be found on the web (tsched=0, disabling module-suspend-on-idle, ...) has worked. I'll finally give up on this issue because I didn't find a solution for more than a year now. Either I'll buy myself a Raspberry 2 or I'll use mpd with the ALSA backend, because that works great.

@maxnet has this issue been resolved? If yes, then please close this issue.

I don't think so. It doesn't work with Raspberry 3 either (which is no wonder because it uses the same chip/driver: snd_bcm2835).

I have this problem on my Raspberry 3 running ubuntu 16.04. As a workaround I will put a 5 second timeout delay in my program, but that messes up the naturalness of the output (It is a speech synthesizer)

Same issue with my pi3 and ubuntu mate 16.04 and mpd sounds fantastic unless I change volume (which causes stuttering or sound loss) also looses sound randomly among other issues.really frustrating.

Same issue at Rpi B (not 2 or 3) with latest kernel (684be4bc8cc343f60fdc3240c6d55d41d0a5b56c)

Can confirm that issue with an rpi3 running Linux raspberrypi 4.9.27-v7+ #997 SMP Tue May 9 19:58:37 BST 2017 armv7l GNU/Linux on raspbian.. Pulseaudio usually stops playing between tracks that I feed to it from mpd (from another host via network). When trying to play 24bit flac audio via mpd to pulse it only plays 2 seconds and freezes..

Confirming issue on rpi3 running 4.9.30-v7+. Filling mpds playlist and starting playback will usually work until the playlist completes, but manually changing tracks, stopping and restarting, will stop the audio output from working, until I restart mpd.

audio_output {
        type            "alsa"
        name            "ALSA Output"
#       device          "hw:0,0"        # optional
        mixer_type      "software"      # optional
#       mixer_device    "default"       # optional
#       mixer_control   "PCM"           # optional
#       mixer_index     "0"             # optional
#       auto_resample   "no"
#       auto_channels   "no"
#       auto_format     "no"
}

Having the same problematic behavior as described by @flittermice :disappointed:
System is RPi2 running a fresh install of Raspbian Stretch (9.1) with pulseaudio v10.0-1+deb9u1, kernel 4.9.59+
Been reading related articles/tutorials/threads, but MPD playback hangs as described above, until I kill-and-restart pulseaudio.

Has anyone found a solution to this yet? :crossed_fingers: :smile:

Found something interesting (maybe):
When pulseaudio hangs (as described above), issuing a "paplay" command twice (!) resumes audio playback:
$ paplay /usr/share/sounds/alsa/Front_Center.wav

• The 1st time, the paplay command times out (or can be interrupted by Ctrl+C)
• The 2nd time the paplay command works, and now sound from MPD is resumed.

Works for a random amount of time, then it's back to @flittermice's behavior :sob:

I debugged further into this issue, and found that Pulseaudio's use of an esoteric ALSA feature called "rewinding" is causing this problem.
Unfortunately, there is no configuration option to stop PA from using that feature.
This branch disables it permanently in source code: https://github.com/strfry/pulseaudio/tree/no_rewind
If you can build and install it on your system, please check if that fixes your problem.

I debugged further into this issue, and found that Pulseaudio's use of an esoteric ALSA feature
called "rewinding" is causing this problem.
Unfortunately, there is no configuration option to stop PA from using that feature.

But can Pulse function properly if you take away that feature?

Keep in mind that part of the functionality it offers as sound server is mixing sound that can originate from multiple applications together.
And I can imagine that if you want to be able to let new applications add sounds to the mix instantly, you do need a way to discard part of existing buffer.
Otherwise you can only add new sound at end of buffer, and will have lag, which application may not expect. And which may be a problem for some purposes (e.g. video with sound)

@maxnet A proper fix (mine isn't) would fix the latency at a rather low value, which eliminates the need for rewinding, at the cost of a slightly higher CPU load / power consumption.
It works fine for my low-latency application, for playing music with MPD, it might be a bit annoying not to have rewind (without patching PA to only do low-latency buffers).

Always having low latency, would imply using tiny buffers.
Which doesn’t sound ideal to me either.

Would argue that a proper fix would be in the kernel module...

@strfry: relation to ALSA rewinding sounds reasonable. When pulseaudio gets "unhappy", it usually ends in this line:

D: [alsa-sink-bcm2835 ALSA] source.c: Processing rewind...

However, I somewhat agree with @maxnet, and there's probably a reason for ALSA doing this in the first place... :wink:

Is this only non-functional on the Raspberry Pi or a general issue of pulseaudio+ALSA?
Being still an issue for over 3 years now, shall we report this to pulseaudio/ALSA devs instead of here?

@pjotrek-b It is non-functional only with Raspberry PI built-in sound 'card'. We use pulseaudio as network sound server successfully with USB sound card for number of months without issues.

I can confirm @jekhor's statement.
The very same configuration works perfectly with my USB Sound card (snd_usb_audio) on the Raspberry Pi.

As the log file says: "E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.". Does anyone know how to do this?

@jekhor: Thanks for clearing this up! :smile:

What's now puzzling is that, I always thought it's like this:
application > pulseaudio > ALSA > driver > hardware

If so, how can the same applications that have this issue, work flawlessly when using ALSA directly?
application > ALSA > driver > hardware

Now if this issue is specific to RPi's built-in sound card/chip, how come these problems don't appear with alsa-only use, too? :confused:

@strfry: I've found a quite detailed article about "Rewinding" in pulseaudio's documentation.

I've read parts of it and it doesn't seem that "esoteric" to me now anymore. Since you've looked at its code: Any ideas what could cause it to make pulseaudio "get stuck"?
As I've mentioned above, executing "paplay" twice seems to give it a "nudge" to get back to working again... :smile:

@pjotrek-b Sure it makes sense given the design goals of Pulseaudio. It is "esoteric" in the sense that 99% of normal ALSA applications will never use rewind, and thus trigger a less tested path in the ALSA driver. Unfortunately, Pulseaudio lacks on option to disable use of this potentially buggy feature (like other, e.g. timer-based scheduling).
I haven't debugged the exact details, but basically Pulseaudio gets stuck in an endless loop, because ALSA fails to correctly report when it is time to write audio data to the device again.
Despite possibilities to workaround this on Pulseaudio's side, this is a bug in the ALSA driver.
My suspicion is that issuing new streams will generate the events that Pulseaudio is waiting for when it gets stuck.

@flittermice I guess in this case, the responsible ALSA developer is someone of the Raspberry Pi kernel developers who wrote the snd_bcm2835 driver, so this repository would be the right place to report this.

A simple code example that demonstrates a clearly wrong behaviour of ALSA when using rewind would probably be helpful to the kernel developers when taking a closer look at this bug.

@pjotrek-b Sure it makes sense given the design goals of Pulseaudio. It is "esoteric" in the sense that 99% of normal ALSA applications will never use rewind, and thus trigger a less tested path in the ALSA driver. Unfortunately, Pulseaudio lacks on option to disable use of this potentially buggy feature (like other, e.g. timer-based scheduling).
I haven't debugged the exact details, but basically Pulseaudio gets stuck in an endless loop, because ALSA fails to correctly report when it is time to write audio data to the device again.
Despite possibilities to workaround this on Pulseaudio's side, this is a bug in the ALSA driver.
My suspicion is that issuing new streams will generate the events that Pulseaudio is waiting for when it gets stuck.

@flittermice I guess in this case, the responsible ALSA developer is someone of the Raspberry Pi kernel developers who wrote the snd_bcm2835 driver, so this repository would be the right place to report this.

A simple code example that demonstrates a clearly wrong behaviour of ALSA when using rewind would probably be helpful to the kernel developers when taking a closer look at this bug.

If so, how can the same applications that have this issue, work flawlessly when using ALSA directly?

Applications using ALSA directly typically have no need to use rewind.
They know exactly what sound they want to have playing in the coming seconds, and send it to the audio device.

It is used in situations in which there is a change of plans.
If Pulse already has sent the audio for the next 2 seconds to the device, and suddenly a different Pulse client connects and wants to play sound as well -without having to wait for those 2 seconds to be over first- it has to tell the sound device to discard the previous buffer, and replace it with new data which has the extra sound mixed in.

Sure, if you use tiny buffers that hold milliseconds instead of seconds of audio, one could do without rewinds.
However I don't think that is preferred.
Under Linux there are no guarantees about the amount of CPU time any application gets, nor that it gets divided evenly, it is not a real-time operating system.
If another application is using a lot, and Pulse doesn't get sufficient in time to keep that tiny buffer filled at all times, it will underrun, and your sound will go stuttering.

As I've mentioned above, executing "paplay" twice seems to give it a "nudge" to get back to working again... :smile:

Pulse Audio also closes the connection to the sound device 5 seconds after the last client using it disconnects, if no other clients connect during that time.
And reopens it the next time a client wants to use it.
So if there is sufficient time between your commands, that could also be the reason it is working again.

@strfry and @maxnet:
Thank you very much for these detailed answers!

Does anyone know if this is still an issue in the latest Raspbian (with kernel 4.14.y)?

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

I'd check, but I currently don't have the time to test it... :disappointed:
Just in case: May I reopen it if I test it after 30 days and it's still an issue?

Though I'm pretty sure there have been no improvements, I cannot contribute much for this particular bug. I bought an external USB sound card with a PCM2704 chipset and am now happy with the snd_usb_audio driver.
Using the HDMI output of the raspi would have been a nice option, but my raspi would even refuse to boot with the HDMI cable plugged into the AV receiver... but that's another story.

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.

Can confirm that this happens to my Rasp Pi 3
I'm running ArchARM with kernel version 4.14.69

Can confirm this is still happening on my RPI3:

Linux 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux

Trying to use mpd with pulseaudio I get:

Nov 05 09:25:17 noise systemd[1]: Started Music Player Daemon.
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

Any chance we can reopen this issue?

Can confirm that this happens to my Rasp Pi 3
I'm running ArchARM with kernel version 4.14.69
This was because of wrong permission, I have it worked.

@l4rzy: you're making us curious. Which permissions?

@flittermice: Oops, I misunderstood the situation since I commented on this for months. It was not about permissions.
I tried to set up my Raspberry Pi 3 for a local network Pulse audio server, it worked seamlessly but after a while not playing anything, Pulse audio server automatically shut down. Later I install mpd to play music from SoundCloud, which always open a connection to Pulse and keeps it running. Not a bad workaround I think.

@l4rzy: Working around is the way to go :-)

BTW: Did you ever try not to load "module-suspend-on-idle" in default.pa?

load-module module-suspend-on-idle

@flittermice i tried. Doesn't help.

Pulseaudio is still not working with snd_bcm2835. Can you reopen this issue, please?

I can confirm it not working for me either. I've been testing different code and compile options and I've been unable to get it to work. I'm on ArchLinux ARM and all the newest software. I'm happy to help debug if possible.

For me, near as I can tell, the issue comes from the buffer size reported by the bcm2835_alsa module. The audio buffer reported to pulse is 8816 bits, or just enough for approximately 1.56 ms of audio from a network stream. I'm not enough of a hardware geek to find the specs but something seems off here. According to ALSA itself (i.e. not the pulse module) the buffer size is a much more logical 131072 bits. If I were to guess, pulse thinks it can't keep the buffer full for the card and tries to rewind because it is being told there's a software limit of 8816 bits... but maybe I'm way off base here.

Just had the same issue (it's really anoying), @JamesH65 could you reopen it to further track it?

Hmmm... I cannot reproduce this with Raspberry Pi 3 B v1.2 and latest 4.19.34 kernel (updated by rpi-update to https://github.com/Hexxeh/rpi-firmware/commit/99c274691c07480762dcda91a0ebfe3c4f519307). I have no idea why, driver seems not changed from 2016. Maybe some VC firmware changes?

Hi, on Raspberry Pi 4 B v1.1, kernel 5.3.0-1014 has the same problem with sound fading with pulseaudio v13.0. Sound is lost if a stereo output is selected in pavucontrol. Is there any solution?

@acegallagher:

The audio buffer reported to pulse is 8816 bits, or just enough for approximately 1.56 ms of audio from a network stream.

I think this is because PulseAudio is detecting the sinks as Mono by default (because of this issue), and the default buffer size for these is lower.
Try updating PA's default profile config file so that stereo sinks are created instead, as this will make PA create sinks with device.buffering.buffer_size = "17632", which seems better!

@olevenets2

Hi, on Raspberry Pi 4 B v1.1, kernel 5.3.0-1014 has the same problem with sound fading with pulseaudio v13.0. Sound is lost if a stereo output is selected in pavucontrol. Is there any solution?

Make sure to update PA's default profile config file so that stereo output actually works using PA on the RPI 4, and make sure you have load-module module-udev-detect and not load-module module-alsa-sink in your /etc/pulse/default.pa.