[mythtv] [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T).
Manu Abraham
abraham.manu at gmail.com
Thu Mar 16 16:35:18 UTC 2006
Daniel Kristjansson wrote:
> Yup, the averaging is in my long term todo, it just doesn't have a
> terribly high priority because it doesn't serve any purpose in MythTV
> yet. Many cards don't even report these values.
>
You are right, we are looking at this aspect, but this involves some
changes like getting math operations into kernel/moving frontend drivers
out to userspace. We have some thoughts on this, but don't bet on it,
since there are quite some issues to be considered.
And when this is done, in most cases you wouldn't have to do the
averaging, the driver will do the averaging according to the specs from
the chipset vendor.
Another one of the reasons why drivers are in such a state is that many
drivers are Reverse Engineered , since vendors don't release
specifications / information on them. But for some of them due to
certain reasons some things cannot be implemented in kernel as it is.
We are looking at userspace libraries to fix issues like this, so that
all such information like this can be contained in them such that
applications do not have to be bothered by issues like this. It will
not be too long for them.
> I don't recall any patch from him for this issue. I've only been
> maintaining the DVB stuff for a few months so it may have been
> before I started tracking DVB patches. There was a period after
> Taylor Jacob ran out of time and before I picked it up, if it was
> sent during that period it would have fallen into a black hole.
>
>
Hmm.. I was talking to Ralph Metzler, he told me that Marcus Metzler
sent you guys a patch to fix the issue properly. If Marcus sends you a
patch i can assure you that you that you can use that patch as it is.
> The well coded drivers mostly used the safe 0..2^15 range anyway, so
> it looks like all cards are reporting somewhat sane values now.
>
>
AFAIK, the values are simply mapped and on different hardware it has
different meanings. It might need further processing to display
something really sane enough.
> "Everyone else is doing it" doesn't make it right. I would much
> rather have a 'maintain lock for x msec' threshold rather than
> a have lock at 'magic moment y' threshold. We actually used to
> use the same tuning regime as those programs, and it resulted
> in shads of zero-length recordings...
I understand what you are saying, but if you say that if you want
drivers to be fixed, then it would be as good as talking terms to the
kernel folks to have certain features in the kernel. So IMHO if you
think that things should remain broken for that period till LK folks
agree, then MythTV will remain broken for all those time.
IMHO you guys should adapt to something what's acceptable to the rest of
the world for the time being and later on use the stuff whatcomes out as
a good solution. First fix the immediate problem, then go for the finer
fix. Don't wait for the fine fix to be your first and final fix.
>
> I tried searching the archives and didn't find anything for this.
> I have applied patches from him, so he's not a total unknown
> around here...
>
>
I will ask him to send again, in case you guys are interested.
Manu
More information about the mythtv-dev
mailing list