• 1
  • 100
  • 101
  • 102(current)
  • 103
  • 104
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
Updated my previous post with Video settings.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2013-11-27, 01:57)MilhouseVH Wrote: Updated my previous post with Video settings.

Okay, guess it's not that. Finding the first firmware that does it would be useful.

Some new commits on newclock3 (fix for all subs appearing at start, fix EDL commercial skip start time, and a couple more Ben Avison idle CPU reductions).
When I get around to identifying the specific firmware, do you want me to focus on next or master? And I guess the plan will be to roll through the firmware from the hexxeh repo, testing start.elf/fixup.dat starting from Nov 7th using the last known good image (02:51 on Nov 20)?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2013-11-27, 02:17)MilhouseVH Wrote: When I get around to identifying the specific firmware, do you want me to focus on next or master? And I guess the plan will be to roll through the firmware from the hexxeh repo, testing start.elf/fixup.dat starting from Nov 7th using the last known good image (02:51 on Nov 20)?

Yes. Notionally there was just one source code tree, and any commits to either master or next were just builds of the top of the source tree, so you should be able to bisect on date, ignoring which tree it came from.
But I'd focus on master and find the breaking commit, and only look at next if there were commits there between the two master commits.
This is great news. Looking forward to this fix making it into new Gotham builds. Thanks!

(2013-11-25, 16:55)popcornmix Wrote:
(2013-11-21, 19:59)popcornmix Wrote: Looks like just creating a file called <video>.edl with:
Code:
30.000 40.000 0
may skip from 30-40 seconds of any video file.....

Yes, that seems to work, and actually jumped from about 20s to 40s I believe, so I've got something to debug.

I've added this commit to newclock3 branch https://github.com/popcornmix/xbmc/commi...6f254f12f7
that makes my EDL test file skip at the right start point.
Quick update before I start attacking the firmware, I tried the "bad" firmware through my Onkyo 828 amp and got mixed results when playing back the BRFC_100 sample:

No passthrough (48KHz PCM shown by receiver), 2.0 Channels - result: "Chirping"
No passthrough (48KHz PCM shown by receiver), 5.1 Channels - result: "Clicking" (could just be a multi-channel variation of the "chirping" but now sounds more like a "click")
With Passthrough (DD5.1 shown by receiver), 5.1 Channels - result: Perfect audio
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
The above i(MilhouseVH) s consistent with my experience with DD audio. With other audio (AAC, MP3) I do get the chirping with passthrough.
Well at least it didn't take long to find the firmware! Smile

This was my process:

Started with the last known good build from 02:51 on Nov 20:
Code:
rpi512:~ # vcgencmd version && cd /flash && ls -la fixup.dat start.elf
Nov  7 2013 16:45:47
Copyright (c) 2012 Broadcom
version 8573b0747a17baf22e97e08254737a13d80430dd (clean) (release)
-rwxr-xr-x    1 root     root          8804 Nov 20 02:52 fixup.dat
-rwxr-xr-x    1 root     root       3482692 Nov 20 02:52 start.elf

Cloned the raspberrypi/firmware repo on the master branch and started with the first commit on 7 Nov, copying start_x.elf and fixup_x.dat to the Pi as start.elf/fixup.dat respectively.

First 7 Nov commit details:
Code:
bcm2835-driver.git$ git reset --hard 452637c34ceb3f3323e09b56c705f34bbe3a4594
HEAD is now at 452637c kernel: config: add missing PPP config options, MMC_SPI and DM_LOG_USERSPACE and crypto options

rpi512:~ # vcgencmd version && cd /flash && ls -la fixup.dat start.elf
Nov  7 2013 15:28:26
Copyright (c) 2012 Broadcom
version 7fc43cae4787c82b467d5707f48021b65cf3d44e (tainted) (release)
-rwxr-xr-x    1 root     root          8803 Nov 27 04:35 fixup.dat
-rwxr-xr-x    1 root     root       3482692 Nov 27 04:35 start.elf

Result: Audio OK

Second Nov 7 commit details - same as build (confirming my process is valid):
Code:
bcm2835-driver.git$ git reset --hard e85b566308a06952103fc3c70f46f3d13aac557b
HEAD is now at e85b566 firmware: rebuild with missing pause_burst_frames added

rpi512:/flash # vcgencmd version && cd /flash && ls -la fixup.dat start.elf
Nov  7 2013 16:45:47
Copyright (c) 2012 Broadcom
version 8573b0747a17baf22e97e08254737a13d80430dd (clean) (release)
-rwxr-xr-x    1 root     root          8804 Nov 27 04:40 fixup.dat
-rwxr-xr-x    1 root     root       3482692 Nov 27 04:40 start.elf

Result: Audio OK (as expected)

Nov 10 commit details (only commit that day):
Code:
bcm2835-driver.git$ git reset --hard 18a163f9341755b00841312af2878afeb64c131c
HEAD is now at 18a163f userland: Add support for mmal camera to texture conversion and support this in raspicam apps

rpi512:~ # vcgencmd version && cd /flash && ls -la fixup.dat start.elf
Nov 10 2013 16:16:10
Copyright (c) 2012 Broadcom
version 96ec677b68916c87fac224a45994ad5a4da819d5 (tainted) (release)
-rwxr-xr-x    1 root     root          8804 Nov 27 04:42 fixup.dat
-rwxr-xr-x    1 root     root       3483844 Nov 27 04:42 start.elf

Result: *CHIRPING* ding ding ding we have a winner! Smile

I've gone back and forth several times now between e85b566 (last commit on 7 Nov) and 18a163f (10 Nov) and only getting "chirping" with 18a163f. It appears this commit resolves several problems, not sure which one might be the underlying cause of the audio glitches (which seem to be PCM related).

Edit: One of the fixes in 18a163f appears to be network related, so I just wanted to add that I've reproduced chirping when streaming from NFS, SMB, and also direct from USB.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
I tried the 10 Nov firmware with the following options added to config.txt:
Code:
pause_burst_frames=0
num_stream_blocks=0x311111
but still heard chirping.

I also added pause_burst_frames=1 to config.txt with the "known good" 7 Nov firmware (e85b566308a06952103fc3c70f46f3d13aac557b), and heard no chirping (there was one, single, solitary "chirp", but it took several attempts at playing BRFC_100 to hear it, and may have been a one-off so possibly not related).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
With the last build that was done onthe thread I updated my firmware for the first time and also got the chirping.

But I just installed an older xbmc version an left the firmware as is. No more chirping. Will go and do more tests
tonight to confirm, but don't understand why I am getting different results.
(2013-11-27, 10:03)rterblanche Wrote: With the last build that was done onthe thread I updated my firmware for the first time and also got the chirping.

But I just installed an older xbmc version an left the firmware as is. No more chirping. Will go and do more tests
tonight to confirm, but don't understand why I am getting different results.

I just tested this theory, and still get chirping.

I put the latest 24 Nov build on my system, tested it and confirmed bad chirping.

I popped the SYSTEM and kernel.img from the "known good" 20 Nov 02:51 build directly into the root of the SD card (so keeping the 24 Nov firmware), rebooted, and still heard chirping. The chirping *was* less pronounced (less frequent) than with the entirely 24 Nov build - which is strange - but it was still present.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2013-11-27, 07:06)MilhouseVH Wrote: I've gone back and forth several times now between e85b566 (last commit on 7 Nov) and 18a163f (10 Nov) and only getting "chirping" with 18a163f. It appears this commit resolves several problems, not sure which one might be the underlying cause of the audio glitches (which seem to be PCM related).

Thanks for searching. There's one change with a config option you can test. Add this to config.txt (with "chirping" firmware)
Code:
hdmi_dma_waits=7
Any different?

If not I may have to produce a few test builds to narrow it down further.
(2013-11-27, 13:50)popcornmix Wrote: Thanks for searching. There's one change with a config option you can test. Add this to config.txt (with "chirping" firmware)
Code:
hdmi_dma_waits=7
Any different?

If not I may have to produce a few test builds to narrow it down further.

Sorry for the delay. I added the above setting to config.txt, but it made no difference - still chirping.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2013-11-27, 22:14)MilhouseVH Wrote: Sorry for the delay. I added the above setting to config.txt, but it made no difference - still chirping.

Okay, here are test builds of commits between the good and bad builds:

https://dl.dropboxusercontent.com/u/3669...431286.elf
https://dl.dropboxusercontent.com/u/3669...431587.elf
https://dl.dropboxusercontent.com/u/3669...431592.elf
https://dl.dropboxusercontent.com/u/3669...431595.elf
https://dl.dropboxusercontent.com/u/3669...431597.elf
https://dl.dropboxusercontent.com/u/3669...431600.elf

if I understand things correctly, 431286 should be good. 431600 should be bad. Somewhere in between in the bad commit.

Note these are test builds with a fixed memory split (256M/256M). You should move current fixup.dat out of the way.
The results are in... working top to bottom through your start.elf files:
Code:
20 Nov 02:51 Build: No chirping
start_431286.elf  : No chirping
start_431587.elf  : No chirping
start_431592.elf  : No chirping
start_431595.elf  : ** CHIRPING **
start_431597.elf  : ** CHIRPING **
start_431600.elf  : ** CHIRPING **

I've repeated the testing twice, and chirping kicked in both times with 431595.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
  • 1
  • 100
  • 101
  • 102(current)
  • 103
  • 104
  • 277

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 223