In message <1a297b360703180613p51a82364we3fcc6e8efb9f161@xxxxxxxxxxxxxx>, "Manu Abraham" wrote:
>On 3/18/07, Darron Broad <darron@xxxxxxxx> wrote:
lo
>
>> I can't even see why you would need to even set the delivery
>> type to query the delivery parameters.
>
>
>If the delivery parameters are the same, i don't see why you need an
>API update and all the hell, if it had just the same delivery
>parameters. ;-)
i didn't say you should not specify the delivery type when
querying, just not set it.
the cx24116 driver as it stands may return one of two static
structures when get_info is called.
it makes no point to me to query for this detail prior to
every set_params, hence, setting internal state on get_info
is asking for problems, however, setting the delivery path
on set_params does makes sense.
>For multistandard devices, capabilities are different due to the
>different demodulator cores on the relevant chip (for
>dvb-s/dvb-s2/dss), whether it be vendor X or Y, it is indeed
>implemented that way only. And the basics specs just talks the same.
>
>This is due to the fact that the DVB-S2 DSP core is different from the
>DVB-S/DSS DSP core, as mentioned in the DVB-S2 specs
>
>Usually, the Viterbi decoder will be on another separate core from the
>demodulator
yes, but one question, why doesn't the multiproto driver aggregate
demods? I can see it handling multiple protocol on one physical device,
but this doesn't extend to cards that contain multiple physical demods
yet with only the one bus path, such as the hvr4000?
cya
--
// /
{:)==={ Darron Broad <darron@xxxxxxxx>
\\ \
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
