• 1
  • 23
  • 24
  • 25(current)
  • 26
  • 27
  • 30
[AppleTV] CrystalHD Driver for XBMC Launcher
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.
Reply
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.
Reply
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.
Reply
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...
Reply
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'
Reply
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?
Reply
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.
Reply
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?
Reply
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.
Reply
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!
Reply
CrystalHD-for-OSX project hasn't been updated since October 2010 which is a version 174 that I currently run on my ATV1 (new abbreviation) with a well-known memory leak problem that requires hard rebooting ATV1 after watching a few HD movies. Since there is a new favorite ATV2 I take it the CrystalHD project will be on standby forever with no hope for improvements. Can anyone confirm that?
Backend: Windows 7 file share + MySql on wired 1GB
Frontend 1: ATV OSX 3.02 w/CHD 012 + XBMC Dharma 10.0 + CHD r174 on wired FE
Frontend 2: Intel Atom 330/2Gb/ATI HD4350 + Windows 7 + XBMC Dharma 10.0 with DXVA + MySql DB on wired 1GB
Reply
hi im running windows xp on my computer and using a apple tv v1 as a media player so im not use at all with mac environement or linux how can i install the driver on my apple tv i bean searching but cant find a guide that i understand thx
Reply
nanuk Wrote:hi im running windows xp on my computer and using a apple tv v1 as a media player so im not use at all with mac environement or linux how can i install the driver on my apple tv i bean searching but cant find a guide that i understand thx

Just download Putty ( http://www.chiark.greenend.org.uk/~sgtat...nload.html )

In Putty type in:

Press return

It will ask you for a password. Type
Code:
frontrow

Press return

type in:

Code:
defaults write com.teamxbmc.xbmclauncher XBMCAdditionalDownloadPlistURLs -array-add http://crystalhd.sartori.at/files/crystalhd.plist

Press return

You're done. I can't remember if you need to reboot the ATV1 to see the change, but if you don't see a CrystalHD option in the download section of "Launcher" then just unplug and replug the ATV1 to reboot. Go back to Launcher and select downloads and select the CrystalHD option.
Reply
MaestroDD Wrote:Thanks for the update, andy204!

Once this is tested by a few users, we'll integrate it into Launcher.

Has this happened or going to happen anytime soon?
Reply
gilbreen Wrote:Probably not proper forum etiquette to answer my own posting but I did the outlined steps in my previous post following intercepter121's recommendation to use the r156 driver and everything is working great. Now on to install the two remaining 70015 cards in my two other ATV boxes.

Thanks to the devs and the everyone's postings that has made my ATV with XBMC an even more awesome device!

Gilbreen, where you able to get your 70015 card w/ r174 driver working on Eden Beta 3?

-ATV420:confused2:
Reply
  • 1
  • 23
  • 24
  • 25(current)
  • 26
  • 27
  • 30

Logout Mark Read Team Forum Stats Members Help
[AppleTV] CrystalHD Driver for XBMC Launcher3