Analog audio quality regression with 05dbfa4d59 commit

[cpinkham]

The 05dbfa4 commit which updated the firmware has introduced an audio quality regression that appears to affect both the B and B+. This issue appears to still be present in the current version of the firmware tested yesterday.

The Falcon Player (http://github.com/FalconChristmas and http://FalconChristmas.com) uses Raspberry Pi's to play Christmas light sequences along with synchronized audio and video using mpg123, ogg123, and omxplayer. When attempting to update our base SD image to a new version earlier this year, we noticed a severe audio degradation. We use rpi-update to update our image and did a bisect to locate the commit where the degradation occurred.

The quality degradation is evidenced mainly in the high pitch tones although I am not sure exactly how to describe it. Depending on the audio clip, it sounds like clipping or high pitched noise when the audio is supposed to be playing a high tone. This occurs at all volume levels on the Pi. The only way to restore audio quality was to revert to the prior commit a0eb067.

We have tried using a mixture of firmware and kernel versions to work around the issue but everything pointed at the change to start.elf in commit 05dbfa4. If we use a working system based on a0eb067 and replace only the start.elf file committed in 05dbfa4 then the audio quality degradation shows up.

I believe that a lot of the model B+ analog audio quality issues are being blamed on hardware when in fact they may be related to this regression in the firmware code. B+ users need the newer firmware and kernel for the new hardware and hence all B+ users are affected by this issue.

[popcornmix]

Can you provide a test app that demonstrates this problem well?
Either an arm binary file, or a wav/mp3 file with instructions for which player you are playing it with.

[cpinkham]

We are using mpg123 and ogg123 from Raspbian.

mpg123 1.14.4
ogg123 from vorbis-tools 1.4.0

A 1MB clip which demonstrates the issue is available at https://www.dropbox.com/s/4bc35ub2t7vw8u1/SHeDAISY-Deck_The_Halls_1MB.mp3?dl=0

We are not providing any extra command line options, the filename to play is the only argument passed to the player.

mpg123 SHeDAISY-Deck_The_Halls_1MB.mp3

[popcornmix]

I've spent some time listening to your sample with older and newer firmwares and I can't hear any difference. (This is with a cleanly booted raspian image).

I've looked closely at the commits around the firmware you identified and I've got an idea what you may be hitting.

There were some changes back then to avoid resampling where possible (mostly for hdmi passthrough purposes, but also to maintain audio quality).

This had the effect that pwm audio will choose a PLL that's a multiple of sample rate and avoid resampling. However to avoid popping we also avoid closing/opening the PWM audio channel. This means you stick with the sample rate of the first track. If the first track you play is 8kHz, then that will degrade the 44.1kHz track you play later.

If you add "force_pwm_open=0" to config.txt and use latest firmware, you should find the audio quality is improved, but you get the popping between tracks.

Ensuring the first audio that is played is 44.1kHz/48kHz will also avoid the problem.

I think the real solution is to always run the PWM audio at 48kHz when de-popping is enabled. The software resampling is far higher quality than you will hear through the analogue audio interface, so shouldn't be a problem. I'll do that in next firmware update.

[popcornmix]

Here is a test build (fixed 256M/256M memory split) with the change I suggested.
https://dl.dropboxusercontent.com/u/3669512/temp/start_analogue.elf

[cpinkham]

I think you hit the nail on the head. We use the flite text to speech engine to play a message when the Pi boots to announce the IP address so that users can run the system headless and still know the system booted and know what IP to contact the system on. I doubt that flite uses 44.1 or 48, it's probably 8. This would also explain why some Pi users around the net report that the audio is good sometimes on the B+ and not at other times, I have even heard users report that they thought it worked well sometimes when they booted but not at other times. This is probably due to the differences in the audio they played first after boot.

I updated two of my Pi's, a B and a B+, to the latest firmware and 3.12.29 kernel and the audio issue still occurred as I expected. I then copied your start_analogue.elf into place as start.elf on these systems and rebooted both and the audio quality on them seemed to match that of another B that is still running the older firmware and 3.10.33 kernel I mentioned in my original comment.

The Falcon Player can synchronize video playback on multiple Pi's using a patched version of omxplayer that lets us make small speed adjustments to speed up or slow down the secondary system(s) to get them into perfect sync with the master system. Once they are in sync, their playback speed returns to normal. I tested a set of synced FPP instances with one running the old firmware and 3.10.33 kernel and another updated system running the latest 3.12.29 kernel and your test firmware and to my ears, the audio sounded identical between the two.

I am going to write up some simple instructions for a few of our B+ users to follow to get some more ears listening to see if others confirm the audio quality is equal to what they are used to with the older firmware and kernel.

Thank you for looking into this so quickly. I will report back once I have confirmation from others.

EDIT: I forgot to mention prevously, the suggested "force_pwm_open=0" test did not work on my system when running the 3.12.29+ kernel and accompanying firmware. This setting actually caused omxplayer to freeze on my system and the 'flite' audio did not play at boot.

[cpinkham]

Thank you, this test firmware and release version has resolved the issues that we were seeing. I posted instructions on our forum for testing the original test firmware and later for updating to the latest released firmware via rpi-update and we have heard very positive results from users.

[popcornmix]

No problem. Thanks for tracking down the firmware version that caused the issue - that always helps.