For the stuttering reports there is a fix. Either wait for the next LE update or grab firmware from here:
rename and replace http://start.elf/fixup.dat on the FAT partition of sdcard.
For the stuttering reports there is a fix. Either wait for the next LE update or grab firmware from here:
rename and replace http://start.elf/fixup.dat on the FAT partition of sdcard.
Anyway - the new Raspi has potential to solve one of my problems. My TV has one 4K HDMI input, but my reciever is 1080P only. Unfortunatly the TV will only send stereo back down the ARC if the source is external. So I need a way of getting passthrough audio to the reciever.
Will it be possible to use the second HDMI to output the audio (with or without 1080P or lower video) while sending the full 4K video to the TV on the other HDMI?
I think this is possible from a hardware perspective.
We'll need a way for kodi to choose a different hdmi port for the audio
(possibly a different Sink, or maybe just a config option).
Don't hold your breath - there are more important things to support first,
but it's something I'll bear in mind.
Okay. You are on a Pi2, right? The commit I reverted should affect Pi3 behaviour rather than Pi2.
But, assuming you are still happy with the last test firmware can you try:
https://drive.google.com/uc?id=1ag88d56gimdzu7sxnc191hirepmgcnf8&export=download
This only partially reverts the commit to try to narrow it down. Let us know if you are happy or not with this version.
vamp. Okay, that's a little surprising. I've built a top of tree firmware with the commit we suspect reverted. Can you test it?
https://drive.google.com/uc?id=1flqknowjd6tpr1yrpc2dh8cghktjbzaq&export=download
Extract start.elf and fixup.dat and replace the ones on the boot partition of your sdcard.
(Using a build that is currently showing the problem). Let us know if the problem still occurs.
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?