[AppleTV] CrystalHD Driver for XBMC Launcher

  Thread Rating:
  • 3 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
« Next Oldest | Next Newest»
davilla Offline
Team-XBMC Developer
 Posts: 10,505
Joined: Feb 2008
Reputation: 58
2011-06-19 03:21 Post: #361
8 buffers or 16, that's the main difference.

On osx, specially the atv1, 8 seems to be better as it does not put pressure on the amount of physical ram used. The buffer are phy allocated.

MediaInfo : http://mediainfo.sourceforge.net/
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
find quote
plugh Offline
Senior Member
 Posts: 281
Joined: Feb 2006
Reputation: 2
2011-06-19 08:12 Post: #362
I'm aware of that difference, Scott. That's not the point of my post.

I'll try again. Let's look at the definition of the Pause / Resume values.

First Linux:

include/ bc_dts_glob_lnx.h
Code:
BC_RX_LIST_CNT          = 16,           /* Max Rx DMA Rings*/

linux_lib/ libcrystalhd/ libcrystalhd_priv.h
Code:
PAUSE_DECODER_THRESHOLD = ((BC_RX_LIST_CNT * 10) / 16), /* 12 for 16 buffers, 6 for 8 buffers */  
        RESUME_DECODER_THRESHOLD = ((BC_RX_LIST_CNT * 3) / 16),  
        FLEA_RT_PD_THRESHOLD = ((BC_RX_LIST_CNT * 14) / 16), /* 14 for 16 buffers, 7 for 8 buffers */  
        FLEA_RT_PU_THRESHOLD = ((BC_RX_LIST_CNT * 3) / 16),

when BC_RX_LIST_CNT equals 16
PAUSE_DECODER_THRESHOLD calcs to 10
RESUME_DECODER_THRESHOLD calcs to 3


Now let's look at OSX

include/ bc_dts_glob_osx.h
Code:
#ifndef __APPLE__  
BC_RX_LIST_CNT = 16, /* Max Rx DMA Rings*/  
#else  
BC_RX_LIST_CNT = 8, /* Max Rx DMA Rings*/  
#endif

darwin_lib/ libcrystalhd/ libcrystalhd_priv.h
Code:
PAUSE_DECODER_THRESHOLD = ((BC_RX_LIST_CNT * 12) / 16), /* 12 for 16 buffers, 6 for 8 buffers */
        RESUME_DECODER_THRESHOLD = 3,  
        FLEA_RT_PD_THRESHOLD = ((BC_RX_LIST_CNT * 14) / 16), /* 14 for 16 buffers, 7 for 8 buffers */  
        FLEA_RT_PU_THRESHOLD = 3,

when BC_RX_LIST_CNT equals 16
PAUSE_DECODER_THRESHOLD calcs to 12

when BC_RX_LIST_CNT equals 8
PAUSE_DECODER_THRESHOLD calcs to 6

and (unlike the Linux case)
RESUME_DECODER_THRESHOLD always equals 3


So, the last point in my previous post was - this looks odd to me.

Is there some reason why (when using 16 buffers) 'Pause Threshold' is 10 on Linux and 12 on OSX?
Is there some reason why 'Resume Threshold' is a constant 3 on OSX but a varying value on Linux?

Or perhaps these are simply some 'oops' that have crept in ??

(I'm not looking for an answer - I'm simply pointing these 'odd' things out)


Continuing on: Let's look at the use of the Pause / Resume values.

The Linux code:

linux_lib/ libcrystalhd/ libcrystalhd_if.cpp
Code:
#include "bc_dts_glob_[b]lnx[/b].h"
Code:
    // For LINK Pause HW if the RLL is too full. Prevent overflows
    // Hard coded values for now
    if(Ctx->DevId == BC_PCI_DEVID_LINK) {
        if(pStatus->ReadyListCount > PAUSE_DECODER_THRESHOLD && !Ctx->hw_paused && !Ctx->fw_cmd_issued) {
            DtsFWPauseVideo(hDevice,eC011_PAUSE_MODE_ON);
            Ctx->hw_paused = true;
        }
        else if (pStatus->ReadyListCount < RESUME_DECODER_THRESHOLD && Ctx->hw_paused && !Ctx->fw_cmd_issued) {
            DtsFWPauseVideo(hDevice,eC011_PAUSE_MODE_OFF);
            Ctx->hw_paused = false;         }
    }
The OSX code:

darwin_lib/ libcrystalhd/ libcrystalhd_if.cpp
Code:
#ifdef __APPLE__
#include "bc_dts_glob_osx.h"
#else
#include "bc_dts_glob_lnx.h"
#endif
Code:
    // For LINK Pause HW if the RLL is too full. Prevent overflows
    // Hard coded values for now
    if(Ctx->DevId == BC_PCI_DEVID_LINK) {
        if(pStatus->ReadyListCount > PAUSE_DECODER_THRESHOLD && !Ctx->hw_paused && !Ctx->fw_cmd_issued) {
            DtsFWPauseVideo(hDevice,eC011_PAUSE_MODE_ON);
            Ctx->hw_paused = true;
        }
        else if (pStatus->ReadyListCount < RESUME_DECODER_THRESHOLD && Ctx->hw_paused && !Ctx->fw_cmd_issued) {
            DtsFWPauseVideo(hDevice,eC011_PAUSE_MODE_OFF);
            Ctx->hw_paused = false;         }
    }

The Linux code always pulls in the Linux headers, but
the OSX code conditionally uses the Linux or OSX headers.

When building the darwin code (but 'not __apple__') it uses the Linux flavor
buffers, pause, and resume parameters (among various others)...

Again - something that looks odd to me, that I thought perhaps worth pointing out.


Continuing on: Let's look at the history of the Pause / Resume values.
(no more code extracts - y'all can walk through code and headers to verify it)

before r151, osx used 16 buffers, 10 Pause thresh, and 6 Resume thresh
with r151, osx used 8 buffers, 10 Pause thresh, and 6 Resume thresh (bug)
with r161, osx used 8 buffers, 7 Pause thresh, and 3 Resume Thresh
with r172, osx used 8 buffers, 6 Pause thresh, and 3 Resume Thresh

This means that the R156 OSX driver has a definite bug. But R159 introduced a BUNCH of changes (BCM70015 support?) that anecdotally resulted in a less stable OSX driver for BCM70012 users (see posts on preceding page)...

It might be interesting if someone could rebuild r157 (aka 3.6.0 tag) with the two edits adjusting the (back then, hard-coded) pause and resume thresholds from 10 / 6 to say 6 / 3 ? THAT would be a useful driver for users to test/evaluate against the R174 build.
find quote
davilla Offline
Team-XBMC Developer
 Posts: 10,505
Joined: Feb 2008
Reputation: 58
2011-06-19 18:58 Post: #363
1st, __APPLE__ is a compiler defined flag, you can't turn it off when using the gcc compiler under darwin. So all code that ifdefs things using __APPLE__ will choose __APPLE__ if compiled on osx.

2nd, the linux code is straight linux, the osx is linux+darwin, so you will find __APPLE__ defs where code is needed/removed to support darwin. It's my way of making clear which code was added/removed to support darwin. In theory, one could compile the osx branch under linux and get linux. My hope was to push these changes upstream but since the driver is now in the linux kernel tree, this will never happen. They don't like to see #ifdefs supporting other os'es in kernel source.

r151, osx with 8 buffers, 10 Pause thresh, and 6 Resume thresh is defiantly a bug, it will never hit the pause threshold and potentially overrun. That's why it was fixed in a subsequent version.

There are differences in behavior between the bcm70012 and bcm70015. The bcm70015 is much, much faster in responding to changes and initial decode startup.

There might be lingering bugs in the code, I've also not sync'ed to upstream's last push yet.

The driver/libs are quite easy to compile under osx's xcode.

MediaInfo : http://mediainfo.sourceforge.net/
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
find quote
interceptor121 Offline
Fan
 Posts: 507
Joined: Feb 2009
Reputation: 1
2011-06-19 19:57 Post: #364
I was one of the first users of a BCM70012 right after the initial 1.0.1 driver
I have recently bought a BCM70015 and since I have it I essentially don't switch on the ATV with Ubuntu for 720p. With few exceptions all works well and it is worth not messing around with the USB stick
Ubuntu remains mandatory for 1080p but I personally don't have nearly any file like that in my library...
find quote
plugh Offline
Senior Member
 Posts: 281
Joined: Feb 2006
Reputation: 2
2011-06-21 04:29 Post: #365
davilla Wrote:The driver/libs are quite easy to compile under osx's xcode.
As the only Apple product in my house is the AppleTV, rebuilding it myself is not an option.

So I took a differant tack...

To fix 8 DMA buffer pause/resume bug consistent with R172 limits of 6 / 3 :

Using the 3.6.0 osx driver build, patch two locations in libcrystalhd.dylib with a hex editor

Code:
56D0: 3C0A    CMP AL,10
        JBE ...
5748: 3C05    CMP AL,05
        JA ...

Using the 2.0.1 osx driver build, patch two locations in libcrystalhd.dylib with a hex editor

Code:
5F24: 3C0A    CMP AL,10
        JBE ...
5F75: 3C05    CMP AL,05
        JA ...
replace '0A' with '06', and '05' with '02'
find quote
JeffElkins Offline
Member
 Posts: 99
Joined: May 2008
Reputation: 0
2011-06-25 17:02 Post: #366
interceptor121 Wrote:Ubuntu remains mandatory for 1080p but I personally don't have nearly any file like that in my library...

Noob atv1 user. With 3.0.2/Dharma and r174 playback is choppy using my "test" movie, BBC's Earth @ 1080p, but pretty good with my other 1080p movies. Resolution is fixed at 1080x720. So the ATV is only 1080p decode/720p playback with the CrystalHD?
find quote
davilla Offline
Team-XBMC Developer
 Posts: 10,505
Joined: Feb 2008
Reputation: 58
2011-06-25 18:05 Post: #367
JeffElkins Wrote:Noob atv1 user. With 3.0.2/Dharma and r174 playback is choppy using my "test" movie, BBC's Earth @ 1080p, but pretty good with my other 1080p movies. Resolution is fixed at 1080x720. So the ATV is only 1080p decode/720p playback with the CrystalHD?

Don't even try with killa Smile You can search for why.

MediaInfo : http://mediainfo.sourceforge.net/
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
find quote
JeffElkins Offline
Member
 Posts: 99
Joined: May 2008
Reputation: 0
2011-06-25 18:41 Post: #368
davilla Wrote:Don't even try with killa Smile You can search for why.

Got it, 16 vs 10, thanks Smile. Still, is the atv with os x limited to 1080p decode/720p display?
(This post was last modified: 2011-06-25 18:45 by JeffElkins.)
find quote
davilla Offline
Team-XBMC Developer
 Posts: 10,505
Joined: Feb 2008
Reputation: 58
2011-06-26 03:07 Post: #369
JeffElkins Wrote:Got it, 16 vs 10, thanks Smile. Still, is the atv with os x limited to 1080p decode/720p display?

yes and that going to be forever.

MediaInfo : http://mediainfo.sourceforge.net/
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
find quote
JeffElkins Offline
Member
 Posts: 99
Joined: May 2008
Reputation: 0
2011-06-26 03:11 Post: #370
davilla Wrote:yes and that going to be forever.

Silly Apple. I'm glad set up ubuntu then. Thanks for the assistance. I'm also really enjoying my atv2 with XBMC, so thanks for that too!
find quote
Post Reply
Contact Us | XBMC Home | Return to Top | Return to Content | Lite (Archive) Mode | RSS Syndication