AVerMedia M150-D

From MythTV Official Wiki
Revision as of 03:09, 28 September 2010 by Wagnerrp (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Warning.png Warning: This page has been locked and archived on September 27, 2010. The official documentation for this card can be found at AVerMedia_M150-D. This page remains as there is significant information herein not included in the official documentation. Please migrate any such information to the proper location.


AVerMedia M150-D
Vendors Website http://www.aver.com
Input Formats not applicable
Support Status Supported in MythTV 0.20 onwards (may require unusual configuration settings; see below)
Driver cx88 and cx88-blackbird in recent Linux kernels.
Sound Driver N/A for MPEG-2 device; cx88-alsa for framebuffer access
Chipset Conexant CX2388x and CX23416


Note: This device is reportedly the same as the AVerMedia AVerTV 1500 MCE; the M150-D is the OEM version of the card, while the 1500 MCE is the retail version. This board may also be known as the ASUS PVR-416. Windows XP device manager identifies it as an "AVerMedia AVerTV (Philips 1236 MK3)" series of devices. AVerMedia also makes other cards, such as the AVerTV Studio and the M179, which require different drivers and installation procedures from those described here.

Description

The AVerMedia AVerTV M150-D and 1500 MCE are MPEG-2 encoding cards using the Conexant 2388x chip and the 23416 MPEG-2 encoder chip. Although this hardware is similar on the surface to some Hauppauge cards, the AVerTV hardware requires different drivers. Specifically, whereas the Hauppauge MPEG-2 cards use the IVTV driver, the AVerTV M150-D uses the CX88 driver and its "Blackbird" optional extra driver.

As an MPEG-2 encoding device, the AVerMedia AVerTV M150-D requires little CPU power to operate. On a system with an Athlon-64 3000+ running 64-bit Gentoo, the device consumes between 0.1% and 1% of CPU time, according to top.

At least two versions of the M150-D and one of the 1500 MCE have been released. The first version of the M150-D provides just two coaxial inputs, one for an FM antenna and the other for a TV antenna or cable TV input. The second version of the M150-D and the 1500 MCE provide additional composite and S-video inputs. The initial version of this wiki entry was written using a bare-bones coaxial-only M150-D as a reference. This board was scavenged from a Gateway Media Center PC and traded on eBay for a ridiculously low price.

Driver Installation Overview

This board requires the cx88 and cx88-blackbird kernel modules to operate, as well as various ancillary kernel modules. These modules are part of the standard kernel tree; the reference platforms for this wiki entry used a 64-bit 2.6.19.1 kernel and 32-bit 2.6.19.2 and 2.6.20 kernels.

Unfortunately, loading the modules isn't enough; the board requires firmware files to be uploaded by the drivers -- a fact that's conspicuously absent from most online discussions. If you don't have ready-made and obvious firmware files, follow these steps:

  1. Obtain the file ftp://ftp.hp.com/pub/softlib/software3/COL6537/pv-20048-1/SP26281.exe, which is a Windows driver package
  2. In an empty directory, use the Linux program cabextract to unpack the archive: cabextract SP26281.exe. Note: Most Linux distributions don't install cabextract by default. Consult your packaging system or download it from its Web site.
  3. Type dd if=driver/cx88enc.sys skip=27912 bs=1 count=262144 of=blackbird-fw-enc.bin to extract the firmware from the Windows driver.
  4. Move the blackbird-fw-enc.bin file to /lib/firmware or whatever other directory houses your firmware files.
  5. Some reports indicate that the blackbird-fw-enc.bin file must be renamed v4l-cx2341x-enc.fw. Copying the file or creating a link should do no harm and will ensure that the file is available under both names.

Once you've taken these steps, the driver should load the firmware automatically, at least assuming you're using hotplug or udev. You shouldn't need to reboot the computer; the driver should try to load the firmware the next time you access the video device files. If you have problems, though, unloading and reloading the drivers, or even rebooting the computer, may be a useful step to be sure the drivers and firmware are reset.

The latest drivers, available from the v4l project's Mercurial repository, as well as kernel 2.6.22 and later can use the firmware provided with the IVTV drivers, which are available at some package repositories (e.g. ATrpms).

Verifying Driver Installation

Once you've finished installing the drivers (if your distro hasn't already done so for you), you should verify that the device is available. First, check for an appropriate video file. If this is your only video capture device, it will probably be /dev/video or /dev/video0. The blackbird module creates a second video file, which will most likely be /dev/video1 if this is your only capture card. The first video device file provides framegrabber (non-MPEG-2) access to the card, while the second provides access to the MPEG-2 video stream.

If the MPEG-2 device file is present, you can test it by passing it to mplayer, as in mplayer /dev/video1. This should produce a video stream using whatever channel or input the device is configured to use by default. Alternatively, you can try using cat to copy a video stream to a file, which you can then examine using tools that can handle MPEG-2 video:

cat /dev/video1 > foo.mpeg

Note that you might get a blank display if the device is set to an input you're not using.

TV applications might or might not produce a useable display, since they might or might not work with an MPEG-2 stream.

You can also test the framegrabber device file with

mplayer tv://$channel -tv driver=v4l2:device=/dev/video0:chanlist=us-bcast norm=NTSC-M

(replace an appropriate TV channel number for $channel)

If you have problems or want to check some low-level configurations, you can review driver installation. As a reference, here are the modules loaded on the reference system:

$ lsmod | grep blackbird
cx88_blackbird         20932  0
firmware_class         12096  1 cx88_blackbird
cx2341x                12804  1 cx88_blackbird
cx8802                 14468  2 cx88_blackbird,cx88_dvb
cx8800                 40076  1 cx88_blackbird
cx88xx                 71076  5 cx88_blackbird,cx88_dvb,cx8802,cx8800,cx88_alsa
videodev               28544  3 cx88_blackbird,cx8800,cx88xx
v4l2_common            26624  6 cx88_blackbird,cx2341x,tuner,cx8800,compat_ioctl32,videodev
video_buf              29060  7 cx88_blackbird,cx88_dvb,cx8802,video_buf_dvb,cx8800,cx88_alsa,cx88xx

Finally, here are the kernel messages from the drivers being loaded, as reported in dmesg output:

Linux video capture interface: v2.00
i2c-core: driver [tveeprom] registered
CORE cx88[0]: subsystem: 1461:c111, board: ASUS PVR-416 [card=12,autodetected]
TV tuner 43 at 0x1fe, Radio tuner -1 at 0x1fe
i2c_adapter i2c-0: adapter [cx88[0]] registered
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x50
i2c_adapter i2c-0: master_xfer[0] W, addr=0x50, len=0
i2c_adapter i2c-0: master_xfer[0] W, addr=0x50, len=0
i2c_adapter i2c-0: client [tveeprom] registered with bus id 0-0050
i2c_adapter i2c-0: master_xfer[0] W, addr=0x50, len=1
i2c_adapter i2c-0: master_xfer[0] R, addr=0x50, len=256
cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
vt596_smbus 0000:00:11.0: VT596_smba = 0x400
i2c_adapter i2c-1: adapter [SMBus Via Pro adapter at 0400] registered
cx2388x v4l2 driver version 0.0.6 loaded
ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 17
cx88[0]/0: found at 0000:00:0a.0, rev: 5, irq: 17, latency: 32, mmio: 0xcc000000
tuner 0-0043: chip found @ 0x86 (cx88[0])
tuner 0-0060: All bytes are equal. It is not a TEA5767
tuner 0-0060: chip found @ 0xc0 (cx88[0])
i2c_adapter i2c-0: client [(tuner unset)] registered with bus id 0-0060
tuner 0-0060: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
tuner 0-0060: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88[0]/0: registered device radio0
cx2388x blackbird driver version 0.0.6 loaded
cx88[0]/2: found at 0000:00:0a.2, rev: 5, irq: 17, latency: 32, mmio: 0xce000000
cx88[0]/2: cx23416 based mpeg encoder (blackbird reference design)
cx88[0]/2: registered device video1 [mpeg]
cx88[0]/2-bb: Firmware and/or mailbox pointer not initialized or corrupted
cx88[0]/2-bb: Firmware upload successful.
cx88[0]/2-bb: Firmware version is 0x02040120
cx88[0]/2-bb: VIDIOC_TRY_FMT: w: 720, h: 480, f: 4

Note that I've omitted quite a few dmesg lines unrelated to the M150-D, as well as several repetitive i2c messages that probably are related to the board.

Pay particular attention to the Firmware upload successful message. If it's not present, or if you see a message saying that the firmware upload was not successful, you should review your firmware configuration. The board will not function as an MPEG-2 encoder without a successful firmware upload. (You might be able to use the framegrabber device file to use the card as a software encoder without the firmware upload, though.)

Of course, some details will differ on your system, particularly if you build relevant drivers into your kernel -- they won't then show up in the lsmod output.

Setting Video4Linux Options

On the reference system, the video devices were present, but subsequent tests produced video but no audio. The cause was that the drivers brought the card up with audio muted. This problem was easily remedied with the v4lctl utility, which was part of the xawtv package on the Gentoo reference system:

v4lctl -c /dev/video1 volume mute off

The utility v4l2-ctl included in the v4l2-apps utils directory can also be used:

v4l2-ctl -d /dev/video1 -c mute=0

This command can be placed in a local boot file (such as /etc/conf.d/local.start for Gentoo or /etc/rc.local for Ubuntu) to have it execute automatically when the system boots. Alternatively, you can incorporate it into a channel-change script, as described shortly.

MythTV Configuration

Once the drivers are installed and appear to be working, you can configure the device in MythTV. For the most part, you should be able to treat the encoder as if it were a Hauppauge WinTV PVR-x50/500 card: Tell MythTV that it's an MPEG encoding card. The User Manual:Detailed configuration Backend section of this wiki describes MythTV backend configuration in more detail.

One slightly confusing fact: On my system, the backend configuration tool (mythtv-setup) detected both the /dev/video0 and /dev/video1 devices as software encoders, but attempting to configure /dev/video1 in this way would not work. Using the MPEG-2 encoding screen, manually typing the device name (/dev/video1 in my case), and proceeding with configuration worked. Once the device filename is typed in, mythtv-setup recognized it as an ASUS PVR-416.

Initial attempts to use the device sometimes produced distorted ("razzy") audio; however, I never noticed such problems when using mplayer to access the card, so I suspected a problem in the way MythTV tuned the device. This problem may also be likely related to the kernel bug that causes a race condition mentioned in the cx88 section of the PCI TV Audio article. However, this problems seems to have been resolved as of kernel 2.6.25. If you do experience this problem, a little experimentation revealed a workaround: Specify a custom channel-tuning script in the mythtv-setup program.

#!/bin/bash
v4lctl -c /dev/video1 setchannel $1
v4lctl -c /dev/video1 volume mute off
#sleep 1

Of course, you should set the video device file as appropriate for your system. This script also unmutes the audio channel, just to be sure that task is done. My initial hypothesis was that the MPEG-2 stream didn't become stable for a brief period and that a delay (via a call to sleep) would cure the problem. This doesn't usually appear to be necessary, at least on my system; I suspect the second v4lctl call and/or overhead in calling a bash script is sufficient to enable the MPEG-2 stream to settle. If you get distorted audio even when using the above channel-changing script, try uncommenting the sleep 1 line. If that doesn't work, try increasing the sleep pause value. It's conceivable that calling v4lctl directly, rather than in a script, would work around the problem. Over the course of over two weeks using this tuning script and recording several shows a day, the razzy audio problem occurred once, when the system was starting three recordings simultaneously.

In the frontend, you can tweak your Recording Profiles in the usual way; however, see the "Issues and Problems" section for one caveat.

Hardware (MPEG-2) vs. Software Encoding

You can also use an AVerMedia AVerTV M150-D card as a software encoding device by telling mythtv-setup to use /dev/video0 as a frame grabber. Such a use will require you to load the cx88-alsa driver, which provides ALSA device files to access the video card's audio stream. It has successfully been tested using 32000Hz sampling rate and ALSA sound driver output. Note that one should probably specify that this card should not be the primary sound card interface by passing index=1 to the cx88-alsa driver module, otherwise MythTV will try output its audio to it instead of your real sound card. If there are audio devices other than this card and the primary sound card, then you may want to use a number other than 1 for the device index.

Using the card as a frame grabber will result in higher CPU use but more encoding options. You'll be able to encode directly to either MPEG-4 or RTjpeg. Furthermore, there appears to be sound-related issues when switching between hardware encoding and frame buffer access with kernels as late as 2.6.25. If problems are encountered when switching between MPEG access and frame buffer access, module reloading is recommended.

You should not configure access to both the framegrabber and MPEG-2 device files in MythTV. The card contains just one tuner, so any attempt to use both simultaneously (as MythTV would likely try, sooner or later) can't do anything good.

Issues and Problems

The audio stream often become corrupted when tuning channels using MythTV's built-in channel tuner when using earlier kernels. If you experience this problem, try specifying a separate channel-tuning command, as described earlier, in the "MythTV Configuration" section. It is possible that the patches mentioned here may also solve the problem. This problem seems to have been solved as of kernel 2.6.25.

The card seems to have problems changing channels in MythTV's live TV also when using earlier kernels; MythTV freezes after entering a channel number, and the only way out seems to be to kill the process. These problems affected about 50% of tunes before I implemented my channel-change script and 100% after. Therefore, the M150-D seems to be useless for channel-surfing within MythTV. This problem also seems to have been solved as of kernel 2.6.25.

The card seems to be unresponsive to attempts to change its video recording resolution; it returns a 720x480 MPEG-2 stream no matter what resolution is requested. The delivered bitrate seems to match what MythTV requests, though. If you want something other than a 720x480 stream, you may have to transcode your recordings after the fact. I've only attempted to change the horizontal resolution down to 640x480; I've not tried lower resolutions than this or changes to the vertical resolution. It's also conceivable that a lower resolution could be acquired by changing other encoding parameters; there are hundreds, if not thousands, of possible combinations, and I've not tested them all. The card does respond to resoluton changes via v4l2-ctl -d1 -v width=w,height=h so it might be fixed in a later release of MythTV (after 0.20.2).

The card's most serious problem is its unreliability with earlier kernels; in tests with 2.6.19.1 and 2.6.19.2 kernels, the card is mostly reliable, but sometimes produces 0-length recordings. In tests with 2.6.25 it has been completely reliable. When this happens, the /var/log/mythtv/mythbackend.log file contains Can't open video device and Device or resource busy (16) errors. When using a 2.6.20 kernel or the latest (March 2, 2007) v4l drivers, MythTV always creates 0-length files. This problem is much less common when using the separate channel-tuning script described earlier (I don't recall a single instance in over two weeks' use), but only with 2.6.19.1 and 2.6.19.2 kernels and their standard drivers; tests with the separate v4l driver package produce 0-length recordings. Kernel 2.6.22 and 2.6.23 also seem mostly reliable.

This card is quirky enough that it may not be the safest choice for a primary MythTV tuner with earlier kernels; however, the use of a separate channel-change script makes it reliable enough to be used as a secondary tuner or if you never want to channel surf. Your choice of kernel version number is critical.

Relevant Links