05 Nov 2009 |
Posted by Devin Heitmueller | 2 Comments.
2
While Steven continues to churn away on ALSA audio and VBI support for the HVR-1800, I have started working on a project to do ALSA audio for the HVR-1600. So if you have an interest in being able to use the raw analog video capabilities for the 1600, stay tuned!
The call for testers for the ClearQAM fixes has been very successful, and I am happy to report that 100% of the people who have done testing have seen a significant improvement in ClearQAM performance, with none reporting a regression. That said, I will be issuing a PULL request this weekend to get the changes into the mainline v4l-dvb...
29 Oct 2009 |
Posted by Devin Heitmueller | 47 Comments.
47
If you are an HVR-1600 user who has noticed the ClearQAM tuning performance under Linux was worse than under Windows, this should make you happy.
As a result of the work described in the previous post, there is now a tree that contains the various fixes:
http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-perf-2
The goal is to submit this upstream, but before that we want to get some people to try it out first and submit feedback on their experience.
Thanks go out to ONELAN Limited for sponsoring this work!
Feedback (good or bad) on the blog or the linux-media mailing list would...
22 Oct 2009 |
Posted by Devin Heitmueller | 54 Comments.
54
Haven't had much time to update the blog lately. All week I've been quietly grinding away at two basic issues: PAL VBI support for the em28xx chip, and identifying/addressing the HVR-1600 performance problem.
I often get questions from users along the lines of "how do you make boards work?". Reverse engineering is a bit of a black art, but I figured I would offer some insight as to how the process works. If you don't actually care how tuners are designed and how we figure out how to make them work, stop reading now. If this stuff interests you, read on, and feel free to put something in the comments...
02 Aug 2009 |
Posted by Michael Krufky | 0 Comment.
0
I've decided to post some patches that attempt to bring some consistency across the ATSC demodulator drivers in the signal strength reporting mechanism.
If we use the lgdt330x driver as an example, signal strength is calculated as a percentage from SNR up to 35 dB. Why up to 35 dB? As indicated in the comments inside the drivers:
Calculate strength from SNR up to 35dB
Even though the SNR can go higher than 35dB,
there is some comfort factor in having a range of
strong signals that can show at 100%
The behavior of the code in this tree gives you a nice feeling of "100%" strong...