|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.
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
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-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 126.96.36.199 kernel and 32-bit 188.8.131.52 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:
- Obtain the file ftp://ftp.hp.com/pub/softlib/software3/COL6537/pv-20048-1/SP26281.exe, which is a Windows driver package
- In an empty directory, use the Linux program
cabextractto unpack the archive:
cabextract SP26281.exe. Note: Most Linux distributions don't install
cabextractby default. Consult your packaging system or download it from its Web site.
dd if=driver/cx88enc.sys skip=27912 bs=1 count=262144 of=blackbird-fw-enc.binto extract the firmware from the Windows driver.
- Move the
/lib/firmwareor whatever other directory houses your firmware files.
- Some reports indicate that the
blackbird-fw-enc.binfile 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/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
Linux video capture interface: v2.00 i2c-core: driver [tveeprom] registered CORE cx88: 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] registered i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x50 i2c_adapter i2c-0: master_xfer W, addr=0x50, len=0 i2c_adapter i2c-0: master_xfer W, addr=0x50, len=0 i2c_adapter i2c-0: client [tveeprom] registered with bus id 0-0050 i2c_adapter i2c-0: master_xfer W, addr=0x50, len=1 i2c_adapter i2c-0: master_xfer R, addr=0x50, len=256 cx88/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: found at 0000:00:0a.0, rev: 5, irq: 17, latency: 32, mmio: 0xcc000000 tuner 0-0043: chip found @ 0x86 (cx88) tuner 0-0060: All bytes are equal. It is not a TEA5767 tuner 0-0060: chip found @ 0xc0 (cx88) 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: registered device video0 [v4l2] cx88/0: registered device vbi0 cx88/0: registered device radio0 cx2388x blackbird driver version 0.0.6 loaded cx88/2: found at 0000:00:0a.2, rev: 5, irq: 17, latency: 32, mmio: 0xce000000 cx88/2: cx23416 based mpeg encoder (blackbird reference design) cx88/2: registered device video1 [mpeg] cx88/2-bb: Firmware and/or mailbox pointer not initialized or corrupted cx88/2-bb: Firmware upload successful. cx88/2-bb: Firmware version is 0x02040120 cx88/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
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
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.
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/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
#!/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 184.108.40.206 and 220.127.116.11 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 18.104.22.168 and 22.214.171.124 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.