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.
@jahutchi thank you!
While we would still like a real solution (ideally upstream kernel devs acknowledging the issue introduced and finding a solution), identifying the commit that caused the regression makes this far more likely.
And it allows people affected to run a build much closer to the official one - running the 4.8 kernel was never going to be a solution that would work indefinitely.
Good work!
Can you reproduce issue using raspbian? e.g. using aplay or something simpler than kodi?
It may be the same issue as USB DAC dropouts/glitches · Issue #2215 · raspberrypi/linux · GitHub
Having a simple use case that shows the problem would be helpful, especially if it didn't occur with an older kernel (was OE 7.0.1 using 4.4 kernel?)
Posting output of "dmesg" when the drive goes may be helpful.
An insufficient power supply may be to blame.
Do you ever see warning symbols in top/right of screen (temperature/power symbols)?
Can you post output of dmsg after the failure?
Do you still see the failures when PVR is disabled?
the problem is between rev1 and rev2 are a huuuuuuuughe number of commits so its is pretty useless to to recompile if you can't do it by your self (maybe ~50 builds are needed to get close to the problem)
You are vastly over-estimating the number of tests needed in a bisect.
50 builds would allow for identifying a single commit in ~1000000000000000 commits (2^50).
Around 9 builds are actually needed for bisecting the ~343 commits in the "Here is the big USB, and PHY, and extcon, patchsets for 4.9-rc1" merge that is believed to contain the regression.
Bisecting the kernel will be a lot easier on x86 where the upstream kernel can be used untouched.
Bisecting kernel on Pi across the 4.8/4.9 boundary would need serious git skills due to the downstream patches changing.
I wonder if this issue is related:
Basically USB packets were getting dropped on 4.9 kernel and not on 4.4 kernel.
Interesting this bug has just been fixed upstream (this commit).
There was an overflow error in setting timer callbacks which may result in incoming packets not being serviced.
smp I wonder if you could try a recent 4.9 kernel that includes that commit.
Are you able to test a Milhouse nightly build?
That has a change to 3d subs that may help. Would be useful to know.
I don't believe so. If gui is duplicated for 3D then so will subs.
