vamp could you test the latest Milhouse nightly build?
The firmware you identified had an increase to the i2c clock frequency used for setting chip voltages
which we found caused problems on some boards, and more recent firmware has reverted this change.
Sure, alsamixer does not work. But what about amixer? Shouldnt that work?
amixer: "allows command-line control of the mixer for the ALSA soundcard driver"
It won't affect kodi which doesn't use ALSA for hdmi or analogue audio.
Ignore alsa mixer. Kodi doesn't use alsa for audio (it uses openmax).
Volume on analogue does work, so it's possible you have custom settings that are affecting it. A debug log may be useful.
But to start with I'd suggest using the "reset settings to default" option in the system/audio settings page, and just change the output device to analogue.
If that doesn't work then renaming /storage/.kodi to /storage/.kodi_back and restarting kodi will start from completely clean settings.
You can then set audio output to analogue and see if it's any different. If not you can rename back to .kodi to get back to your original settings.
There is an dtparam that can control led behaviour - see https://github.com/raspberrypi/firmware/blob/master/boot/overlays/readme#l96
It was added March 21, so required a kernel newer than that date.
Yes, as smp says, try removing "arm_freq=1200" and try adding "over_voltage=2"
Is that stable?
Does adding arm_freq=1200 to config.txt make any difference?
popcornmix a provisional 8.2.5 image with the updated http://startup.elf/fixup.dat files seems to work fine (at leas it boots, which is the main thing).
This firmware has been pushed to raspberrypi/firmware repo.
deancan your issue doesn't seem related to the analogue audio issue reported.
Please create a new thread and include some information if you want help (e.g. a debug log).
MikeBuzz Can you test this firmware? Latest firmware with emmc clock change just reverted for external emmc platforms.
Could you test with this firmware: uc?id=1pwZSRw4BuoWYixZHKuhE42lypraa-eG6&export=download
It reverts a change to the EMMC clock which could be to blame.
Extract start_x.elf/fixup_x.dat, rename to http://start.elf/fixup.dat and replace the existing ones on slice.
Yes, audio_pwm_mode=0 fixed the noise issue for me.
Can you remove that line and try disabling deinterlace?
Does that help? If it does, then does switching to Bob deinterlace help?
The audio_pwm_mode will only affect analogue audio (as in original post in this thread).
Other audio issues are probably unrelated.
Can you try "audio_pwm_mode=0" in config.txt?
Can you try adding audio_pwm_mode=2 to config.txt and reboot? Any different?
MikeBuzz can you try firmware from March 5th:
Start with a working 8.2.3 image and download the two files. Rename to start.elf / fixup.dat and replace your current ones.
That is the newest firmware that predates the frequency/voltage/temp rework so should narrow the problem down.
I suspect it is not just being busy that causes the packet loss, but something that holds off the USB interrupts (cache flushing was guessed at in the github issue which Nodejs does for jit).
It's probably worth posting on USB DAC dropouts/glitches · Issue #2215 · raspberrypi/linux · GitHub
The USB expert (P33M) may be able to suggest something.
Report with output of "lsusb -v"
Can you confirm if the occasional pop you hear on raspbian kodi is resolved with dwc_otg.speed = 1?
Could you also test this build: DVB issue since LE switched to kernel 4.9.x
There is just a chance the issue that causes USB DVB glitches could also be causing USB audio glitches.
