CityK wrote: > Boleslaw Ciesielski wrote: >> There are some people who have it working but that's a small >> minority. For most people QAM is a no go and it does seem like a >> hardware issue. (Could it be QAM64 vs QAM256?) > We know the Nxt2002 can perform QAM, just not 100% reliably. I > suspect that MIT, being fully aware of the limitations imposed by the > Nxt2002's internal SRAM configuration, reasoned not to release > drivers that supported such function and instead just provided an OTA > solution. So, it is with this thought in mind, I suspect that as the > (recently resumed) MyHD driver progress, that project will discover > that it can provide QAM functionality for the MDP-120 under > Linux....albeit, not a 100% reliable solution, given the limitation of > the demodulator. I was thinking about this again yesterday. In respect to the Air2PC/Nxt2002 cards, I'm wondering if there is a correlation between success or failure with QAM sources and the users' CPU horsepower. Consider the comments by Geoffery Reynolds in that AVS thread that I linked to earlier: "When we first got the application and driver source code, one of the team members took a stab at adding QAM support. If only for a little more memory on board, it probably could have been done - he was able to get it to work with (in the clear) QAM64 channels, but not QAM256 due to the limited memory. There were also issues with recording QAM stations as it's more data to send over the PCI bus than 8VSB, but I suspect there may have been ways to deal with that if more memory had been present.........I don't remember all the specifics, but IIRC, there's some give and go between the NXT2000 chip having memory on board combined with the 16MB versus the newer NXT200x chips having more memory on board or something like that. I'm not a hardware guy at that level, so don't know all the specifics, but do know the problem was definitely related to limited available memory. The bottom line is that QAM support on accessDTV, MyHD MDP-100, and MyHD MDP-120 doesn't appear to be possible. Quite a bit of work was put into attempting to get it to work in the accessDTV drivers (including some attempts at hardware modifications) - it was close but no go." To me, this seems to suggest that the problem with the MDP-120 is that the Nxt2002's FIFO buffer isn't large enough to contain or hold incoming data while earlier packets set downstream are processed by the TeraLogic MPEG decoder (either for immediate decoding or routing the TS off the card for storage). In other words, there seems to be a mismatch between the buffering capabilities of the Nxt2002 and the processing power (for either decoding or bridging) of the TL880. Now, lets remove the fixed processing power of the TL880 out of the equation and instead take a look at the scenario of Nxt2002 based Air2PC "software" decoding cards. Is it a case that host processors (that are several times faster then the TL880!) are able to overcome the limitation of the Nxt2002's buffer (and latency introduced by streaming over PCI-to-host) and process the packet streams fast enough that there is no overrun occurring backup stream in the Nxt2002? Perhaps there is a certain set point in host processing power that would overcome deficiencies seen in other Nxt2002-CPU combinations of less prowess. This may explain why some Air2PC users are successful while others are not as fortunate in attempting to receive QAM source signals. Thoughts? --Cheers, CK
