Freeview DVB-T

So I finally bought a KWorld/VStream XPert DVB-T card and put into into my master backend.

I chose the V-Stream card based on reputation in the MythTV lists and it's status at the linux v4l wiki. Oh, and recent models also have a good quality Samsung tuner. However, it still came as a shock to find the card fully autodetected on first-boot after installation. This was with a stock 2.6.12 FC3 kernel.

The card came with a very small antennae and the usual remote. I've tried using the supplied aerial in an upstairs room but the signal strength from the Crystal Palace transmitter 40Km away isn't strong enough. It's just about ok for testing but not good enough for a production system. This was expected.

I've plumbed it into Myth and have done some basic testing. I have a couple of weak channels displaying directly in PS mode on the PVR350. This is nice. Other channels don't display so well and I'm not sure if this is signal strength and/or problems with one of the DVB muxes or problems with the TS->PS translation. Using TS mode directly seems to force the stream into some non-mpeg2 format that causes the 350 to display it using Xv/X11 rather than directly as an mpeg stream. This is not so nice!

Of course, all of this needs a lot more testing and I need to get my master backend installed in the loft so that I can sort out a proper aerial...

Tuning the Shuttle BIOS

In an effort to squeeze a little more out of the my shuttle hardware (without increasing the heat output), I dived into the BIOS again.

This time, I was looking at memory issues. I was hoping to speed up memory access a little and find out why my 512Mb memory stick was only delivering 480Mb of usable RAM.

The size issue was due to the onboard ATI graphics stealing system RAM for it's framebuffer. The default setting is 32Mb and the minimum is 8Mb. I'm not using the onboard graphics for anything other than a virtual console which only needs a few kb of RAM. Reducing the 'UMI framebuffer size' (SP?) to 8Mb changed my usable memory from 479728k to 504176k. Useful.

With the speed issue, I tried playing with RAM timings and managed to reduce the latencies from 3-3-4-8 to 3-3-3-7. Anything less would cause a failure during extended testing with memtest86 or caused the shuttle to fail completely, requiring a BIOS reset.

While I was in the BIOS, I also tried lowering the CPU core voltage again. The default for my Celeron D is ~1.32v. I tested 1.2v and 1.1875v, both of which worked reliably under extended stress testing. I've left it at 1.1875v and I'll monitor the effect it has on heat output and assess long-term stability...

One last thing - ever since I've had it, my shuttle has exhibited a boot problem - it often fails to boot from cold, requiring perhaps one or two resets to get going. I think I might know why... While I was playing around, I noticed on 2 occassions that the BIOS had auto-detected the wrong FSB speed (166MHz instead of 133MHz) and was reporting my CPU as 3.15GHz w/ 664MHz internal FSB rather than 2.53GHz w/ 533MHz. That degree of inadvertent overclocking, without the corresponding voltage increase and cooling management is not going to work! I've now hardcoded the BIOS settings for FSB and memory speed to 133MHz and DDR-400 respectively.

Xv support on the PVR350

The PVR350 X driver didn't used to support the Xvideo extension that video players such as xine, mplayer and realplayer try to use. Instead, display was limited to using standard X11 or Xshm which was just too slow/inefficient to display video in realtime.

Having spent a considerable amount of time testing and debugging the new Xv support for the 350, I'm happy to say that it's now working really quite nicely.

Initially, I saw problems with MPEG recordings when simultaneously watching video via the YUV decoder. The MPEG encoder appeared to drop frames with the resulting video looking (and sounding) like it was speeded up. Increasing the MPEG encoder buffer size from the 4Mb default to 8Mb (as suggested by John Harvey, author of the X driver) cured the problem. However, that started triggering buffer allocation problems, so I reverted to using static buffer allocation in ivtv, ie. where all of the codec stream buffers are allocated on module load rather than allocated and freed on-the-fly.

Here are my Xv-friendly ivtv module options:

# buffer stuff to help simultaneous YUV decode/MPG encode
options ivtv mpg_buffers=8 dec_yuv_buffers=4 ivtv_dynbuf=0

So, using the changes above with 0.3.7c ivtv driver and the latest X driver allows me to play DVDs and watch pre-recorded AVI and QT video. mplayer started causing me problems during testing and I switched to xine. They may well both work fine but I've stuck with xine for now.

Some videos still show a few dropped/discarded frames and I'm trying to figure out if there is any further optimisation I can make to cure this. Additionally, there is also occassional 'frame stalls' which show as a subtle jerkiness in panning movement, however DVD straight off the disc is now almost pefect. If only I could get the digital audio out working on my Shuttle...