Kodi Community Forum

Full Version: Sound Issues on Analogue Out with audio_pwm_mode=2 - latest firmware from Raspberry
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Be aware that the folks at Raspberry, in their attempt to improve the Analogue-Out sound in the latest firmware, have apparently broke it:
I haven't noticed myself any "subjective" sound quality improvements but the load on the GPU is deffo higher. I'm not registered at Raspberry Forum anymore (out of self-respect), but if some of you fellow Kodi-ers are, please let:  jdb -Raspberry Pi Engineer & Forum Moderator know about this - he needs feedback on the firmware changes / sound improvements.

I was trying the latest kernel&firmware from Raspbian - 4.9.59 and noticed constant cracks and pops while playing 1080p 50fps DVB streams on a Pi0 board with audio_pwm_mode=2. LibreELEC - latest versions 8.x - are also affected. With the firmware&kernel 4.4.50 everything still works fine.

Just to mention, I've recreated the audio circuit from the Raspberry Pi2B board (simple electronics) and connected it to the Pi0 GPIO (re-routed the Audio PWM pins). Kodi 17.x runs well on this Pi0 board (even flawlessly playing MPEG4 1080p 50-60fps content - GUI gets a little laggy though, but still usable).
Adding some details, the latest modifications to the audio generation algorithm are to be found in the latest official kernel release 4.9.80+, that comes with the  Raspbian release from 13.03.2018 and which are now enabled by default (no need to specify audio_pwm_mode=2 in the /boot/config.txt anymore) :

I only own a few Pi0 boards that I use for Kodi  and DVB streaming (tvheadend), and it is on these boards I observed this issue. I'm afraid that all the BCM2835 based Raspberry Pi boards are affected.

Here is a 16 seconds crackling& popping sample while playing a DVB-S2 stream (KODI+ remote tvheadend) - BBC World HD - 1080p @ 50 FPS on a pi0 running 4.9.80+ kernel and Kodi 17.4 + tvheadend HTS PVR Addon:
The output of bcmstats for this 16 seconds recording:
bcmstat.sh A
Successfully updated from v0.4.8 to v0.4.9
  Config: v0.4.9, args "A C", priority lowest (+19)
   Board: 1 x ARMv6 core available, ondemand governor (Pi0 rev 1.3, BCM2835 SoC with 512MB RAM by Sony)
  Memory: 512MB (split 384MB ARM, 128MB GPU) plus 200MB Swap
HW Block: |   ARM   |  Core  |  H264  |    SDRAM    |
Min Freq: |  700MHz | 250MHz |   0MHz |    450MHz   |
Max Freq: | 1000MHz | 400MHz | 300MHz |    450MHz   |
Voltages: |         0, 1.3500V        | +1, 1.2250V |
   Other: temp_limit=85, disable_auto_turbo=1
Firmware: Mar 13 2018 18:45:03, version 6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b (clean) (release)
  Codecs: H264 H263 MPG4 MPG2 MJPG PCM
  Booted: Wed Mar 28 10:33:03 2018

Time         ARM    Core    H264 Core Temp (Max)  IRQ/s     RX B/s     TX B/s GPUMem Free Memory Free/Used(SwUse) Accum  GPU B     Mem kB
======== ======= ======= ======= =============== ====== ========== ========== =========== ======================= =======================
10:39:36 1000Mhz  400Mhz    0Mhz 43.31C (43.31C)    202        781      3,670  74M ( 68%) 510,596 kB/12.6%( 0.0%)            0         -8
10:39:40  700Mhz  250Mhz  250Mhz 41.16C (43.31C)    143         54        220  74M ( 68%) 510,636 kB/12.6%( 0.0%)            0        +32
10:39:43  700Mhz  250Mhz  250Mhz 41.16C (43.31C)    141         27        193  74M ( 68%) 510,636 kB/12.6%( 0.0%)            0        +32
10:39:45  700Mhz  400Mhz  300Mhz 40.62C (43.31C)    143         55        216  74M ( 68%) 510,636 kB/12.6%( 0.0%)            0        +32
10:39:47  700Mhz  250Mhz  250Mhz 40.08C (43.31C)    143         27        195  74M ( 68%) 510,636 kB/12.6%( 0.0%)            0        +32
10:39:49  700Mhz  250Mhz  250Mhz 40.08C (43.31C)    141         27        193  74M ( 68%) 510,636 kB/12.6%( 0.0%)            0        +32
10:39:51  700Mhz  250Mhz  250Mhz 41.16C (43.31C)    143         54        218  74M ( 68%) 510,636 kB/12.6%( 0.0%)            0        +32
10:39:54  700Mhz  250Mhz  250Mhz 40.62C (43.31C)    145         27        193  74M ( 68%) 510,636 kB/12.6%( 0.0%)            0        +32
10:39:56  700Mhz  250Mhz  300Mhz 40.08C (43.31C)    144         27        193  74M ( 68%) 510,628 kB/12.6%( 0.0%)            0        +24
10:39:58  700Mhz  250Mhz  250Mhz 40.08C (43.31C)    144         27        195  74M ( 68%) 510,636 kB/12.6%( 0.0%)            0        +32
10:40:00 1000Mhz  400Mhz  300Mhz 41.16C (43.31C)    167         90        332  74M ( 68%) 509,280 kB/12.8%( 0.0%)            0     -1,324
10:40:02 1000Mhz  400Mhz  300Mhz 42.77C (43.31C)    146        133        240  74M ( 68%) 509,228 kB/12.8%( 0.0%)            0     -1,376
10:40:05 1000Mhz  400Mhz  300Mhz 43.31C (43.31C)    703    988,506     17,655  27M ( 25%) 504,264 kB/13.7%( 0.0%)  -49,283,072     -6,340
10:40:07 1000Mhz  400Mhz  300Mhz 44.39C (44.39C)    827  1,140,212     19,154  27M ( 25%) 503,412 kB/13.8%( 0.0%)  -49,283,072     -7,192
10:40:09 1000Mhz  400Mhz  300Mhz 45.46C (45.46C)    703  1,127,568     18,918  27M ( 25%) 502,688 kB/14.0%( 0.0%)  -49,283,072     -7,916
10:40:12 1000Mhz  400Mhz  300Mhz 45.46C (45.46C)    728  1,145,365     18,520  27M ( 25%) 501,004 kB/14.3%( 0.0%)  -49,283,072     -9,600
10:40:14 1000Mhz  400Mhz  300Mhz 45.46C (45.46C)    737  1,124,042     17,012  27M ( 25%) 501,572 kB/14.2%( 0.0%)  -49,283,072     -9,032
10:40:16 1000Mhz  400Mhz  300Mhz 45.46C (45.46C)    785  1,138,891     19,717  29M ( 26%) 501,208 kB/14.2%( 0.0%)  -47,185,920     -9,396
10:40:19 1000Mhz  400Mhz  300Mhz 45.46C (45.46C)    852  1,134,714     21,751  33M ( 30%) 501,300 kB/14.2%( 0.0%)  -42,991,616     -9,304
10:40:21  700Mhz  400Mhz  300Mhz 44.92C (45.46C)    757  1,127,890     19,906  33M ( 30%) 500,504 kB/14.3%( 0.0%)  -42,991,616    -10,100
10:40:23 1000Mhz  400Mhz  300Mhz 46.00C (46.00C)    770  1,149,953     21,569  33M ( 30%) 500,196 kB/14.4%( 0.0%)  -42,991,616    -10,408
10:40:25 1000Mhz  400Mhz  300Mhz 45.46C (46.00C)    776  1,131,174     19,585  33M ( 30%) 499,920 kB/14.4%( 0.0%)  -42,991,616    -10,684
10:40:28  700Mhz  250Mhz  250Mhz 45.46C (46.00C)    752  1,134,828     17,085  33M ( 30%) 499,720 kB/14.5%( 0.0%)  -42,991,616    -10,884
10:40:30 1000Mhz  400Mhz  300Mhz 45.46C (46.00C)    729  1,134,604     19,541  33M ( 30%) 499,744 kB/14.5%( 0.0%)  -42,991,616    -10,860

To summarize, the playback of 1080p @ 25FPS content using analogue out  - audio_pwm_mode=2 works fine with all the kernels & firmwares up to date on Raspberry Pi0 (BCM2835).
Then, playing higher frame rates:
- playing 1080p @ 50-60FPS video content under Kodi (omxplayer) using analogue out  - audio_pwm_mode=2 with the Raspberry Foundation official kernel 4.4.50 and the firmware 3ca4cf4a663c5351eaec08b29d50d6e8324981b4 is OK
- playing 1080p @ 50-60FPS video content under Kodi (omxplayer) using analogue out - audio_pwm_mode=2 with the Raspberry Foundation official kernel 4.9.80 (noticed first in the official 4.9.58) and the firmware 6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b is NOT OK, and a pity
(2018-03-28, 23:51)abga Wrote: [ -> ]- playing 1080p @ 50-60FPS video content under Kodi (omxplayer) using analogue out  - audio_pwm_mode=2 with the Raspberry Foundation official kernel 4.4.50 and the firmware 3ca4cf4a663c5351eaec08b29d50d6e8324981b4 is OK
- playing 1080p @ 50-60FPS video content under Kodi (omxplayer) using analogue out - audio_pwm_mode=2 with the Raspberry Foundation official kernel 4.9.80 (noticed first in the official 4.9.58) and the firmware 6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b is NOT OK, and a pity
Does adding force_turbo=1 to config.txt avoid the issue?

Would be useful to have a file that shows the problem. e.g. does 60 fps Big Buck Bunny have the issue?
(2018-03-29, 15:56)popcornmix Wrote: [ -> ]
(2018-03-28, 23:51)abga Wrote: [ -> ]- playing 1080p @ 50-60FPS video content under Kodi (omxplayer) using analogue out  - audio_pwm_mode=2 with the Raspberry Foundation official kernel 4.4.50 and the firmware 3ca4cf4a663c5351eaec08b29d50d6e8324981b4 is OK
- playing 1080p @ 50-60FPS video content under Kodi (omxplayer) using analogue out - audio_pwm_mode=2 with the Raspberry Foundation official kernel 4.9.80 (noticed first in the official 4.9.58) and the firmware 6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b is NOT OK, and a pity
Does adding force_turbo=1 to config.txt avoid the issue?

Would be useful to have a file that shows the problem. e.g. does 60 fps Big Buck Bunny have the issue?   
@popcornmix Thanks for your reply!
 I knew that the playback of MPEG4 - 1080p - 50fps is not officially supported by the GPU that is used on the Raspberry boards, but only 1080p at 25fps, and got really worried about this recent (2-3 years old) change on the HD (DVB-S2) satellite channels, broadcasting 1080p at 50fps. Happy that it was working and was enjoying it.

I was playing the 60 fps Big Buck Bunny without any audio issues, with both force_turbo=1 and without, under 4.9.80 + firmware 6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b

To fulfill my previous report and help your with a debug log, I went through a short playback, experiencing the sound issues, of  the BBC World HD DVB-S2 channel - 1080p at 50fps on the Pi0 v1.3 board running Kodi 17.4 and the PVR HTS addon, the tvheadend streamer running on a remote Raspberry Pi2B board and here you can find the debug log (modified a few privacy related records - keys/serials, nothing that might affect the study):

Some additional details on the audio issues on the Pi0 under 4.9.80 + firmware 6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b :
- while playing DVB-S2 channels - 1080p at 50fps, the OSD in Kodi becomes really delayed/laggy - almost unusable - GPU overwhelmed?
- disabled the de-interlacing, I'm currently only using MMAL Bob, and had no positive effect on the sound issues
- these audio issues are exactly the same in nature as previously observed (some years ago - older FFMPEG & Kodi releases) with using the MMAL Videoplayer & MMAL Advanced de-interlacing on Raspberry Pi2B, where the CPU was loaded at 40-50% and the GPU overwhelmed
- for more details about how I compile Kodi - and maybe more important - how I configure it, please look at the end section of this (long) post:

Just a thought, wouldn't be better to have these GPU audio generation algorithms, if possible, that's, if supported by the firmware capacity/structure, defined as:
audio_pwm_mode=1 -> for when only some simple sound is required (beeps & such)
audio_pwm_mode=2 -> good quality & better compatibility with the BCM2835 SoCs (actual issue)
audio_pwm_mode=3 -> improved quality (subjective for my ears, I don't own an oscilloscope/spectrum analyzer) - the new algorithm for Pi2B&Pi3B&above. Although, I haven't yet done any DVB-S2 MPEG4 1080p - 50FPS tests on the Pi2B boards I have with this new algorithm
Sorry for the short delay in providing you with sample files, zippyshare went crazy yesterday evening.

I recorded through tvheadend a few seconds from two MPEG4 - 1080p - 50 fps FTA DVB-S2 Channels on Astra 19.2 E and uploaded the ts files (raw transponder streams), each is around 40MB.
Kodi 17.4 is able to play these files directly and I was experiencing the reported sound crackles&pops with both. Note that Servus TV Deutschland has usally a higher bitrate than BBC ~ I observed it peaking at times at 18Mbps

1. - subscribing on channel "BBC World News Europe HD", network: "Astra", mux: "11229V", provider: "SES ASTRA"

Uploaded sample file:
MD5: 9df86ea8b927d6633ef305bb49106021

2. - subscribing on channel "ServusTV HD Deutschland", network: "Astra", mux: "11302.75H", provider: "ServusTV"

Uploaded sample file:
MD5: 2944e214483425658ca5a422e18e42c0
I tried to check the video format, focusing on the frame rate, for the two sample files from the previous post and learned that both files are 25 FPS (seems to be) from the output of:
mplayer -vo null -ao null -frames 0 -identify *.ts
FPS seems to be: 25.000000

By attaching a keyboard to my Raspberry Pi 0 Kodi player and accessing the (forbidden for remote control) magic button "o", I observed that Kodi is reporting 100FPS on the playback of the BBC World ts file.

BBCWolrd.png - screenshots - comparison between live play and playback:

ServusTV.png - screenshots - comparison between live play and playback:
I just replicated the reported audio problem on a brand new Raspberry Pi 2 Model B v1.1 (stashed a few back when these were still available for sale)  running the latest LibreELEC (official): 8.2.4 (RPi2.arm) that comes with the kernel 4.9.59 and the firmware 6e08617e7767b09ef97b3d6cee8b75eba6d7ee0b

On the Pi2, while playing BBC World HD, the sound was clear for the first 2-3 seconds, then the crackling and popping started and after 15-20 seconds I lost the sound for good and the image started to freeze every 2-3 seconds. I wasn't able to get the sound back, even playing another channel / local media content and I had to reboot the system. I was able to replicate this for 3 times in a row by rebooting the LibreELEC from the Kodi reboot menu. By using the MMAL Videoplayer instead of the OMXplayer I was only able to not loose the sound after the 15-20 seconds, the crackling and popping were still there.

Here you have a debug log - playing BBC World HD through the HTS PVR Addon by using OMX Player and loosing the sound for good:

With this latest observations, ruling out the low performance of the Raspberry Pi Zero - which I used in my original report, being able to replicate the issue on a powerful Pi2B board, I consider these new sound enhancements buggy / overloading the GPU.
@popcornmix  (et al.) have you had a chance to download the files from my post #5 and have a look at the reported issue? Please note that those files will become unavailable around the 30th of April and I might  need to upload them again.

Meanwhile I've been trying to understand why Kodi is reporting 50FPS for the BBC-World-News-Europe-HD channel, even 100FPS while playing back the recorded .ts file and with the help of some available players/tools I learned that the stream and .ts file should be at 25FPS:
- Media Player Classic (Windows) playing HTSP stream & recorded .ts file playback:
Video: H.264/AVC 1920x1080 25fps [V: h264 high L4.0, yuv420p, 1920x1080]
- MediaInfo -  https://mediaarea.net/en/MediaInfo
1920*1080 (16:9), at 25.000 FPS, AVC (Component) (High@L4) (CABAC / 4 Ref Frames)
- DVB Viewer (Windows) direct USB DVB Playback & recorded .ts file playback:
H.264 Video, 16:9, 1920x1088, 25fps
Note: I have used DVB Viewer since 2004, before recently (2 years) switching to Kodi on Raspberry boards, and I do remember that the channel ServusTV HD Deutschland was the only one (FTA) broadcasting FullHD at 50 fps with bandwidth peaks at around 20mbit/s . It looks like they've changed that now, might have become too expensive for them - DVB Viewer is reporting now 25FPS for ServusTV HD Deutschland

High Profile (HiP, 100)
 The primary profile for broadcast and disc storage applications, particularly for high-definition television applications (for example, this is the profile adopted by the Blu-ray Disc storage format and the DVB HDTV broadcast service).

My guess about the limitations of the GPU from post #4 (playing MPEG-4 -1080p - 50FPS) looks to be wrong and the new analogue sound algorithm is the only one causing the reported issue.

I just noticed:
and thought it might be related.
Just came by to report that the issue persists with the freshly released kernel - 4.14.50+ & firmware - 748fb17992426bb29d99224b93cb962fefbdc833 (extracted from the Raspbian image). Tested only on Raspberry Pi0 under Slackware ARM 14.2 and Kodi 17.4.
  * Linux kernel 4.14.50+
  * Raspberry Pi firmware 748fb17992426bb29d99224b93cb962fefbdc833

There is another rare issue I was experiencing for the last years (valid for kernel 4.4.50 and the firmware 3ca4cf4a663c5351eaec08b29d50d6e8324981b4 and pre) which caused the loss of analogue audio output (both Pi0 & Pi2B), recently confirmed here:
- in my case it happens only once a week or so, not sure about the cause but it looks like it happens only when I switch between DVB-S2 1080p channels too fast from the remote control, I hear a loud pop and the analogue audio stops working. After this event Kodi itself is still working but I need to reboot the Pi in order to get the analogue audio back - I just defined a remote control key and script in irexec.conf for this purpose - shutdown -r now ...

I wish I could do some more testing on these issues but the latest official kernel&firmware releases from Raspberry are confusing me and I'm not sure I'm able to track all the modifications in the official kernel&firmware git records because it looks like the actual releases (deliverables) are not consistent with them. Some recent examples:
1. - the compiled kernel, even patched - according the the source files - looks like it wasn't actually patched during the kernel compilation process:
2. - I need to patch a dvb driver and not able to find a corresponding Module.symvers file for the running kernel, the last time I tried was for the 2018-04-18 release -  kernel 4.14.34+ & firmware 5db8e4e1c63178e200d6fbea23ed4a9bf4656658, for which, by using the Raspberry official instructions under Raspbian,  I got 2 (actually there ware 3 including the kernel headers source files from the Raspberry official repository) different Module.symvers files, none of which apparently consistent with the running kernel.
3. - on this latest Raspbian release from 2018-06-27  - kernel - 4.14.50+ & firmware - 748fb17992426bb29d99224b93cb962fefbdc833  the script bcmstat.sh is reporting a different firmware release:
~# uname -r
bcmstat.sh A - reports:
Firmware: Jun 7 2018 15:31:38, version 4800f08a139d6ca1c5ecbee345ea6682e2160881 (clean) (release)
I'm so glad I found this thread! I've experienced crackling and pops for a while now when playing HD feeds on a RPi3 playing Kodi from a Mythtv backend. The popping invariably leads to a complete loss of audio that needs a reboot.

So after many searches for similar (but not identical issues) now I find the exact same set of symptoms.

I need analogue output as the sound is played through a separate amplifier/speakers. 

How do I help with testing?

First, try audio_pwm_mode=1 in config.txt. Does that avoid the issue?
Does disabling deinterlace avoid the issue? If it does does enabling deinterlace and switching it to bob avoid the issue?
Ahh I see it's already been fixed in the firmware (via rpi-updater). https://www.raspberrypi.org/forums/viewt...8&start=50

I'm running OSMC so I guess they've not yet propagated the new firmware.
Thanks for the heads-up, I've updated the firmware now, so it will make it in to OSMC's August update.
I'm wondering if the crackling and pops issues while playing DVB full HD streams are resolved now in the latest firmware, because the latest updates about fixes in the Raspberry thread are only related to the total loss of audio analogue (after the loud pop - I mentioned that occurring once a week or so):
The last update on that thread is 2 months old and Raspberry didn't provide any new Raspbian image (new kernel & firmware) since 2018-06-27

Since this audio analogue output doesn't look like a pre-designed feature of the Raspberry boards, but more of an afterthought, the DAC is resolved software in the GPU, I guess the long term approach is to use the MMAL acceleration and buy an external USB Sound Card with a proper HW DAC, or wait until Raspberry Pi 4 will be released and hope that the SoC used on that board will have an actual DAC.
For Raspberry Pi2B / 3B / 3B+, using MMAL instead of OMX is OK, although it's not efficient (loads the CPU) and my advice for an USB sound card is Creative X-Fi Go Pro (30 USD/EUR):

I'm only using Pi Zero boards (powerful enough!) for my multimedia needs (Kodi) and MMAL is not an option, so I'm stuck with the older (still working fine and secure enough) kernel 4.4.50 and the firmware 3ca4cf4a663c5351eaec08b29d50d6e8324981b4
Adapting OMXplayer to make use of external sound cards, without too much overhead, if that's even possible, might be the best resolution instead of focusing too much effort on the GPU DAC engine .
Pages: 1 2