I know things have been pretty quiet on the blog lately, so I wanted to give you all a quick status update on how various projects are going (for better or for worse). We are quite busy, but alot of the stuff we are working on is not currently publicly visible, and many people who read the blog are interested in various things we are doing in the open source community (either out of academic curiosity or because you own some piece of hardware that you are hoping to see better support for).
So, let’s talk about the stuff that we are actively working on first:
em28xx quality fixes – I spent most of this week trying to nail down a significant quality problem in em28xx analog support. I did isolate one problem, but I am seeing other issues that bother me. The current fix is here:
http://kernellabs.com/hg/~dheitmueller/em28xx-test/
While I was at it, I nailed down a regression that got introduced that resulted in the xc3028 firmware taking nearly five seconds to load (whereas it used to take about 1 second). This is probably most noticeable by users of devices such as the original HVR-950 (em28xx/xc3028) where it resulted in applications like tvtime and MythTV taking *much* longer to startup.
http://kernellabs.com/hg/~dheitmueller/xc3028-regression/
tvtime – Tvtime work has been slower going than I would have liked. I did do some work last week, but the more testing I do the more problems I find. The goal at this point continues to be to get a release where both the audio and VBI support work well with a variety of cards, and then ask the distributions to redistribute this version.
HVR-1600 ALSA support – There were a bunch of cleanups required to get this upstream, but I am happy to announce that it was merged this week. None of the changes asked for were actually necessary for the driver to work – all of them were codingstyle issues.
http://kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-3/
Now, let’s talk about the things I’m not working on right now. This list is based largely on the comments I receive both on the blog and via email where people ask “When is X going to start working?”. I feel there is some value in telling everybody about this stuff, so that expectations are set properly and in case anyone else wants to contribute (knowing that we are not actively working on it).
HVR-950Q work with MythTV – Ok, so I was the guy who wrote the analog support, and I did do some work a couple of months ago to at least getting it basically working with MythTV (with a few well-documented caveats). But as at least one user has pointed out, there is some sort of race condition where the card gets locked up periodically when switching back and forth between analog and digital. If you use it for digital only then you are fine, or if you use it for analog only then you are fine. But if you try to use it for both then you are in for trouble.
HVR-900R2 and PCTV 330e – I’ve discussed this particular issue various times in previous posts. Basically it boils down to getting an extraction script written for the firmware, and fixing the existing driver to work with the updated firmware (since the firmware that was used to write the original driver can not be found). You can read the blog history for the gory details as to why something that sounds as simple as a firmware extraction script would end up being such a headache.
PCTV 340e/340eSE/801e/801eSE analog support – At this point, I have no plans to be extending the dvb-usb framework to support analog, which is what would be required to get analog support working for any of the dib0700 based devices named above.
saa7164 analog support – This is basically the same situation as with the dib0700 – it requires a *huge* development effort that would amount to hundreds of hours of labor. Sure, we might come out with something at some point if a commercial backer steps up, but I would not expect to see this supported in the immediate future.
I realize that the above list of “stuff we are not working on” can be frustrating if you are a user who was hoping to see one of these things done sooner. Let’s not forget that all of these are projects that KernelLabs developers are doing in their own free time for no compensation. We’ve donated thousands of hours to making LinuxTV better. And when it comes to the stuff we do in our free time, we need to focus on the things that interest *us* personally in order to keep our sanity. Unfortunately, the stuff I may be interested in “playing around” with is often not the stuff certain groups of users would prefer we spend our time on.
It’s probably also worth noting that we do see people who post comments in the blog along the lines of “How about accepting donations? I would donate $10.00 to see XYZ working.” However, at this time we are not accepting donations toward any of these projects. Why? Because there is *nowhere* near enough people who are willing to donate to make it worth our while – and it wouldn’t be fair to accept your donations but not deliver. I do appreciate those people who offer to donate, but unless you can find 1500 more friends like you, you are in an extreme minority. I have had extended conversations with a few individuals who argue that our view is not valid, but ultimately it is our decision what we dedicate our efforts to.
To end this post on a positive note, if you are a PCTV 74e user who has been looking for driver support, keep an eye on the blog since I’ve got a GPL driver and have worked out the firmware redistribution rights with the chipset vendor, so I just need to do some cleanup and testing before we can post a tree for testing.
Thanks Devin, I always look forward to seeing your updates. With regards to the HVR950Q analog in MythTV, I still haven’t been able to get it going. The Scan for Channels button is always disabled, and i’m not quite sure about what to define the tuner as; is it a standard Analog V4L device? IVTV device?
Hello Corey,
Bear in mind that the “channel scanning” feature in MythTV is completely disabled for analog mode, regardless of what board you try to use it with. They disabled it during the 0.22 development cycle because it was broken and they never got around to fixing it. If it’s any consolation though, I spent about an hour thinking the driver was broken before I emailed mythtv-users and found out that it didn’t work with *any* board. In order to use analog support with MythTV, you have to get a SchedulesDirect subscription.
In terms of what type of device to configure it as, it’s a standard analog V4L device.
Devin
Appreciate the update. Hope you do get some time to look at the digital/analog switchover race condition on the HVR-950Q as it is a nice, small and relatively inexpensive USB tuner. I suspect other multiple mode tuners have similar issues?
Zaphod,
I agree it would be nice. One of the key reasons I did the work for this tuner was because it was inexpensive and readily available. Regarding other hybrid tuners, I am not sure they would be effected. The 950q is one of the few devices I have seen that have both an analog video decoder and a digital demodulator on the same chip (the au8522). I believe this is why the 950q hits this issue – under on other devices the attempt to power down the digital demod immediately after switching to analog mode would not cause a problem because they are different chips.
Devin
That’s bad 🙁 but I understand you 🙂
It would be good to free the information for someone to add the analog support to hvr 2250, or to talk to hauppauge people to give more resources to this driver…
Mario,
Hauppauge isn’t really the issue (as officially they provide zero support for Linux devices). They also don’t control the rights to the specifications in question. The real issue is the chipset vendor (NXP) who has chosen to not make the datasheets available except under NDA. That is their right, of course, but it also restricts who is able to add the necessary driver support (unless someone reverse engineers the device and adds support without use of the datasheets).
Devin
Is there any way you can open a way to allow interested parties to try to do it ?
I mean, I understand that you are free to choose what you work on on your time,
but also you guys have some key enablers to actually work on this arena.
As you are bound by NDAs, can you at least show us the path to get such NDA,
if at all possible ? Somehow NXP let you get this base code / data sheets. Was that
free or not ?
On, I guess, a more practical side for those like myself wrongly choose a 2250
as a replacement for the great pvr-250 board, which board would you recomend
that is analog/digital @ linux ready ?
Hi Carlos,
Yes, all of the documentation we have on the saa7164 is under NDA. One of the reasons KernelLabs was founded was to create a corporate entity that can negotiate with chipset vendors to gain access to documentation (under terms that allow us to use the docs to write GPL drivers). Much of this boils down to trust of course – the chipset vendors are more willing to disclose the information to a company than to some “random developer on the Internet”. And speaking from personal experience, building relationships with these vendors is not a trivial endeavor. It takes time, energy, a formal business case, and sometimes actual money.
In terms of internal boards that do both analog and digital, I have had pretty good success with the HVR-1600 (which does both analog and digital, and in fact can do them both simultaneously), as well as the PCTV 800i (which doesn’t have an MPEG encoder but that fine given how infrequently I need to use it). If you need PCIe though, the options are pretty slim. Both the 1800 and 1850 have bugs in the analog support, and the 1250 doesn’t have an encoder, nor is the analog support implemented in the driver. Looking into the 1800/1850 issues is on my TODO list, although I doubt anything there requires the datasheets so much as just taking the time to sit down and debug the issues.
Devin
Ok, fair enough. It’s kind of a pitty not being able to leverage the will and energy
of people at large. I’ve contributed here and there to free software, and what I find not so nice is that this puts a high barrier in the path of getting a larger
base of programmers. Being that your time is a premium, having more
people involved might be a good idea. May be the way is to enlist in KernelLabs ? Is registration open ? 🙂
On the other side, the 1850 might be the way to go then. Is the analog
input (no tunner) supported ? I guess I’ll be able to swap the 2250 for a 1850
with a bit of luck (given I’m in Argentina)
-Carlos
Hi Carlos,
I agree that the situation makes it very hard for people to contribute. Unfortunately, the terms are defined by the chipset vendors. And while the solution KernelLabs came up with is not ideal, it’s a *huge* improvement over nobody being able to get the specs at all.
No, we aren’t really taking on any more people right now.
If you’re in Argentina, I’m surprised that you are using a 2250 at all, since the HVR-2250 is an ATSC/NTSC device and your country uses ISBD-T/PAL. If you’re going to buy a new card, you should consider one that is designed for PAL as opposed to NTSC. I originally listed out ATSC/NTSC cards under the assumption that you were in the United States.
Devin
PAL, yes, but PAL-N. The 2200 does not do N, and the 2250 does.
Go figure. ATSC ? Nope, but it can do QAM, so that was my compromise.
Oh well…
Both the 2250 and 2200 will support the same analog standards, as they both have the exact same analog frontend (tda18271/saa7164). Note though that under Linux there is no analog support at all for either the 2250 or the 2200 (making this a non-starter if your intention is to use the board under Linux).
As for QAM, you understand that the QAM provided by the 2250 will only work with USA based cable systems, right? It is not compatible with the QAM signaling you find with other standards such as DVB-T.
Devin
this is kind of pointless now (for me at least) but…
The choice of the 2250 over the 2200 was done under direct Hauppauge technical advice. In fact, being PAL a european standard I went for a 2200 and when I said that
I was in Argentina, they told me that the 2200 does not do N, only B/G and that
the 2250 would do N. Given that OTA digital was not my target, doing QAM and Pal/N
was a good compromise.
As for QAM alternatives, I’m lost. I thought that QAM was mostly digital and that there
were no local differences. We do use 6MHz channels here , and AFAIK there is
QAM on 6/7/8 MHZ. I’ve seen specs of QAM modulators (cisco) and I do not remember seeing different options on QAM alternatives. I thought that DVB was only relevant on OTA transmissions.
Hi Carlos,
I do find that a little surprising that they would tell you that, since they both use the same silicon tuner (the tda18271). It is possible though that under Windows they have restricted the software to be region specific, only allowing the 2200 to do B/G and only allowing the 2250 to support M/N. That would be completely unrelated to the hardware’s capabilities though (and it is unlikely that such an arbitrary restriction would be enforced under Linux, if analog support ever gets added for the product at all).
Unfortunately, the term QAM is pretty generic. There is QAM used for DVB-T, DVB-C, US based cable systems, etc. You cannot just look at a spec which says “QAM on 6/7/8 MHz” and assume that means the same QAM that you need.
That said, frankly I do not know how Argentina implements their cable system. I suppose it’s possible that they copied the US based standards for digital cable, but I could not say (and it seems pretty unlikely).
Oh, and to clarify, “DVB” does not specifically mean “over the air”. There are DVB standards for terrestrial, cable, and satellite (DVB-T, DVB-C, and DVB-S).
Cheers,
Devin
I have a WinTV-HVR-2250. I admit to being dissapointed that its going to take a giant effort to get analog working, as I’m interpreting that as you really saying that its unlikely to ever get done. especially as it is only you guys who potentially could do it, because of the NDA.
Is there any chance that you could at least getting the FM radio support working under Linux? I’m guessing that can’t be too much of an effort given its audio-only? I really would find FM support very useful.
Hello Neil,
The incremental cost of doing FM support once analog video is working is very small. Unfortunately, doing FM support requires about 95% of the same infrastructure that video needs. So it’s not one of those cases where you could do the FM support first as an incremental step toward analog video.
Devin
Hi,
I actually work in the consumer electronics environment, but I often use PC based DVB tools to analyse the live signals that are being delivered to our products. I recently purchased two PCTV 74e for monitoring use and foolishly I didn’t check the support status on them. They work fine in Windows with the manufacturer supplied software but anything else, including other Windows analysis software I have tried, just doesn’t work. I have now just been seeing what happens with Linux and ended up here.
I too find the secrecy of the chipset vendors disappointing because I think if they were more open the world would be a much more productive place. On a couple of levels I think I need to have a word with my NXP rep next time I am in contact. Data sheets for STB chipsets is one thing, but PC devices need all the drivers to be public really.
I look forward to seeing your progress.
Regards,
Bob
Hi Bob,
The amount that chipset vendors are willing to disclose varies wildly by company. Some will make datasheets available under NDA, some will provide datasheets and reference driver code under NDA, some will provide reference driver code that can be released under the GPL.
In the case of Abilis (the chipset vendor for the 74e), PCTV actually convinced them to release a GPL driver. However, because PCTV doesn’t want to incur the support overhead associated with “officially” supporting Linux, we worked with them so that the driver will come through KernelLabs. It basically works, but I didn’t want to post something that I haven’t had a chance to test myself yet.
In other words, keep an eye on the blog and there should be a driver up in the very near future. The plan at this point is to release the driver “as-is” and then work on cleaning it up so it can be merged into the upstream kernel (so that it will work by out-of-the-box with distributions).
It’s also worth mentioning that many of these chips are used both in STB and in PC devices. In fact, that is one reason why the PC devices are economical despite those products being relatively low volume – because they take advantage of chips designed for settop boxes.
Cheers,
Devin
Well, I know you probably have extensive contact with the chipset vendors already, but if I can help introduce you to any I am involved with the purchase of substantial volumes of product from the main chipset vendors.
I actually have an ambition to make the first DVB-T2 PCI card because I have a spare demod and PCI card to cannibalise, but I don’t have the time to get down to it.
Regards,
Bob
How much would you estimate you need to cover development costs for analog support? I am willing to commit several hundred dollars to get this going. I suspect their are others willing to contribute more much more $10. Create a seperate thread for with your estimate and lets tally the amount folks are willing to contribute. Lets see if we can meet your donation requirement.
Thanks
I agree with this. I’d even post it on my blog (which doesn’t get a lot of readers, but does get people interested in things like running XBMC on Linux–so they may be interested in MythTV also). If I knew more about coding drivers, I’d offer to help in that way also (although I see they’re not taking applications right now).
Have a great day:)
Patrick.
Hi all,
I really appreciate all the hard work Kernal Labs does for the Linux TV community!! I feel like you guys give with out expecting anything in return! 🙂
I know a lot of people in the Ubuntu forums are talking about IR (receiving) support for the 2250. I also believe that Steven said he might put this on his To Do list. I was just curious if this is really going to happen since it was not listed above?
Thanks again!
Jeremy
Hi Jeremy,
If I recall, Steven actually added the IR support to his TODO list *after* I wrote this blog post. That said, sometimes circumstances change which result in things getting done faster or slower than we thought. For example, of the things in the list above of stuff “we’re not working on actively”, we actually did in fact end up releasing support for the PCTV 330e and HVR-900 R2 and we did do the HVR-950q fixes for MythTV.
So while the goal is to try to keep readers “in the loop”, sometimes things don’t always go according to plan, largely dictated by what projects we have going on for commercial customers and how much free time we have to work on other stuff.
Cheers,
Devin