Hardware Support Using Linux TV Tuner Cards Hauppauge PVR 350 The PVR 350 is an analogue TV card with a built-in MPEG-2 encoder and decoder. The video data that comes from the tuner is fed directly into the encoder, which is then presented to the operating system as a /dev entry. The system then manipulates this MPEG stream – there is no way of getting the „raw‟ pre-encoded data. The MPEG-2 decoder is connected directly to the TV-out port of the card. There is no way to access the decoded data to eg. display on a monitor. To display a video stream on a TV, simply copy MPEG data to the /dev entry which represents the decoder. The TV-out can also be used as a framebuffer device, so you can display a console or even an X server on it. The PVR 250 model has the same encoder and tuner as the 350, but lacks the TV-out and decoder functionality. The drivers to control this board are available at http://ivtv.sourceforge.net/ Firmware is available from the Hauppauge site in the driver download section – it is in the Windows installer zip file and must be extracted via the ivtv „ivtvfwextract.pl‟ util. The files should then be placed in /lib/modules. The encoder is normally reliable, but if on the wrong kernel/motherboard combination it can give jumpy output which will eventually freeze. This will normally only happen when the decoder is in use at the same time. The decoder is not reliable. If on the wrong motherboard it will hang the machine within a second. When it works properly it may run for 20 minutes and stop working (not hang), or it may run indefinitely. This is not due to overheating: the card gets hot, but even with active cooling the results are the same. The decoder is far more likely to hang when running with MythTV. The TV-out has never hung when using it as a framebuffer The decoder rarely hangs when using it from the command line (as a pipe) Data can be piped directly from the encoder to the decoder using a line like “dd if=/dev/video0 of=/dev/video16 bs=64k”, or from a file like “cat test.mpg > /dev/video16” The decoded MPEG video is not visible when using it as a framebuffer, except when using MythTV as it overlays the (hardware decoded) video over the framebuffer display. CPU usage is close to 0% when using the hardware encoder and/or decoder. When the loadavg approaches ~1.2 (on a 1GHz Nehemiah) video starts to jump Video is not accessible via V4L compatible programs, but V4L is required in order to use the drivers. Hauppauge WinTV Primio-FM / PCI-FM These are two very similar cards based on the Conexant 2388x video decoder chips. They can receive analogue-only TV broadcasts and present the data using the standard V4L /dev entries. They have no TV-out or MPEG encoder/decoder. The difference between the two cards is that the Primio-FM has S-Video, composite, FM radio and coax TV inputs and the PCI-FM has just the FM and coax inputs. Standard TV programs like XawTV can be used with these cards but that is the extent of software support: these cards do not return data using the standard 24/32bpp RGB or 4:2:0 YUV packed pixel formats. As a result this makes it very difficult to stream data from them as most streaming systems do not have support for the odd chromas that the card insists on using. The drivers used are part of the bttv driver set available from http://linux.bytesex.org/v4l2/bttv.html, in particular the cx8800 drivers are required. bttv is also included in the 2.6 series kernel. Video can always be viewed using XawTV. Video can sometimes be captured via the V4L interface using FFMPEG (http://ffmpeg.sourceforge.net/), although often the program exits early as the card refuses to supply any video data. Although the card supports 4:2:2 YUV, if using VLC or VLS (http://www.videolan.org) and the card‟s chroma is forced to using I422 it refuses to supply any data. This makes programs like VLC and VLS useless. The card does not work with MythTV: the screen turns green and the cx8800 driver gives huge amount of errors in the syslog. The standard video chroma used by the card is RV24. Hauppauge WinTV Nova-T This is a terrestrial digital TV card. Support for DVB is available in the 2.6 series kernel and drivers and userspace tools are available from http://www.linuxtv.org. DVB-T transmissions are broadcast as an MPEG transport stream (TS) and each component (audio/video) of a TV channel is sent as an MPEG elementary stream (ES). To stream or save this broadcast nothing much needs to be done as the data is already in a compressed format. Technically, to make the data as compatible as possible for target decoders and players, the required TV channel needs to be converted from the broadcast TS to a TS containing just one channel (program ID) or converted to program stream (PS) containing a single video and audio stream. Neither card I received worked in the machine they were installed in. They did not show up in the BIOS‟ PCI listing and were declared DOA. Nebula Electronics DigiTV This is another DVB-T card. It uses the same drivers from the same site as the NovaT card. Userspace tools can be obtained from http://www.metzlerbros.org/dvb/index.html. The DVB kernel option must be selected (as a module or built-in) when compiling the kernel. The kernel module required for the base is dvb-bt8xx and for the frontend is nxt6000. The first thing to do is to find some channels with your DVB card. Run the scan program from the Metzler Bros site. You will need to tell it which transmitter you are receiving from. scan comes with a list of known transmitters – select the relevant one (Southampton can get Rowridge and Hannington). Once channels have been detected the tzap program can be used to lock on to a given TS and the channel can be extracted by selecting a given program ID from the mux by using dvbstream. Not all cards support hardware demuliplexing and some will only return the full TS for software-only extraction. Video can then be streamed and viewed using standard programs that support DVB: eg VLC, VLS, FFMPEG, MythTV etc. The first card I received was faulty, but the second card worked fine. Using VLC compiled for DVB support, it is possible to stream digital TV. First, the correct transponder must be tuned for the corresponding group of channels – eg in Southampton BBC is transmitted on 489MHz, but ITV/C4 is on 530MHz – by using tzap to lock onto a pid coming from the required transponder. Then VLC must be started using something like “dvb:// :dvb-adaptor=0 :program=4227” where 4227 is the program group representing the video and audio streams associated with the TV channel. Using VLC‟s DVB code, there is no support for interactive services like Teletext or “press the red button for…”. Also radio channels refuse to work. VLC refuses to play/broadcast audio for many channels – it seems to refuse the FOURCC „dvbs‟ but other times (eg for BBC2) it accepts it and audio works. This might be why digital radio does not work. However on some channels which refuse to process the sound, the sound can be transcoded to mpga (the original format) and can then be transmitted to clients. Video can be extracted from the TS using dvbstream, converted to a PS using ts2ps and then piped into something that accepts a regular MPEG-2 PS eg VLC. This only seems to work for some pids as most simply do not supply any video or audio, only the header data. Even though the card works similar to the PVR 350 by outputting an MPEG-2 stream, the card requires even less CPU time. Video can be streamed without jumps or artefacts on a 3GHz P4 with a loadavg >3.5. This may be because the processor is much faster. The card has a built-in demux. As a result this is not classed as a „budget‟ card by Linux. The bandwidth required by the video stream is normally lower than that of the PVR 350 – some require just 4Mbit/s compared with the 11Mbit/s of the PVR. VLS requires a special config file to use DVB. There is no spec of how this file should be formatted, so DVB was never tested with VLS. Motherboard Support VIA EPIA M 10000 This is a Mini-ITX motherboard with an embedded 1GHz VIA Nehemiah processor. It has a VIA CLE266 north bridge and a VT8235 south bridge. Features: Standard PCI bus with standard IDE and FDD controllers VIA TV6103 10/100 Ethernet PHY: use module via-rhine VIA VT1616 AC‟97 audio: use ALSA module snd-via82xx VIA VT6307S IEEE1394: use module ohci1394, also eth1394 for Ethernetover-IEEE1394 UHCI USB 2.0: use module uhci-hcd and ehci-hcd VIA Unichrome AGP graphics: there is no X server included with the XFree86 distribution that supports accelerated graphics via this chipset. The only working ones are generic vga/vesa. Instead an X server needs to be downloaded and built http://unichrome.sourceforge.net/ supplies one. Using the ~40meg download rebuilds the entire X install – this takes ~4 hours on a 600MHz EPIA or 1½ hours on the 1GHz Nehemiah. The results are a properly working X server with accelerated 2D video (no 3D support). MPEG-2 accelerator – as the CPU is too slow to comfortably decode MPEG streams, VIA included this MPEG-2 decoder on the motherboard to reduce the load on the processor. The problem is that there is little Linux support for this piece of hardware. TV-out: this is an extension of the VGA-out of the motherboard. Video can either go towards a CRT or to a TV. The default output and TV format can be selected from the BIOS. Problems: The CPU is slow. This causes problems for compiling and especially for decoding and encoding video. Compiling is slow on the 1GHz model, but not unbearably so. MPEG-2 decoding can take anywhere between 20% and 100% of CPU time, depending on whether or not the video is being rendered directly to the framebuffer or via the X server. There are DMA problems when used with the Hauppauge PVR 350. This is what makes the TV-out decoder on the card unreliable. VIA EPIA M 6000 This is the same motherboard as above but with a 600MHz Eden CPU from VIA. It is fanless, unlike the 1GHz Nehemiah. Problems: The CPU is very slow. The CPU does not run at 60% of the 1GHz Nehemiah, despite the clock speed. Compiling can take forever: the Unichrome X distribution took 4 hours to compile, MythTV took 1-2 hours, and the Linux kernel takes equally long. There is no chance of encoding video in real-time and MPEG-2 decoding can only just be achieved via direct rendering to the framebuffer. There are similar DMA problems to the M10000, except much worse. The PVR 350 cannot decode video for more than a few seconds without completely hanging the machine – the M10000 would never hang. Gigabyte 7VAXP-Ultra This is my motherboard, running with a VIA KT400 chipset and an Athlon XP 2700 processor. When running with the PVR 350 and the hard drive from the M10000, the hardware decoder on the PVR350 never crashed or hung – it worked exactly as it should do. Shuttle ST62 This is the motherboard that comes with the Shuttle XPC ST62K. It has a 3.0GHz Pentium 4 „Prescott‟ CPU (with Hyper-Threading) and for this processor it requires DDR400 RAM. The case is very well made as is much easier to install than the MiniITX system. Features: Pentium 4 processor with Hyper-Threading – when running Windows 2003 Enterprise Server the machine would lock up every few minutes until the HT was disabled in the BIOS. There was no (apparent) problem with Linux using the HT and an SMP kernel. ATI RS300 north bridge and ATI IXP150 south bridge Realtek RTL-8100C 10/100 Ethernet PHY: uses the 8139too kernel module. There is a conflict with the sound chip though. ATI USB controller (unknown chip): uses the ohci-hcd and ehci-hcd modules VIA IEEE1394 controller: uses the ieee1394 (and eth1394) modules ATI Radeon 9100 IGP AGP video controller: apparently there is support with X.org X11R6.7.0 but this was never tested. The XFree86 4.4 „radeon‟ driver never worked with the video modes given in the XF86Config file and displayed every resolution with a vertical frequency of 120Hz, regardless of the capabilities of the monitor (or TV). Thus the only resolutions „usable‟ on my Dell 1025HE are 640x480 or 800x600 (only just). The ATI closed-source driver failed to detect a compatible chipset when the install program was run and refused to be forced to use the 9100 IGP chipset. The solution was to use the Radeon framebuffer X server, although there are limitations and performance hits as a result of doing so. Realtek RTL-ALC650: this is an AC‟97 compatible sound chip and should be autodetected by ALSA. Instead it isn‟t, so a driver must be installed manually. There is a kernel module responsible for this chip „snd-atiixp‟, but when inserted into the kernel it dumps huge amounts of errors into the syslog. Then the network interface goes down… Windows support for this chip (via a driver from the Shuttle site) is fine however. This motherboard was also incompatible with the PVR 350‟s MPEG-2 decoder. It would hang the whole machine within a second of use, even when used from the console. ICP Vortex Computersysteme GmbH SCSI RAID card This is a 64-bit PCI SCSI RAID card. It supports RAID-0 through -5 and -10. As this is from a German manufacturer, all the manuals come in German. When connected to a group of drives for the first time, they must be configured to work as a RAID array. First boot off the CD (you cannot use the „F2 for BIOS‟ option yet) to install the RAID BIOS on the drives and then set up the drives as a RAID array. When compiling a new kernel, the gdth module must be selected. In the menuconfig program this is listed as “Intel/ICP (former GDT SCSI Disk Array) RAID Controller support”. When running with the 2.4.21-4.ELsmp kernel that comes with Red Hat EL AS performance is poor, giving ~20MB/s in RAID-0 mode (striped). When running a hand-crafted 184.108.40.206 kernel and the same RAID-0 array 50-90MB/s can be achieved.