PaulR said:
I think it has plenty of processing power; it must have to be able to record two HD streams at once whilst playing a third pre-recorded HD programme.
Well, most of the image and audio processing stuff these days is done in hardware, ie. the DCT for MPEG decoding is on-chip straight to the image buffer. The actual transfer from hard-disk to memory and back is usually via DMA, with the CPU only involved in setting up the transfers and the decoding.
This of course all varies from chipset to chipset, and with price of chipset. Less special-purpose hardware means more work for the CPU to implement certain functions (and less time for user responsiveness). On the other hand, high-end boxes can even have multiple cores etc, just like PCs, allowing the application to run on one core, while the hardware is managed by the other.
So with the Humax box not exactly being cheap, I would care to speculate that it has quite a bit of hardware automation to do the recording and playback.
PaulR said:
The slowness in channel changing (and I don't think it's THAT bad) must be down do programming. What does take time is responding to button presses and it always seems to have suffered from this.
You do have a point - but whose programming? Box designer? Chipset manufacturer? Application programmer?
The lowest time delay incurred by changing channel is the basic cost of re-tuning. This includes setting the tuner to the new frequency, locking on to the transport stream, and demuxing the elementary streams that make up the audio and video, and feeding those to the decoders. This penalty is induced by the hardware/lowest firmware. Hard to do anything about this.
A little bit of cleverness can optimise the channel change, e.g. if changing channels within a transport stream (say, from BBC1 to BBC2), you can skip the tuning and locking step, and just change the elementary streams making up the new service. In theory, you can reduce the channel change time to the time until the next I-frame in the stream.
Similarly, if you have two available tuners, you can "cue" the other tuner to the next channel up in the channel list, so that it's already tuned when you decide to go one step further. This is a bit like double-clutch automatic gearboxes in e.g. VAG cars.
Combining the two can give quite good results. However, if the other tuner is busy, and you do change between services on different muxes, the delay will be more noticeable.
The actual control of channel change is often implemented in the box-specific middleware libraries that control the chipset and peripheral devices. These are often ports of the chip-set manufacturer's standard libraries provided with the license for the chip-set. The libraries provided are not meant to be super-optimised, but are more provided as reference. They are also written for generic designs, so that e.g. dual-tuner designs are not necessarily handled without some adaptation of the code. And that's what cost money.
The FoxSat, however, has a reasonable performance, leading me to suspect that they do employ some tricks in their firmware. For example, if recording two channels that happen to be on the same transport stream, it seems to use the same tuner for the two, as I can watch a third channel sometimes.
The real answer to fast channel changes is to have always have three tuners to watch live TV, so that you even in worst case can always go up and down at your leisure (tuner 1 on the channel you just left, tuner two on the current, and tuner three on the one up from here). Then you'd want to have at least one or two more tuners to record stuff while you watch other things.
The problem is, all extra goodies costs money, and STB design is a careful exercise to balance cost and benefit. Saving $15 on a tuner, or even $2 on less RAM means a lot when you sell millions of boxes.
Sorry for the rant. I get carried away some times...
