5

I am playing short sound effects using aplay whenever users interact with the interface.

What I notice is that I can play any of the sounds in any order and as long as two sounds play within 5 seconds of each other the transition is clear, but a gap of anymore than 5 seconds and there is a horrible pop!

Note that all of my sound files are < 1 second in duration.

What I have done to hack around this is to create a 5 second long low sample rate silence.wav file that loops in an .sh script (which is definitely not a long term solution):

Brute forcing with silence:

#!/bin/bash
while [ 1 ] ; do
 aplay sounds/blank.wav
done

The popping is now very seldom, if at all.

So what I can't figure out is why the heck something is changing in those 5 seconds to cause the pop? How can I configure my audio to remain in a state where it won't pop when a sound is played after a long delay?

I have experimented with /etc/pulse/default.pa and /etc/pulse/daemon.config but have made zero progress.

Note that I am using a single core raspberry pi, but if brute forcing with silence helps, then there's still hope??

[UPDATE]

I came across a slightly more elegant way to continuously brute force silence to the devices:

aplay /dev/zero
    
Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono

But for some reason it produces a high frequency tone instead. Is there possibly a similar way to do this?

[UPDATE]

aplay -r 8000 -f S16_LE /dev/zero

This does the trick, with some overhead of running a thread constantly to keep things open. But otherwise very clean audio now.

[EDIT]

This feature is related to the pulseaudio module module-suspend-on-idle. Also possible to disable this module. Try temporary first:

pactl unload-module module-suspend-on-idle

If you are satisfied, then you can make this setting temporary in the pulseaudio configuration file.

4
  • I would tend to agree, and that's exactly what I wish to disable. But to clarify I am using a I2S dac connected directly to the GPIO. For such a simple device I don't believe it would be responsible for managing power states..
    – Logic1
    Sep 2 '18 at 18:33
  • 1
    Answers to your own question are perfectly valid, but belong in the Answer box, not as part of the Question.
    – Jeff Schaller
    Sep 3 '18 at 12:25
  • may be power saving as already stated, even on a 'simple' device. to test for this keep Pulseaudio Volume Control pavucontrol open on desktop - that is usually enough to stop the power management and have no pop. pops will return if pavucontrol is closed. if test confirms it is power management, Pulseaudio configuration can be adjusted for permanent solution to this
    – nik gnomic
    Apr 28 '19 at 11:11
  • I am not sure why this question was closed, the reason given for closing the question was not accurate and the problem still exists and never "seemingly went away on its own". So I add this comment in protest.
    – Logic1
    Mar 5 at 2:38