Clicks and Pops and Sound Quality

[hpmax]

My "safeguard" feature was less successful than I had hoped. I believe what is happening is the speaker has momentum and continues to move even after it's brought back to "rest." Another possibility is that the capacitive coupling shifts the waveform, therefore the waveform at the speaker is actually not at 0 when you output 0 to the DAC. It might be theoretically possible to calculate this, but it would be really difficult.

When switching between operating modes (mute/deadband, sink, climb) you can go from 0 to full volume or vice versa, instantly. For example, sink is always at full volume, deadband is always 0. Climb can be any volume, depending on where on the waveform it is. The climb waveform is square but with a rise and fall time on the edges.

I re-wrote the code so that volume should be a continuous function. That is, it can change, but the change is rate limited so it can't change instantaneously (note that if you adjust the volume by using volume up/down, the change is NOT rate limited.
This seems to get rid of all the clicks and pops I was hearing, and I will release the code soon.

I do find the sound to be a bit harsh... I was wondering if rather than using a triangle wave, we want to pre-compute a waveform (perhaps a triangle with blunted tips) and then implement a lookup table. Does anyone have any ideas on what waveform might sound more... pleasant than the triangle?

[hpmax]

I thought I had gotten rid of all the clicks and pops -- looks like I might have been a bit hasty.

I stand behind my previous comments. Switching modes could (and often will) cause a click/pop. My code changes eliminate those -- but I am still getting click/pops (which I still think are fundamentally a rapid change in volume). They are less common, and they often seem to come in pairs. I think this is something akin to a buffer underrun. The first click usually occurs coincident with a synthesize_vario call with a large frames_n, and the second click is in the next frame (which also usually has a large frame_n). But the weird thing is adjusting the buffer size doesn't seem to have a significant impact on this, and frames_n is ALWAYS less the buffer length which would indicate it's not ACTUALLY a buffer underrun.

Unless there is some magic with pulseaudio, the only thing I can think to do is convert to fixed point and hope the speedup reduces the chance of this behavior.

Anyone have any ideas?

[hpmax]

And, I think I've solved all the clicks and pops... I can confirm that my revised code is definitely fixing most of them. The other source of problems was pulseaudio itself. I killed pulseaudio and restarted and everything worked much better. Pops are gone, and the frames_n number is far more stable.

I strongly suspect there is a link between this and the issue I found with sensord, where the real timing issues were exacerbated when launched as a service instead of being run from the command line. It really would be a good idea if one of the more Linux knowledgeable people looked into this, and until we come up with a solution we should probably change all the services to launch from the command line.