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.