Skip to content

State of WinTV-Aero-m & ATSC-MH support in Linux

As of the release of Linux Kernel 3.1, Hauppauge’s WinTV-Aero-m is fully supported for use with both ATSC and DVB-T, using the new MFE framework within dvb-usb to represent two frontends on a single DVB adapter. This makes the Aero-m the first semi-worldwide terrestrial digital television broadcast receiver to be supported under Linux.

The device is built of two LG broadcast demodulators and a MaxLinear SoC. The first LG demodulator, LG DT3305, has been well supported in Linux for ATSC ever since I released it a few years ago. I’ve written a new driver to support the other LG demodulator, LG2161, for ATSC-MH, but it hasn’t yet been merged upstream.

Since ATSC-MH is a relatively new delivery system, some API changes will need to get cleaned up and merged before support for the LG2161 can be added to the kernel. Additionally, since the payload format is different from standard transport streams, some changes will have to be made to the kernel demux and / or some userspace libraries in order to make ATSC-MH work with userspace applications.

What is ATSC-MH? In summary, it is a way to broadcast digital television to devices in motion, similar to (but not the same as) DVB-H. The content co-exists with ATSC, and is usually standard definition or lower resolutions, meant to be viewed on handheld / mobile devices.

As of today, there is open source driver support for ATSC-MH and the LG2161 in my own development repositories, but there is no open source userspace applications to support this as of yet. (There are, however, closed-source solutions available. Contact me privately for more info) I have plans to eventually get all of this done for the general public, but I am also working on various other kernel & userspace projects as well, most of which are much more exciting to me right now. I’d like to get these API changes done for ATSC-MH, so that I can close the book on this project, but I haven’t seen much interest for it in the community. Are there people out there that want ATSC-MH to work in Linux?

Basically, I want to know if anybody cares about ATSC-MH. Do you want to be able to watch TV on your linux-based laptop / mobile device while commuting to work on the train? Do you want to display video advertisements and other content on the sides of city buses? Do you want to be able to enjoy your favorite television show *while* crossing the street? ;-) Please let me know. I want to know if it’s worth it to move forward with this. Are there any users or companies that want or need to use ATSC-MH in Linux, or should I just wait until I have nothing better to do? I *will* get this completed eventually, I’m just trying to understand how much it will benefit the community. If nobody cares, then I’ll surely get this all done within the year (or so) … but if people really are interested, I can have it ready by next weekend. You tell me.

In the meanwhile, please enjoy this semi-worldwide tuner using Linux 3.1 or later. I haven’t heard *any* bug reports yet. That means either my driver is awesome, or nobody is using it. Give me some feedback.

Posted in aero-m, hauppauge, lg2161, lgdt3305, mxl111sf.

No comments

By Michael Krufky – January 20, 2012

HVR-1800/1850 Analog support

After quite some time of talking about it, we finally got around to getting the analog support for the HVR-1850 submitted upstream. Support for all things analog is present and tested on all the various input types: the MPEG encoder, raw capture, analog audio. This patch series also includes a fix for a long-standing regression in the HVR-1800 as well.

http://git.kernellabs.com/?p=stoth/cx23885-hvr1850-fixups.git

Users are free to try it building from the above git tree, or they can wait a few days for it to be merged into the upstream linux-media tree.

The HVR-1850 is a really nice card (effectively the PCIe equivalent to the HVR-1600 that is already a popular choice with the MythTV crowd), and we will be happy to see the card fully supported in the mainline kernel.

Comments/feedback welcome!

Posted in cx23885, hvr-1800, hvr-1850.

No comments

By Devin Heitmueller – January 6, 2012

HVR-950q fixes and tvtime…

It’s been a while since we’ve had a blog post, so I figured it would be a good time for an update as to some things going on. We’re continuing to work in a number of areas, although in some cases things are moving along “behind the scenes” and are less visible to the public.

First, let’s talk about the HVR-950q….

As a result of some consulting we did in the last month, I spent *alot* of time digging into the tuning behavior for the HVR-950q. This included finding several bugs which explain some of the “sometimes tuning just fails” type behavior. These are the sorts of things that only happen 1% of the time, so they tend to be quite annoying to track down. I’ve said this in the past and it continues to be true – getting a device up and running is very different than making it work reliably. It can take a ton of work to get a product from a state where it’s good enough for casual TV watching to a state where it’s good enough for embedding in a commercial product.

The patches will be posted soon enough, and I believe that everybody will be happy to see faster tuning times and more reliable/consistent behavior in particular for digital tuning (ATSC/ClearQAM). But to make the analog people happy as well, I also isolated a nasty bug where sometimes changing channels would cause a green screen and it would stay that way until you restarted the device.

All that said, there are still a couple of lingering issues that I want to investigate deeper — in particular one issue related to analog audio not always working. It just goes to show that even if you spend weeks working on a single driver that there are always some weird edge cases outstanding that still need to be isolated and worked on…

Moving on to tvtime…

Kernel Labs’ involvement with tvtime falls under the adage “necessity is the mother of invention.” We needed a tool that was readily available which demonstrated to customers that our drivers were working as advertised. This, combined with the fact that tvtime didn’t build against recent Linux distributions, prompted us to set up our own repository and start making fixes as well as incorporating patches from the various distros. We became a “defacto maintainer” in light of nobody else really being willing to do the work.

Times have changed though and in recent weeks there has been renewed interest in forming a development community around tvtime. This is largely been among the LinuxTV developers, as well as a couple of individuals who have been porting patches between various distros. The net result though is that the tvtime tree will be moving to linuxtv.org, where it can be maintained on an ongoing basis by several people (myself included). This will hopefully lead to the remaining patches from distros being consolidated and the distributions all switching to the LinuxTV version of tvtime as the “official upstream provider”. Plus, with multiple maintainers there should be less of a situation where perfectly good patches get blocked from being merged as a result of a single person being too busy (something which I myself have been known to cause).

In closing…

Beyond that, we’re continuing to grind away at drivers for new devices, do fixes in userland as needed (in fact, some VLC fixes I did for closed captioning were merged upstream last week), and we’ll continue to provide status updates as things can be made public…

Posted in au0828, au8522, hauppauge, hvr-950q, tvtime.

13 comments

By Devin Heitmueller – October 12, 2011

mxl111sf / aero-m mercurial repo forward ported for Linux 3.x

For those wanting to test the mxl111sf driver for the WinTV-Aero-M but not willing to rebuild your kernel, there is good news for you!

I have applied the minimal backports required to dvb-core and the dvb-usb framework to get the old mercurial repository building against Linux 3.x

http://kernellabs.com/hg/~mkrufky/mxl111sf-linux-3.x

I had to disable all IR / remote stuff, since there’s been tons of changes there that I don’t want to deal with.

I’ve only tested the mxl111sf driver in this tree, but other drivers may build successfully as well — try them at your own risk. I’m willing to accept backport patches if there are any features in the newer media tree that would be helpful here.  If things work out well, this can be the starting point for the resurrection of mercurial backports (but let’s not get ahead of ourselves just yet).  For now, this repository is primarily intended for testing the aero-m.

How it works:

This repository contains a combination of some hacks and some backports from the upstream media kernel tree.  The quilt package is required to use the modified build method.

From within this repository, push all of the included quilt patches:

 quilt push -a

After all patches are applied, build the repository and install the modules, just as you would with the older mercurial v4l-dvb test procedure:

 make
 sudo make install

Then insert the usb dongle, the drivers should load up, and you are ready to go!

Note: there are detailed instructions for using the mercurial repositories on linuxtv.org, please consult with online resources before asking me for help with the build system.

Note to driver developers: If you want to be able to use the quilt tool without interfering with the included top-level quilt series, simply spawn a new quilt series under linux/

Posted in aero-m, hauppauge, mxl111sf.

No comments

By Michael Krufky – August 25, 2011

Hauppauge WinTV-Aero-m Linux driver

I’m pleased to announce the mxl111sf Linux driver with support for ATSC on the Hauppauge WinTV-Aero-m.

The device uses a Max Linear tuner with the LG DT3305 ATSC/QAM demodulator. The device also supports ATSC-MH Mobile DTV, but that feature is not yet supported under Linux.

Since I began work on this driver over a year and a half ago, mercurial was the tool used to track development.

If you are the owner of one of these USB dongles, please feel free to give the following repository a try:

http://kernellabs.com/hg/~mkrufky/mxl111sf

Please note, the mxl111sf mercurial development repository is based on a rather old v4l-dvb base tree.  The mercurial repository will not work with the latest kernels.  For those looking to build this driver using git, I have pushed the driver into the ‘atsc’ branch of my mxl111sf git tree on linuxtv.org:

http://git.linuxtv.org/mkrufky/mxl111sf.git

To clone the atsc branch, run the following command:

 git clone -b atsc git://git.linuxtv.org/mkrufky/mxl111sf.git

This is a really cool device – I look forward to hearing your feedback after testing.

Posted in aero-m, hauppauge, lgdt3305, mxl111sf.

2 comments

By Michael Krufky – August 22, 2011

Fix for Hauppauge USBLive2 Regression

Several users who saw the announcement of support for the Hauppauge USBLive2 several months ago reported in the blog comments that the support became broken in the mainline kernel.

After finally getting some time to investigate, I did confirm that there had been a regression, identified the issue, and have submitted a patch for upstream inclusion.

The patch can be found at the following link. It can be applied against the current media_build tree, as well as the 3.0.0 kernel.

http://www.mail-archive.com/linux-media@vger.kernel.org/msg34771.html

Thanks go out to Robert DeLuca for sponsoring the development of a fix for this issue.

Comments/feedback welcome, as always.

Posted in cx231xx, hauppauge, usblive2.

No comments

By Devin Heitmueller – July 23, 2011

HVR-1300 s-video fix when using MPEG encoder

A couple of days ago I submitted a patch for the HVR-1300 to fix a problem where the s-video would have the comb filter enabled even when capturing on s-video. This caused distortion of the video, as Florent Audebert pointed out on the linux-media mailing list. The weird thing is that it only happened when capturing on MPEG, which ultimately was a bug where the input was getting switched whenever the cx88 driver started up the MPEG encoder.

The patch can be found here:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg34236.html

Thanks to Anevia S.A. for sponsoring the fix to this issue.

Posted in cx88, hauppauge, hvr-1300.

No comments

By Devin Heitmueller – July 11, 2011

Call for Testers: HVR-1300, HVR-3000, HVR-4000 DVB-T tuning fix

For quite some time, there have been users complaining of DVB-T scanning problems using application such as MythTV or w_scan. Even stranger, they claimed that using /usr/bin/scan would indeed work as expected.

For example, this Launchpad ticket has tracked the issue for almost two years:

https://bugs.launchpad.net/mythtv/+bug/439163/

MythTV has a ticket tracking the issue too (although closed due to it being declared “upstream”):

http://code.mythtv.org/trac/ticket/9270
http://www.mythtvtalk.com/hvr-4000-fails-scan-11318/

I finally got my hands on some hardware to test with, and what I found was not a device specific bug, but rather a race condition in the framework. This will actually effect far more devices than just the three noted above. Pretty much any card which strobes the reset pin in it’s ts_ctrl() function will hit this issue with applications like MythTV.

I’ve cooked up a patch for the issue and submitted it to the linux-media mailing list for upstream inclusion. It can also be found here if users want to apply it directly to a media_build tree themselves:

https://launchpadlibrarian.net/74557311/frontend_dvb_init.patch

My hope is that this should fix a longstanding issue where no developer had the time to investigate. I’ve tested it with my DVB-T generator and now I can see that w_scan does work. But it would be great it some users would try it out and report back as to whether it improves their situations. Feedback in the comments section welcome below….

Posted in hauppauge, hvr-1300, hvr-3000, hvr-4000.

17 comments

By Devin Heitmueller – July 4, 2011

PCTV 340e and xc4000 drivers going upstream

The PCTV 340e is one of those unfortunate situations that I (Devin Heitmueller) personally take alot of criticism over. About two years ago I bootstrapped the driver, got it working with the hardware, but then never got around to cleaning up the code enough to get it upstream. This has resulted in the HG tree I created to fall behind current kernels, as well as people being frustrated that the work isn’t available in the upstream kernel where they wouldn’t have to recompile my driver every time they do a kernel update.

While I generally strive to get my changes upstream so that they help out the maximum number of people, this is a case where I clearly failed. I invested between 30-40 hours bringing up the device. This included:

  • Negotiating with Xceive Inc. to get access to reference driver code as well as firmware redistribution rights that would allow inclusion in Linux distributions.
  • Working with DibCom to identify, understand, and workaround bugs in the dib0700 chip’s i2c implementation
  • Working with PCTV Systems to get sample devices as well as engineering details about their specific hardware implementation.
  • Using the above information to actually write a driver which works, and test it under a variety of signal conditions. This included dealing with the fact that I’m actually not in a country that receives DVB-T, so I had to use a signal generator instead.

Most of this effort occurs in private emails with the vendors and is largely invisible to users who just want their device to work. However it’s a necessary evil if the intention is to deliver a driver which actually works and that can be used by regular users.

I’m happy to say that in the last 24 hours, there has been renewed interest in getting the driver upstream. This includes other developers contributing to take my patches, do the cleanup needed, as well as extending the xc4000 driver to support analog tuning (something which is useful for the driver in general but won’t help for the 340e in particular for other reasons).

I look forward to seeing this work in the mainline kernel, and would like to thank those who are actively contributing to making this happen (both in development as well as testing):

  • Istvan Varga
  • Mauro Carvalho Chehab
  • Dmitri Belimov
  • Mohammad Bahathir Hashim

If you’re a 340e user who wants to help out, you should try out the tree that is actively being developed and report in your feedback on the linux-media mailing list.

http://www.spinics.net/lists/linux-media/msg33114.html

Posted in 340e, xc4000.

17 comments

By Devin Heitmueller – June 3, 2011

Hauppauge products and Pace DTAs

While this is a bit off-topic for a Linux specific blog, I figured it might be of interest to those of you that have a Hauppauge product and for some time have been frustrated that it doesn’t work with your Pace DTA.

A known limitation of the onboard IR blaster found in many of these products is the inability to blast the XMP protocol which is becoming more and more common in the Digital Terminal Adapters (DTAs) that US based cable companies are giving away as they transition to all-digital networks. For example, it is very common for Comcast to provide these boxes at no charge to existing customers.

This basically means if you have one of the Hauppauge products that contain the Zilog, you have to go out and buy a separate MCE IR blaster in order for it to work with those devices.

After getting sufficiently frustrated with the situation, I sat down and hacked together a solution. If you are a Windows user, you can get the following hcwblast.ini file, which will allow the device to work with the Pace DTA.

http://devinheitmueller.com/HCWBlast.ini

Download the file, make a backup of the hcwblast.ini already in your c:\windows directory, then overwrite that file with the file I provided.

To test it out:

  1. Make sure the IR blasting cable is attached to the front of the DTA (see photo below)
  2. Run the “BlastCfg” tool that comes with the product
  3. Click the “Advanced Config…” button
  4. Click the “Learning…” button
  5. Click the “Send” radio button
  6. Then press the various buttons. As you press them, you should see the buttons being sent to the DTA. The 0-9 buttons should work, as well as the “Enter” button

This solution should work with the HVR-1600, HVR-1950, HD-PVR, PVR-150, PVR-250, and PVR-350. It’s tested against a Pace DCI105, but should also work with the DC50 or DC100 as well (they use the same codeset).

The usual disclaimers of “no warranty” applies. If it doesn’t work though, you can just restore the backup copy of hcwblast.ini that you made in Step #2 (be sure to close blastcfg first though).

Feedback (either positive or negative) always welcome in the comments section below.

Special thanks goes out to Andy Walls for his crucial role in understanding the format of the IR blobs.

Posted in hauppauge.

5 comments

By Devin Heitmueller – May 30, 2011