Speaker phat vs. phat dac, clicks only on speaker phat

Support
1

So I reinstalled jessie on my phat dac and speaker phat and installed the hifiberry dac driver manually using the simplest asound.conf possible as described by hifiberry dac install description.

So then discovered that the native hifiberry-dac driver only supports stereo output.

so then I extended the asound.conf to include a software volume and a plug and that enables auto upmix to stereo and resampling.

pcm.!default {
type plug
slave.pcm “speakerphat”
}

ctl.!default {
type hw card 0
}

pcm.speakerphat {
type softvol
slave.pcm "plughw:0"
control.name "PCM"
control.card 0
}

essentially the phat dac doesn’t make clicks in same set up, but the speaker phat does make clicks. Just retouched the solder joints and still the same.

aplay does not intermittently hang anymore so not sure what happened there, could be something in your install routine, could be me removing the vu meter alsa config, certainly a lot of complex options in alsa configuration.

to me it seems definitely some hardware problem on the speaker phat causing it to click badly, not having another to test I cannot be sure if it is a bad single device or an oversight in the board design.

If you want to send me a revised version of the speaker phat to test then you should know who I am from my email address, I have made several purchases from you, and this is first problem I have had, so anyway, the product ideas you have seem cool, I’ll be Back!

2

Have you tried using the default asound.conf from our Speaker pHAT installer? If I use ESpeak and flip between this config file, and a generic asound.conf that pipes straight into the hardware, it makes a world of difference.

With the default config, ESpeak sounds great, but with:

pcm.!default {
    type hw
    card 0
    device 0
}

It sounds absolutely awful.

I can’t rule out a fault with your specific Speaker pHAT, but there’s definitely no design flaw since the DAC->Amp stage is all internal to the MAX97357A. We’d have to try pretty hard to introduce a flaw there.

The issue is the i2s clock abruptly starting and stopping on the Pi itself. While the DAC/Amp has built-in functionality to mitigate pops and clicks, it does suggest:

For optimal click-and-pop performance, ramp down the digital data on SDIN before powering down the MAX98357

Which loosely translates to: “Don’t stop the i2s clock abruptly at the end of your audio without gracefully ramping it down”

Stuff like ESpeak is constructed, by necessity, of very closely cropped phonemes that are organised to create words. If it’s playing these rapidly one at a time, and the i2s clock is starting and stopping with each one, the resulting mess is too much for the DAC/Amp to handle.

Similarly if you change station mid-way through a song in VLC, it will produce a horrible pop.

It seems Pulse Audio works well to help, as you found here; Speaker phat, loud clicks and removing the alsa driver - #18 by skypi

I’ve noticed with Pulse’s default configuration that ESpeak will never pop if you continually play audio, but has a timeout of 5 seconds before the audio device is closed. I could consistently play audio back to back and never hear a pop, but if I counted to five between each attempt there would always be a pop at startup (there really shouldn’t be, I wonder if Pulse is doing something weird when it opens the audio device).

3

Like I pointed out in other thread you have to remove the pulse idle module, but there are complications in trying to use it headless on jessie lite and multiple logins and trying to auto start pulse with the @reboot. Or even relying on pulse to start itself when first call to an alsa virtual device.

so seems the alternative is the method proposed by this guy which is per user config that I have not tested yet or running it as a system wide demon also not tested.

http://billauer.co.il/blog/2014/01/pa-multiple-users/

if you read the comments on that article there is a method for unix sockets rather than tcp they reckon may be bit faster

4

I’m struggling to get any popping issues at all on my Speaker pHAT, with or without pulse. Actually I’d go so far as to say with the stock Speaker pHAT ALSA config it’s actually better than with Pulse running with a 5-second timeout since Pulse seems to pop the DAC when it starts up anyway- I can’t seem to find out why, since using aplay filename.wav produces no startup pop at all (with Pulse disabled and audio routed straight to alsa), despite aplay having to open/close the audio device.

What audio are you attempting to play, and with what application?

Oh, and is it running on a Pi Zero/Pi Zero W?

5

well lets go back to a question I asked in the old thread, what pins need soldering, I soldered all the ground pins. I used the image on the site referred to in other thread to get the pinouts.

running on a zero w, jessie lite, leds work (using the i2c driver not your alsa plugin), sound works but any sound played does the click, pulse audio startup does the click but once you completely disable the idle dac power down in pulse and pulse has started no further clicks. (though as I said issues with multiple ssh logins to pi do cause clicks to resurface or sound not working at all)

where can your default alsa configs for speaker phat be got from? I do not want your alsa meter plugin as I want to drive the leds myself.

my /etc/asound.conf is

pcm.!default {
type plug
slave.pcm “speakerphat”
}

ctl.!default {
type hw card 0
}

pcm.speakerphat {
type softvol
slave.pcm "plughw:0"
control.name "Master"
control.card 0
}

as far as I am aware no other alsa config than just that file

6

I’m certain it’s not a soldering issue. It’s looking like my tests were massively swayed by using my development Pi 3 rather than a Zero.

Testing the same SD card across the Pi 3, Model B+, Model A+ and Pi Zero W reveals that, in my VLC Radio setup at least, only the Pi 3 can keep up with station changes and successfully switch from one audio source to another without a really obnoxious cracking sound.

This seems to be related to CPU- since the Pi 3 is a great deal faster than the other Pi’s, and VLCs average CPU usage is quite significantly lower. These tests were conducted with the same SD card, the same board (pHAT BEAT in this case), the same speaker, and the same power supply. Invariably the Pi 3 fared much, much better.

I’m not entirely sure why a loaded/slower CPU causes a pop/crack, but I suspect it’s something to do with the DAC being spun up before any audio data is prepared. It could also be a minor difference between the regular and the -v7+ kernels/modules but I doubt it.

Using Pulse seems to be the only tenable solution. It even sort-of fixes my VLC setup on the Pi Zero W, but introduces a slew of problems of its own, since the poor old Pi Zero just can’t keep up with the CPU demand of both VLC and Pulse Audio. sigh (although I’m making inroads with some careful tuning of both VLC and Pulse Audios config files)

But, I digress, the problem is that the Pi Zero is just too weedy to keep up with whatever the audio stack is doing when it spins up/down. Of course, this would suggest a real software fix is possible, because ALSA sure as heck shouldn’t be spinning up the i2s clock without some real data ready to output.

For now, Pulse Audio is my canonical solution where there’s enough CPU overhead for it to run properly, but I do appreciate it can vary from ~4% to ~50% with conservative settings on a Pi Zero.

In my experience Pulse seems to start/stop itself gracefully- all my tests have been conducted headless, connecting via SSH. I’m guessing your problems might stem from running audio services that use their own user context, and cause chaos when their own local Pulse instance is fired up?

It looks like the TCP setup should do the trick in this regard, although it only adds to the configuration headache this stuff already is.

I think our default asound.conf, with Pi VU Meter stuff removed, would look like this:

pcm.!default {
        type plug
        slave.pcm "softvol"
}

ctl.!default {
        type hw
        card 0
}

pcm.dmixer {
        type dmix
        ipc_key 1024
        ipc_perm 0666
        slave.pcm 'hw:0,0'
        slave {
                period_time 0
                period_size 1024
                buffer_size 8192
        }
        bindings {
                0 0
                1 1
        }
}

ctl.dmixer {
        type hw
        card 0
}

pcm.softvol {
        type softvol
        slave.pcm "dmixer"
        control {
                name "PCM"
                card 0
        }
}

But it wont prevent popping, since as explained above I was barking up the wrong (Pi 3) tree :(

7

OK, Thanks, I have it so it will boot and auto start my apps and after first click from pulse startup it works OK!

problem only gets worse as I am doing further testing in further ssh logins under same pi username which as you say is probably some complexity in the pulse settings about yielding pulse or not to another client and ssh session id’s etc.

i.e. if running X, that is actually a child of the single shell that starts it and so on with all shells spawned under X being children of X or parent which is what starts pulse. so a different heirarchy I think to multiple ssh logins.

that is to say my startup runs in @reboot from crontab, which does an aplay of a wav file (or pulseaudio -D) to start pulse then fires off two tmux sessions to run my apps. So i do not even log in to start up the application so seems the tmux sessions inherit from the @reboot state which probably starts a shell to run.

However if I do not do the @reboot in crontab but login and start pulseaudio -D and the tmux sessions from an ssh terminal I can login as other pi users in separate ssh sessions and aplay works ok. So seems some state thing in the drivers/shell-heirarchy

not sure I have tried all combinations of trying to start pulseaudio -D or not from @reboot yet.

8

So it seems, only by logging in as an ssh shell and starting pulseaudio, after which you can fire off tmux apps and then quit the login shell, does pulse audio start OK

if you do it manually you can log in on other ssh logins later and audio works ok and works ok from tmux app you initially started

Some oddity starting it from @reboot messes it up for any other ssh logins but works for the apps you started by @reboot

p.s. apologies for blaming the hardware!

9

stm part of the problem is non-professionals keep going Oh no we’ll do it all a new way and then break everything that was working perfectly well.

I guess the avconv/ffmpeg split is a classic case in point. Kind of like having to learn a new native language to communicate in your own country every few years eh! Innit! Certainly keeps you occupied in unproductive work.

10

You’re not wrong, and no worries. I’m still hunting for a set of settings that works for me with Pulse + ALSA + VLC on the Pi Zero W. It’s really, really touchy! What it looks like we need is a 5-min+ timeout built into ALSA itself that would keep the clock running, outputting silence so the speaker doesn’t overheat.

11

Hi, any update on this? I am running Raspberry PI Zero W with Musicbox OS and the PhatBeat. I also get really high noices/clips when starting/stopping, and when the next track start.

Any solution to this issue would be great, because as it is now, it’s just not usable. :(

Regards
Espen

12

I do not understand how the speaker can overheat by outputting silence, can you explain?

unless the voltage bias at digital zero on the dac is not 0v to the speaker which would of course explain the clicks as power at the bias voltage of digital 0 is applied to the speaker from its rest state.

Ah! because the voltage bias of +/- 0 is 2.5 or 3.3/2 then getting a spike eh!

question is is 2.5v or 3.3/2v holding speaker dead centre??? if so, no overheat!

or actually rms of constant 2.5v or 3.3/2v vs. audio activity that takes it into the 2.5v/2 or (3.3v/2)/2 realm 50% of time is warming it?

so I guess holding it at digital 0 at 2.5 volts is like max volume max frequency sine wave rms…

touch from the top on mine that is running at 2.5v silence with audio roughly every 10 minutes seems mildly warm, but it has a pi in a case warming it from below as well! so are you perhaps a bit scaremongering? like what does an active standard audio speaker do when it has no audio playing through it? stick at constant half voltage I think! but is not rms of most music 2.5 volts no matter how soft or quiet (if it goes long way less than middle typically goes long way higher than middle as well…)

I wonder if I am sensing more lesser droid bullshit about the overheating, as surely most audio as it always crosses centre and typically averages as much higher as lower than 2.5v all averages out at rms 2.5v as that is centre voltage, when I say 2.5v I mean vcc/2 assuming vcc=5v

I’m calling bullshit matey! (though I stand to be corrected)

though I still think your implementation of circuit board ideas is good! this is just the way that chip behaves… other chips have speakers already sitting at half vcc to output to eh!

sound of silence half vcc eh! and that background not tinnitus but real high frequency so tuned they use it as a data transport layer eh!

of course this chip very good for low power use, as it turns off speaker, but need a circuit that detects power-off-power-on transition and masks the spike if it wants to be really good! moderately fast ramp from 0 to half vcc eh!

a whoop fwoom whatever would be better than CLICK!!!

Of course the click at average volume might wake up some dozy cctv observer!!!

13

I have had some success with pulse audio, but that is only with raspbian jessie-lite, which has some problems still in that due to no x-windows the current config of pulse audio does not work for multiple ssh logins but it does work for the first thing that grabs the audio device. I have been through so many config settings I am not 100% sure but I think this is what might solve it. works for me but not as well as it could.

install pulseaudio

in /etc/pulse/default.pa comment out

# load-module module-suspend-on-idle

in /etc/pulse/daemon.conf
amend the value for this parameter to negative number

# negative value disables exit
exit-idle-time = -1

then

pulseaudio -k will kill current session if any

pulseaudio --start will start in daemon mode.

so I can run pulseaudio --start from a crontab @reboot shell script that then loads
my app, that gets exlsuive use of hardware and stops the clicks.

(other apps fail to get the hardware due to dbus not being set up properly on a headless system)

I think if you configure mpd to use pulse that should start up with a systemd unit and grab the pulse driver OK, not tried it, and you may need to amend other settings in the pulse config files, which are hugely configurable.

14

actually the problems I had may not be with pulseaudio but with tmux, so just install pulseaudio, change those two pulseaudio settings and see if it works!

15

OK, thanks, I’ll give it a go. With my musicbox OS, i could not find the files and folders you mentioned, so I am installing Jessi lite with mopidy as a service instead. I’ll keep you posted on the progress.

16

I can confirm that what actually works is to comment out ‘load-module module-suspend-on-idle’ in ‘/etc/pulse/default.pa’

I got the same problem of clicks. I updated my code to replace my audio playback implementation using Alsa library by another one using PulseAudio and everything works perfectly.

17

The setup I now use generally for reducing pops and clicks is this one: https://gist.github.com/Gadgetoid/3301cec3e47495e75b31d3120d8f17d9

This using a similar technique of putting the breaks on “module-suspend-on-idle” (although I’ve read elsewhere that removing it altogether causes other problems) so that pulse keeps the audio device open in perpetuity.

I’ve set up a one-line installer for it, but it should really only ever be run on a fresh Raspbian installation.

18

having just tried an adafruit speaker bonnet with same but stereo chipset with a set of over specced speakers 3w into 4 ohm 5w I think the pop is noticeably less, guess speakerphat using 8 ohm speaker made it worse, but theoretical power size thing eh!

anyway pulse fixes that…

I guess the subtlety is in the missing, actual effect of the dissapearing 3 watts, equation!

actually speaker bonnet clicks a lot as well using alsa, so it’s just that dac, but I think the click is easier to mask with the bigger speakers (i.e. if the start up track/audio starts at a loud point click is better masked than on that diddy speaker on the speakerphat)

though speakerhat does what it does, fits in a very small form… and once pulse is sorted works well for a little speech notifier. No reason if you have the space to not just solder in a larger mono speaker, if they sold the board separate. Though adafruit do a £5 board with that dac on.