Analogue audio redux

[GeorgS]

The change won't be reverted, as there are multiple other use-cases that break if the driver doesn't support multiple writers.

- Please upload a sample of garbled audio somewhere downloadable (preferably captured by a sound card line-in port, not a microphone)
- Do you have composite video enabled on any of your devices?

Thanks for the details, didn't know the new PWM commit entangles so much the firmware.

I was looking for an easy and consistent setup where you could replicate 100% the reported sound issue (garbled sound) and choosed the latest LibreELEC 9.2.4 for the Raspberry Pi2B target.
Configuration: playback on either MMAL or OpenMAX acceleration, no de-interlacing and audio settings on lowest (no GPU accel & fixed 44.1kHz sampling)
LibreELEC:~ # uptime
16:14:03 up 29 min, load average: 0.44, 0.68, 0.67
LibreELEC:~ # uname -r
4.19.127
LibreELEC:~ # /opt/vc/bin/vcgencmd version
Apr 15 2020 11:44:24
Copyright (c) 2012 Broadcom
version 82f9bb929ce2186eb1824178c1ae82902ad6275c (clean) (release) (start_x)
LibreELEC:~ # cat /etc/os-release
NAME="LibreELEC"
VERSION="9.2.4"
ID="libreelec"
VERSION_ID="9.2"
PRETTY_NAME="LibreELEC (official): 9.2.4"
HOME_URL="https://libreelec.tv"
BUG_REPORT_URL="https://github.com/LibreELEC/LibreELEC.tv"
BUILD_ID="1c135e5303ae599339eea56fd6c253dd81965674"
OPENELEC_ARCH="RPi2.arm"
LIBREELEC_ARCH="RPi2.arm"
LIBREELEC_BUILD="official"
LIBREELEC_PROJECT="RPi"
LIBREELEC_DEVICE="RPi2"

Choose any DVB-(C/T/S) 1080p stream that contains a proper quality video above 5-6 Mbit/s and you'll get the following audio outputs:
music.wav - 1080p Music Channel
https://www37.zippyshare.com/v/xDazy6M4/file.html
speech.wav - 1080p Documentary Channel
https://www83.zippyshare.com/v/w1qIC6rn/file.html

I believe you could also test it by playing a 1080p proper Blu-ray full rip (uncompressed - no loss). Playing some very lossy Internet streams (Youtube & such) works OK with audio_pwm_mode=2. I guess it doesn't overwhelm the vc4 core, but testing such lossy video formats is substandard.

No, I don't have the composite video enabled on any of my devices, just HDMI. Don't know if it matters, but I have the mpeg2 HW decoding engine activated - bought mpeg2 licenses on all of them and enabling it in /boot/config.txt

[jdb]

Thanks for the description. Unfortunately your two zippyshare links give me 403 errors - links expired?

[GeorgS]

Thanks for the description. Unfortunately your two zippyshare links give me 403 errors - links expired?

Both links are working here and I've been using zippyshare for quite a while now without any issues here in Europe. Your ISP/firewall could block it, UK is quite restrictive with file sharing.
I re-uploaded the files on the popular Mediafire hosting service:
music.wav - 1080p Music Channel
http://www.mediafire.com/file/v4iq7os0r9fsg3v/file
speech.wav - 1080p Documentary Channel
http://www.mediafire.com/file/bi5mgcy1zc8hesf/file

I hope it works for you now. If not, then please let me know which alternative you prefer. The files are small, 10 seconds of recording through audio-in, less than 4 MB in total.

[jdb]

I've downloaded the files from mediashare. From a brief look, it seems like there is borderline VPU underflow because I see discontinuities in the captured waves at ~5ms intervals (the size of one DMA block).

The MPEG2 hw decode makes some use of the VPU for some of the decode stages but I'm unsure how much. Later Pi models (>=3) tend to be able to handle 1080p decode on the ARMs without issue - do you have a Pi 3 or Pi 4 to see what happens with software decode on the same setup?

Alternatively, does the stuttering reduce if you overclock core_freq?

[6by9]

I've downloaded the files from mediashare. From a brief look, it seems like there is borderline VPU underflow because I see discontinuities in the captured waves at ~5ms intervals (the size of one DMA block).

The MPEG2 hw decode makes some use of the VPU for some of the decode stages but I'm unsure how much. Later Pi models (>=3) tend to be able to handle 1080p decode on the ARMs without issue - do you have a Pi 3 or Pi 4 to see what happens with software decode on the same setup?

Alternatively, does the stuttering reduce if you overclock core_freq?

What are the comparative loadings on the 2 VPU cores? "sudo vcdbg hist gnuplot" should give you two files called task.gpt and task.gpt, and "gnuplot task.gpt" should then display the three graphs of VPU0, VPU1, and combined.
Memory says that video_decode shifts part of the processing to VPU1, but I can't remember exactly what.

[GeorgS]

On the LibreELEC 9.2.4 Pi2B test system I added core_freq=500 to the /boot/config.txt and rebooted.
Started playing a MPEG-4 1080p DVB stream and manually checked the core_freq (every second or so). Noticed it's dynamic:
LibreELEC:~ # /opt/vc/bin/vcgencmd measure_clock core
frequency(1)=250000000
LibreELEC:~ # /opt/vc/bin/vcgencmd measure_clock core
frequency(1)=500000000
LibreELEC:~ # /opt/vc/bin/vcgencmd measure_clock core
frequency(1)=250000000

Couldn't notice any improvement. Please check the following recording for yourself:
http://www.mediafire.com/file/iwzw64whr7xj2c0/file

Also commented the MPEG-2 license activation in /boot/config.txt without noticing any improvements.

Sorry, I don't own any Pi3B (gave it away, couldn't make use of the constant throttling) or Pi4B (burned out on my desk while compiling Apache Hadoop and returned it - 14 days money back guarantee) anymore, but only a dozen Pi2B and PiZero boards.

[jdb]

Can you capture the vcdbg logs when the audio is glitching and upload the results? They should fit in the forum's attachment size limits.

[GeorgS]

Got the static vcdbg from pelwell's link:
https://github.com/raspberrypi/Raspberr ... -653209729

Started the LibreELEC 9.2.4 Pi2B test system with default clock frequencies:
Board: 4 x ARMv7 cores available, ondemand governor (Pi2 Model B rev 1.1, BCM2836 SoC with 1GB RAM by Sony UK)
Memory: 1024MB (split 768MB ARM, 256MB GPU)
HW Block: | ARM | Core | H264 | SDRAM |
Min Freq: | 600MHz | 250MHz | 0MHz | 450MHz |
Max Freq: | 900MHz | 250MHz | 250MHz | 450MHz |
Voltages: | 0, 1.3125V | +1, 1.2250V |

Played some MPEG-4 1080p DVB stream, experiencing the sound crackling and generated the files:
LibreELEC:~ # ./vcdbg -v hist gnuplot
task history written to task.gpt and task.dat
LibreELEC:~ #tar -czpf graphs-ok.tgz khrn.dat task.dat task.gpt

Resulted graphs-ok.tgz available at Mediafire:
http://www.mediafire.com/file/jcp2b3jnz6e7vec/file

I had to recreate and re-upload the archive because I missed the task.gpt file the first time. Post edits in bold.

[GeorgS]

Besides, I don't know if it helps - maybe for comparison, but I performed a tests with the same MPEG-4 1080p DVB stream source on a Pi Zero 1.3 board I'm currently using with the old firmware 63899229b09d22184ee4d2ab9662e9b32b9ec875 (github commit), audio_pwm_mode=2 and proper sound output.

I manufactured a few audio cards by copying (1 to 1) the schematics from the Pi3B board, wired and glued them together with an IR receiver and a mini jack female connector on top of a 40 pin ATA connector.

https://i.postimg.cc/qMRnKqJK/pizero.jpg
https://postimg.cc/HjqVDp7W

Using 3 such PiZero boards as Kodi players ATM and rerouting the PWM pins in /boot/config.txt with: dtoverlay=pwm-2chan,pin=18,func=2,pin2=13,func2=4

Some details:
Board: 1 x ARMv6 core available, ondemand governor (Pi0 rev 1.3, BCM2835 SoC with 512MB RAM by Sony UK)
Memory: 512MB (split 384MB ARM, 128MB GPU) plus 200MB Swap
HW Block: | ARM | Core | H264 | SDRAM |
Min Freq: | 700MHz | 250MHz | 0MHz | 400MHz |
Max Freq: | 1000MHz | 400MHz | 300MHz | 400MHz |
Voltages: | 0, 1.3500V | +1, 1.2250V |
Other: temp_limit=85, disable_auto_turbo=1
Firmware: Oct 10 2017 14:23:57, version 7d8a5ead990e3dd90d322921499935e3eebd3b53 (clean) (release)

Mediafire graphs (./vcdbg -v hist gnuplot) archive graphs-pizero.tgz
http://www.mediafire.com/file/5t4b2uxq3ahjy3h/file

[jdb]

The trace files provided show that while there's load on VPU1 in addition to the audio processing thread, there are plenty of free cycles. The usual suspects for problems like these are priority inversions or exclusive resource contention.

It may be a while before I can get round to looking at this but it's on a list of things to fix.

[GeorgS]

Thanks for the investigation. Please let me know if any additional help is required. I have the LibreELEC SDCard images stored and I can easily prepare a test environment, even for the work-in-progress firmware files you'd like to test.

During the weekend I played a little with overclocking on a few PiZero v1.3 boards loading the latest LibreELEC 9.2.4.
Learned that with only these two enabled:
gpu_freq=580
over_voltage=8
I almost got rid of the audio artifacts. Unfortunately, anything above gpu_freq=500 will make the board unstable (graphics crashing), even if the temperature never exceeded 56C and power peaked at 0.3A (5V).

Wondering if it's acceptable to substitute the audio_pwm_mode=1 with the older code for audio_pwm_mode=2, the one before the "audio redux", as a workaround (maybe even permanent - it's tested, working properly, and doesn't load the GPU too much). The new audio_pwm_mode=2 (audio redux) is already enabled by default for all users and audio_pwm_mode=1 was never useful, other than for some simple beeps and such, quality is just plain horrible. My point is, why not improve audio_pwm_mode=1 and provide the users with a useful alternative, again, at least as a workaround until you fix the new audio_pwm_mode=2 "audio redux".

[jdb]

Latest rpi-update firmware avoids running the audio resampling on the same core as deinterlace/camera tasks. It should fix your use-case (and others) but there is the possibility that other more obscure sets of tasks may interfere.

[GeorgS]

Latest rpi-update firmware avoids running the audio resampling on the same core as deinterlace/camera tasks. It should fix your use-case (and others) but there is the possibility that other more obscure sets of tasks may interfere.

Thanks! Much appreciate your effort on this, it's been almost 3 years now since the audio generation (SW DAC) is broken.

Noticed the firmware commit you're referring to:
https://github.com/Hexxeh/rpi-firmware/ ... ccf44559b9

Got the e8ddac7cd34b179efd702d4dc1efd0ccf44559b9 firmware files and loaded them together with the Raspberry kernel 5.4.51 & latest videocore libs.
There are indeed improvements, the audio crackle is still happening, less often apparently, but still there and noticeable, unfortunately.

I've uploaded a recording on line-in from a short BBC Europe HD 1080p playback:
speech-new.wav - 1080p (BBC Europe HD)
http://www.mediafire.com/file/m6lbv77dj ... w.wav/file
Together with the corespondent GPU graphs (captured during the recording):
GPU-graphs-new.tgz
http://www.mediafire.com/file/hh91pvnb1 ... w.tgz/file
- which is the result of:

Code: Select all

./vcdbg -v hist gnuplot
tar -czpf GPU-graphs-new.tgz khrn.dat task.dat task.gpt

I'm using MMAL Bob de-interlacing (also during the test above) and went on to disable it (no interlacing at all) and learned that the audio started to be OK, at least I couldn't notice any crackle whatever I tried to play. I guess there is still some interference between the de-interlacing and audio generation on the GPU cores. Here are the GPU graphs for the test when the de-interlacing was turned off and the audio was OK (playing BBC Europe HD 1080p).
GPU-graphs-deinterlace-OFF.tgz
http://www.mediafire.com/file/qtn7fy2qb ... F.tgz/file
- result of:

Code: Select all

./vcdbg -v hist gnuplot
tar -czpf GPU-graphs-deinterlace-OFF.tgz khrn.dat task.dat task.gpt

Please let me know if you need me to perform additional tests. I'm genuinely interested and committed to resolve this issue.

[6by9]

short BBC Europe HD 1080p playback

I'm using MMAL Bob de-interlacing

Why are you trying to deinterlace a progressive stream?

What are you using to playback the stream? Still Kodi?
Which Pi variant are you using now? Your older posts seem to mention almost all versions.

[GeorgS]

short BBC Europe HD 1080p playback

I'm using MMAL Bob de-interlacing

Why are you trying to deinterlace a progressive stream?

AFAIK it's an interlaced stream that is de-interlaced/transformed to progressive scanning. Without de-interlacing it just looks bad (scan lines become apparent). It's common to stream interlaced content over DVB-S/DVB-S2 in Europe (also DVB-C/T/T2), most of the HD channels I'm receiving are interlaced, thus, I need to keep the de-interlacing active.
Worth having a look over these two links:
https://en.wikipedia.org/wiki/Deinterlacing
https://medium.com/hd-pro/progressive-v ... 8e2924800e

I choose the BBC Europe HD channel as reference because it's British, same as Raspberry
Here is the official channel info:
https://astra.ses/channels/bbc-world-news-europe-0
And here is a short raw ts (TransportStream) recording over DVB-S2 (it's MPEG4 and should be playable in any standard players):
http://www.mediafire.com/file/xut7nku01 ... HD.ts/file
The MediaInfo utility reports:

Code: Select all

Scan type                                : Interlaced
Scan type, store method           : Separated fields
Scan order                               : Top Field First

Additionally, I uploaded a second short raw ts recording for another 1080p DVB-S2 OTA channel - CNBC Europe HD:
http://www.mediafire.com/file/72xcfng32 ... HD.ts/file
For this one, the MediaInfo utility reports:

Code: Select all

Scan type                                : MBAFF
Scan type, store method           : Interleaved fields
Scan order                               : Top Field First

What are you using to playback the stream? Still Kodi?

Yes, it's what I choose some posts above as convention for the tests, because I can reproduce the issue 100%. It's also reproducible (more difficult) in some other circumstances, like while playing some FLAC files or high bitrate audio streams and putting some high load on the GPU.
I'm using Kodi 17 because Kodi 18 is not properly playing PVR DVB streams (has some buffering and frame drops when starting the playback - it was already reported to your colleague Dom (popcornmix) in the Kodi Forum) and I'm using the OMX acceleration. Alternatively, the MMAL acceleration has the same outcome with respect to the reported audio crackle.

Which Pi variant are you using now? Your older posts seem to mention almost all versions.

I'm only using the Pi2B v1.1 for these tests. In my older posts I mentioned that I'm also using some Pi Zero boards for media playback, including Kodi, and that I only own a bunch of PiZeroes and Pi2B boards. The only Pi3B I owned I gave it away as present (wasn't able to make use of it because of the constant throttling) and some months ago I bought & managed to burn a Pi4B while compiling some large apps.

[varun21]

Does this driver work on 64bit?