Difference between revisions of "AVerMedia M150-D"
(→Issues and Problems: (updates concerning 2-week testing of channel-change script)) |
m |
||
Line 136: | Line 136: | ||
In theory, you should be able to use an AVerMedia AVerTV M150-D card as a software encoding device by telling <code>mythtv-setup</code> to use <code>/dev/video0</code> as a frame grabber. Such a use will require you to load the <code>cx88-alsa</code> driver, which provides ALSA device files to access the video card's audio stream. I haven't tested this approach in more than a half-hearted way. It didn't work for me, but I might have missed something. | In theory, you should be able to use an AVerMedia AVerTV M150-D card as a software encoding device by telling <code>mythtv-setup</code> to use <code>/dev/video0</code> as a frame grabber. Such a use will require you to load the <code>cx88-alsa</code> driver, which provides ALSA device files to access the video card's audio stream. I haven't tested this approach in more than a half-hearted way. It didn't work for me, but I might have missed something. | ||
− | 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. | + | 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]]. |
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. | 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. |
Revision as of 06:02, 29 April 2007
AVerMedia M150-D | |
Vendors Website | http://www.aver.com |
Input Formats | not applicable |
Support Status | Supported in MythTV 0.20 (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. AVerMedia also makes other cards, such as the AVerTV Studio and the M179, which require different drivers and installation procedures from those described here.
Contents
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:
- 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
cabextract
to unpack the archive:cabextract SP26281.exe
. Note: Most Linux distributions don't installcabextract
by default. Consult your packaging system or download it from its Web site. - 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. - Move the
blackbird-fw-enc.bin
file to/lib/firmware
or whatever other directory houses your firmware files. - Some reports indicate that the
blackbird-fw-enc.bin
file must be renamedv4l-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, can use the firmware provided with the IVTV drivers. These drivers failed on my system in initial tests (see the "Issues and Problems" section).
Verifying Driver Installation
Once you've finished installing the drivers, 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 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/video0 > 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.
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
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. A little experimentation revealed a workaround: Specify a custom channel-tuning script in the mythtv-setup
program. I'm currently using the following script:
#!/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
In theory, you should be able to 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. I haven't tested this approach in more than a half-hearted way. It didn't work for me, but I might have missed something.
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.
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. If you experience this problem, try specifying a separate channel-tuning command, as described earlier, in the "MythTV Configuration" section.
The card seems to have problems changing channels in MythTV's live TV; 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.
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's most serious problem is its unreliability; in tests with 2.6.19.1 and 2.6.19.2 kernels, the card is mostly reliable, but sometimes produces 0-length recordings. 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.
This card is quirky enough that it may not be the safest choice for a primary MythTV tuner; 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; you may need to use a 2.6.19 kernel rather than a 2.6.20 kernel.
Relevant Links
Related AVermedia products:
- The AVerMedia_M179 was an earlier MPEG-2 card from AVerMedia
- The AVerMedia AVerTV HD A180 is an HD (ATSC/QAM) card from AVerMedia
Additional wiki entries:
External links: