Page 3 of 4

Re: Analogue audio redux

Posted: Thu May 31, 2018 7:37 am
by jdb
Multiple audio streams should be supported. It was one of the reasons for rewriting the buffer handling code from the first version.

Do you get the same or different behaviour if you revert to the old driver (audio_pwm_mode=1)?

Re: Analogue audio redux

Posted: Thu May 31, 2018 9:43 am
by epoch1970
jdb wrote:
Thu May 31, 2018 7:37 am
Do you get the same or different behaviour if you revert to the old driver (audio_pwm_mode=1)?
Thanks!

I have set audio_pwm_mode=1 on my machine.
Following the same steps as in the other post, the system behaves as expected. Streams can start/stop independently and are remixed when restarted.

(This is on a test SD, I don't care much about the system there. Let me know if you need me to further test/install stuff.)

Re: Analogue audio redux

Posted: Thu May 31, 2018 11:07 am
by niwa3836
Hi jdb / epoch1970,

I've re-performed the test too for completeness as i have a unit that is completely fresh (3B+).
Test 1:
dtparam=audio=on
audio_pwm_mode=1
window 1: start audio (good)
window 2: start audio (good and mixing with first)
window 1, stop and restart same audio (good)
Test 2:
dtparam=audio=on
audio_pwm_mode=2
window 1: start audio (good)
window 2: start audio (good and mixing with first)
window 1, stop and restart same audio (BAD).

I love the audio quality of mode 2 (over mode 1) and would love to know if this could be fixed :) Any ideas what could cause it (I really do use the feature of mixing a lot!). Can I help in any way? If anyone spots the fix could you please let me know, really many thanks for everyone's help so far!

Re: Analogue audio redux

Posted: Thu May 31, 2018 6:16 pm
by jdb
OK that confirms the bug, then. Multi-stream "hardware" mixed playback (actually done on the VPU) is one of the target use-cases for the driver.

The mixing is done at the same stage as the fractional rate conversion - we use an oddball internal samplerate (48828.125Hz) so that we can then use much cheaper integer-factor resampling to produce the 781250Hz samplerate that goes to the PWM controller. The fractional resample stage should seamlessly handle mixing from multiple sources as it's VC4 library code in use across both drivers.

My time is somewhat constrained at the moment but I'll take a look the next time I'm in the vicinity of VC4 firmware.

Re: Analogue audio redux

Posted: Fri Jun 01, 2018 8:08 am
by niwa3836
Hi jdb,

Many thanks for responding and confirming that it is a bug. The calculations look very complex! This is really important for me for lots of reasons and therefore how much rocket fuel do you need me to supply to help fix this? My project is in your hands! (joking apart is there anything else I need to do to help / be formal etc as needed?). Many thanks for your help so far!

Re: Analogue audio redux

Posted: Thu Jun 14, 2018 6:25 pm
by niwa3836
Hi jdb et al,

Naturally really keen to follow this and see if / when a fix would become available. Serious question (and sorry if I'm asking a silly question), is there somewhere else I should be watching for any great announcements regarding this? Really keen to use the mode 2 options with all the great enhancements that it provides. Many thanks for your help and advise.

Re: Analogue audio redux

Posted: Sun Jun 17, 2018 10:52 am
by theonlychriss
Hi jdb et al,

maybe my observations can contribute a bit more:
If the CPU is under fairly/heavy use, i.e. the higher the usage, the more the sound distortion occurs and the quicker the sound (and video application) stops working with a loud "plopp" until a reboot.
By high load, what I've noticed, I mean high computational usage (compiling stuff, image recognition e.g. via "motion" with a RPI-Cam) and/or high network load. It is easily reproducible.
I do not use multiplexed sound, at least not that I'm aware of it. There is only one application using the analog sound output at a time: Either it is Kodi, or a TV frontend, called "VDR".

I already bought a new RPi3 B+, because I thought my "old" RPi3 was slowly dying with this sound phenomenon as a symptom. Observing the very same behavior with the new one drove me crazy, until I finally found this post ...
If I can help anyhow, I'd be glad to support.

Cheers,
Chriss

Re: Analogue audio redux

Posted: Wed Jun 27, 2018 12:08 pm
by niwa3836
Hi all,
Wasnt sure whether this could / would get fixed by other code or whether jdb is the man who can. Either way just as a quick test today I did apt-get update, apt-get dist-upgrade and also rpi-update (I'm not sure which would normal contain that code) but can confirm the audio in mode 2 still remains sadly broken. I'm working on a large project that absolutely needs this and will have to make a decision soon as to whether to avoid 3B+ (with the need for new linux release) and try and source 3B (or alternative). Any suggests really welcome, hoping this great community can help.

Re: Analogue audio redux

Posted: Wed Jun 27, 2018 12:37 pm
by crofter
hi

3b is ok for audio it is 16 bit using raspian

crofter

Re: Analogue audio redux

Posted: Mon Jul 02, 2018 10:25 am
by niwa3836
Thanks re: 3B. Yes I have got a lot already running that code very happily. The problem is that its quite hard to find circa 6000 to 8000 i need as the 3B is in low supply. Hopefully the Raspberry PI community will be able to help soon.

Re: Analogue audio redux

Posted: Mon Jul 02, 2018 3:17 pm
by jdb
Reported elsehwere: https://github.com/raspberrypi/linux/issues/2587

There's a bug in the VC4 firmware that results in writes to memory past end-of-buffer limits when you get repeated DMA underruns.
There needs to be quite a lot of VPU activity to trigger this, particularly vector unit contention. The usual immediate symptom is the firmware crashing (audio playback stops, possibly with garbled output), with the possibility of crashing Linux as well.

Re: Analogue audio redux

Posted: Tue Jul 03, 2018 10:34 am
by niwa3836
Hi jdb, as always many thanks for your reply. I've added some notes to the github link that you sent in case it helps anyone else out. Hopefully the issue is becoming more well understood. Let me know if I can do anything, here to help.

Re: Analogue audio redux

Posted: Tue Jul 03, 2018 2:17 pm
by jdb
Can people experiencing issues with stalled playback please try the latest rpi-update firmware?

There is a potential fix for this issue and a fix for the GPU crashing when certain high-stress workloads are used in conjunction with PWM audio.

Re: Analogue audio redux

Posted: Wed Jul 04, 2018 7:44 am
by niwa3836
Hi all, Looks like the following thread show a fix now for this via rpi-update. Thanks to all those that have contributed!
https://github.com/raspberrypi/linux/issues/2587

Re: Analogue audio redux

Posted: Wed Jul 04, 2018 10:28 am
by jdb
It looks like tvjon's failing videos are also fixed with this update.

There is however a bit of a limitation with these VPU-heavy codecs (VP8 in particular) - the vector unit is being contended between doing the video decode and the audio resampling, so you get underruns if someone is exclusively using the vector unit for more than 10ms at a time.

This is going to be a bit tricky to work around without adding a lot of latency to the resampling pipe.

Re: Analogue audio redux

Posted: Wed Jul 11, 2018 7:12 am
by theonlychriss
I can also confirm that the new firmware (via rpi-update) is much more stable than before. At least in my use-case (watching TV via VDR/KODI) it did not crash anymore. Thanks a million to all contributors!
However, the sound is still sluggish - it seems as if it is hitting me what jdb is pointing out.
The codecs used are mpeg2 and h.264, though.
Before the update, h.264-material produced much more sound-distortions than mpeg2. Now it is quite even.

Please keep up the good work and further investigations how this can be fixed ;-)

Thank you so much!
Chriss

Analogue audio redux causes major audio problems

Posted: Thu Jan 24, 2019 7:40 pm
by peterbennett
I have been using Analog audio and analog video with an old analog TV set on a raspberry pi 2 for years and the sound has been perfect. I just upgraded from raspbian 2017-08-16 to 2018-10-09. Now the audio is full of loud crackles and pops, it is completely unlistenable. After some trial and error I found that setting audio_pwm_mode=1 fixes the problem. Setting audio_pwm_mode=2 or leaving it out causes the awful sound quality. I do not know if something is different about my setup.

I also tried it with an HDMI screen and extarnal speakers with analog audio and the result is the same, crackles and pops all the time.

I am happy to leave it set with audio_pwm_mode=1 and I hope that will continue to work. Let me know if there is anything I can try or if I can help you with more information.

Peter Bennett

Re: Analogue audio redux

Posted: Thu Jan 24, 2019 8:21 pm
by jdb
What are you playing over the analogue audio jack? What command are you using to start playback?

Re: Analogue audio redux

Posted: Thu Jan 24, 2019 10:11 pm
by HiassofT
We've had a couple of reports in LibreELEC that playing live TV results in audio crackling when audio_pwm_mode=2. See eg here: https://www.raspberrypi.org/forums/view ... 7#p1415724

I haven't checked that myself yet but I'm guessing deinterlacing, DRAM bandwitdh, GPU load or any combination of that could play a role in these issues.

so long,

Hias

Re: Analogue audio redux

Posted: Thu Jan 24, 2019 11:44 pm
by peterbennett
jdb wrote:
Thu Jan 24, 2019 8:21 pm
What are you playing over the analogue audio jack? What command are you using to start playback?
I am using MythTV frontend, playing an HD recording.
https://www.mythtv.org/wiki/Raspberry_Pi

It is using the GPU for openmax decoding and presentation of HD video at the time. Perhaps that is related to the problem. gpu memory is set to 256MB

Peter

Re: Analogue audio redux

Posted: Fri Jan 25, 2019 1:54 pm
by jdb
Is the content 1080i interlaced? If so, then adaptive deinterlace is probably being used.
Can you try setting the deinterlacer to "line double (hw)"?

Re: Analogue audio redux

Posted: Fri Jan 25, 2019 5:07 pm
by peterbennett
The recording is interlaced (1080i) and is using Advanced (HW) deinterlace. I changed it to Line Double(HW) and the result is the same, loud click and pops. Also I tried turning off deinterlace with the None option. In all cases the loud clicks and pops remain.

Some other tests -
720p video (h264) - plays better than 1080i, clicks and pops are fewer and softer but there still are clicks and pops.
480 video (mpeg2) - not sure if it is interlaced - audio is pefect - no clicks or pops - as good as with audio_pwm_mode=1

Re: Analogue audio redux

Posted: Wed Feb 20, 2019 7:49 pm
by ivar
Question - does this driver improve only the onboard microplug audio out, or does it improve sound quality for USB boards as well?

Re: Analogue audio redux

Posted: Thu Feb 21, 2019 8:41 pm
by jdb
The driver is specific to the onboard 3.5mm jack audio.

Re: Analogue audio redux

Posted: Thu May 09, 2019 11:21 am
by blackshard83
I revive this old thread with an edge case.
Here there is some code (and precompiled binary) that creates a pbuffer and uses vgGaussianBlur() to make some image manipulation using VC4. It does not render anything on screen, but running this while some audio is playing causes massive buffer underruns with audio_pwm_mode=2.

I tested this on an old raspberry pi 1 model B

Also I noticed that with sustained workloads (one or two video playing simultaneously + OpenVG graphics rendering at full framerate) , audio_pwm_mode=2 often hangs up the GPU so bad that a reboot is required.
Curiously when the GPU is hung, vhciq_test tests works (-f, -p) but calling eglCreateContext() causes the process to lock over a mutex.
I have some logs for this, but I don't know if they are useful

Any chances to get this fixed or simply revert to audio_pwm_mode=1?

PS: apparently my workload hangs the GPU even with audio_pwm_mode=1, but far less often.

edit: to compile the thing use

Code: Select all

cc -I /opt/vc/include -L /opt/vc/lib -l EGL -l GLESv2 -Og blur.c -o blur.bin