[DEV] LineageOS 20 (Android 13) for Raspberry Pi 4 B

[werimail]

Here the Logcat...
Greetings Werimail

[Konsta]

@werimail
Thanks for the logs.

I don't see anything wrong with the audio in that log. Yes, I can reproduce these errors if I select audio to HDMI1 while only having display connected in HDMI0 (or vice versa or running headless without any display connected).

Code: Select all

I audio_hw_rpi_hdmi: start_output_stream: default:CARD=vc4hdmi1
E audio_hw_rpi_hdmi: cannot open pcm_out driver: Operation not permitted
E audio_hw_rpi_hdmi: out_write err: No such device

I guess this could cause some slowing down since whenever sound is played, audio HAL tries to constantly open a device that is not available. Easy solution would be simply not to set HDMI audio to a port where you don't have any display connected.

My builds currently have four different H.264 decoders (V4L2 hardware decoder using AOSP v4l2_codec2, V4L2 hardware decoder using FFmpeg h264_v4l2m2m, FFmpeg's software decoder, and Android's native software decoder). Logs indicate that both hardware decoders have some issue with the H.264 buffers with that app (pixel format, buffer size).

Code: Select all

03-30 13:45:12.307   245  3339 E V4L2Device: (CAPTURE_MPLANE)Failed to set format (format_fourcc=0x3231564e)
03-30 13:45:12.307   245  3339 E V4L2Decoder: Failed to find supported pixel format
03-30 13:45:12.307   245  3339 I V4L2Decoder: Set state Decoding => Error
03-30 13:45:12.307   245  3339 E V4L2DecodeComponent: reportError(error=14)
03-30 13:45:12.307  2774  3330 D CCodec  : Component "c2.v4l2.avc.decoder" returned error: 0xe

Code: Select all

03-30 13:28:42.672   248  3074 I FFMPEG  : [h264_v4l2m2m @ 0xb400007d21106290] --- capture VIDIOC_QBUF: index 0 FAIL err 22 (Invalid argument)
01-01 01:02:19.459     0     0 E         : bcm2835-codec bcm2835-codec: bcm2835_codec_buf_prepare data will not fit into plane (55296 < 884736)

[werimail]

@werimail
Thanks for the logs.

I don't see anything wrong with the audio in that log. Yes, I can reproduce these errors if I select audio to HDMI1 while only having display connected in HDMI0 (or vice versa or running headless without any display connected).

Code: Select all

I audio_hw_rpi_hdmi: start_output_stream: default:CARD=vc4hdmi1
E audio_hw_rpi_hdmi: cannot open pcm_out driver: Operation not permitted
E audio_hw_rpi_hdmi: out_write err: No such device

I guess this could cause some slowing down since whenever sound is played, audio HAL tries to constantly open a device that is not available. Easy solution would be simply not to set HDMI audio to a port where you don't have any display connected.

Hi @Konsta, thanks for your analysis. I now believe that it is no longer an audio problem. I frequently get the logcat error:

Code: Select all

[31m03-31 11:23:20.032   417   533 E WifiVendorHal: getWifiLinkLayerStats_1_6_Internal(l.1199) failed {.code = ERROR_NOT_SUPPORTED, .description = }[0m
[32m03-31 11:23:23.046   248   248 I WifiHAL : Creating message to get link statistics; iface = 8[0m
[34m03-31 11:23:23.047   248   248 D WifiHAL : error code -95 mapped to -3[0m

That sounds more like a network failure, doesn't it?
Greetings Werimail

[Konsta]

Hi @Konsta, thanks for your analysis. I now believe that it is no longer an audio problem. I frequently get the logcat error:

Code: Select all

[31m03-31 11:23:20.032   417   533 E WifiVendorHal: getWifiLinkLayerStats_1_6_Internal(l.1199) failed {.code = ERROR_NOT_SUPPORTED, .description = }[0m
[32m03-31 11:23:23.046   248   248 I WifiHAL : Creating message to get link statistics; iface = 8[0m
[34m03-31 11:23:23.047   248   248 D WifiHAL : error code -95 mapped to -3[0m

That sounds more like a network failure, doesn't it?
Greetings Werimail

No, not everything you see in the logs tagged as "error" is an actual error or cause any issue. Broadcom wifi vendor HAL doesn't implement link layer stats (at least yet) and those messages have been present in the logs for past couple of Android version at least. This has been discussed https://github.com/raspberry-vanilla/an ... /issues/12

It's most definitely something related to audio if you can reproduce this by just switching audio output device between 3.5mm jack and HDMI. As I already commented above, I can see this being a problem if you've selected HDMI audio output to a port where you don't have any display connected. Are you sure this isn't the case?

[werimail]

Yes @Konsta, I currently only use the Raspi on a Samsung LED TV. The audio output via HDMI also works without problems (the sound is clear). Only the video is jerky and stuttering throughout. Even a restart hasn't helped so far. Does the latest logcat show anything along those lines?
Greetings Werimail

[Konsta]

Yes @Konsta, I currently only use the Raspi on a Samsung LED TV. The audio output via HDMI also works without problems (the sound is clear). Only the video is jerky and stuttering throughout. Even a restart hasn't helped so far. Does the latest logcat show anything along those lines?
Greetings Werimail

And if you change the audio output to 3.5mm jack (and reboot the device) there is no longer any video stuttering?

[werimail]

Yes @Konsta, I currently only use the Raspi on a Samsung LED TV. The audio output via HDMI also works without problems (the sound is clear). Only the video is jerky and stuttering throughout. Even a restart hasn't helped so far. Does the latest logcat show anything along those lines?
Greetings Werimail

And if you change the audio output to 3.5mm jack (and reboot the device) there is no longer any video stuttering?

Yes, that's how it is @Konsta, as soon as I switch to "3.5mm Jack" the video runs without jerking and stuttering (but also without any sound )
Greetings Werimail

[Konsta]

Yes, that's how it is @Konsta, as soon as I switch to "3.5mm Jack" the video runs without jerking and stuttering (but also without any sound )
Greetings Werimail

Ok. I can't reproduce that, I haven't received any other reports either, and I can't see anything in the logs that would indicate such issue.

Could be related to the fact that you've switched to H.264 software decoding (you could also test the Android's native sw decoder vs. FFmpeg sw decoder) and the IEC958 subframe conversion for HDMI audio being on the CPU, too. You could try if overclocking the CPU helps, at least increase the clocks to 1.8GHz that should be the default for Pi 400 in the first place.

[werimail]

Yes, that's how it is @Konsta, as soon as I switch to "3.5mm Jack" the video runs without jerking and stuttering (but also without any sound )
Greetings Werimail

Ok. I can't reproduce that, I haven't received any other reports either, and I can't see anything in the logs that would indicate such issue.

Could be related to the fact that you've switched to H.264 software decoding (you could also test the Android's native sw decoder vs. FFmpeg sw decoder) and the IEC958 subframe conversion for HDMI audio being on the CPU, too. You could try if overclocking the CPU helps, at least increase the clocks to 1.8GHz that should be the default for Pi 400 in the first place.

Hello @Konsta Unfortunately, using Android's native sw decoder and overclocking the CPU (frequency = 1800 MHz) did not have any effect. The video is still stuttering and jerking. Merely changing the audio device ("3.5mm Jack" setting) leads to the desired result, but no audio output. Apparently the changes to the HDMI audio output since the last version from 03/21/2023 are to blame, since there have never been any problems with the HDMI audio with my configuration to date.
At the moment I only see one solution for me: I stay with the version from 02/14/2023 without implement audio HAL or there is an option to switch back to alsa loopback for HDMI audio.
Greetings Werimail

[Konsta]

New builds.

https://konstakang.com/devices/rpi4/LineageOS20/
https://konstakang.com/devices/rpi4/LineageOS20-ATV/

-add support for AV1 software video decoding using FFmpeg and dav1d
-update to FFmpeg 6.0
-update to libcamera master/v0.0.5
-update to alsa-lib/alsa-utils v1.2.9
-update to Mesa 23.0.3
-update to Linux 5.15.106 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
-Android security patch level: 5 May 2023 (merged)

[ArSm]

Hi,

is there any way that LineageOS RP4 is detecting a USB DAC? I´ve already tried a lot of things, but in the meantime I have reached a dead end.

Thanks for your help!

ArSm

[Konsta]

Hi,

is there any way that LineageOS RP4 is detecting a USB DAC? I´ve already tried a lot of things, but in the meantime I have reached a dead end.

Thanks for your help!

ArSm

USB soundcards/DACs should work by simply pluggin in the hardware. There's been some reports of issues with some USB DACs since Android 12 but I'm not able to reproduce any issue with my USB soundcard at least. Please post appropriate logs ('dmesg', 'logcat', 'cat /proc/asound/cards') if you're having issues with this.

[ArSm]

Hi Konsta!
Thank you so much for your help! I appreciate it very much. In the meantime, my USB DAC is up and running. Now a new problem has arisen. When playing audio, whether playing video or audio only, there is a crackling sound. When the playback is finished, nothing more can be heard. What could this be related to?

[Konsta]

Hi Konsta!
Thank you so much for your help! I appreciate it very much. In the meantime, my USB DAC is up and running. Now a new problem has arisen. When playing audio, whether playing video or audio only, there is a crackling sound. When the playback is finished, nothing more can be heard. What could this be related to?

No idea, TBH. I doubt there's any quick/easy solution on the software side at least. My builds use the generic AOSP USB audio HAL for the USB audio so there's nothing Raspberry Pi specific there.