[linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

[linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

[Thierry LELEGARD]

Dear all,

I would like to report an annoying behavior difference between S2API and the
legacy DVB API (V3) when _reading_ the current tuning configuration.

In short, API V3 is able to report the _actual_ tuning parameters as used by
the driver and corresponding to the actual broadcast steam. On the other hand,
S2API reports cached values which were specified in the tuning operation and
these values may be generic (*_AUTO symbols) or even wrong.

Logically, it seems that the difference is located in the API and not in the driver.

Here is the configuration I test:

Kernel 2.6.35.10-74.fc14.i686 (Fedora 14)
Hauppauge WinTV-Nova-T-500 (dual DVB-T, DiBcom 3000MC/P)

I tune to a frequency and let many parameters to their *_AUTO value:
  DTV_TRANSMISSION_MODE
  DTV_GUARD_INTERVAL
  DTV_CODE_RATE_HP
  DTV_CODE_RATE_LP

The tuning is performed correctly and reception is effective. The tuner finds
the right parameters.

With API V3, after reading the frontend state (FE_GET_FRONTEND), the returned
values are correct. I can see that actual code rate HP is 3/4, LP 1/2,
transmission mode 8K and guard interval 1/8.

However, on the same machine, after reading the frontend state using S2API
(FE_GET_PROPERTY), all returned values are the *_AUTO values I specified
while tuning.

But there is worse. If I set a wrong parameter in the tuning operation,
for instance guard interval 1/32, the API V3 returns the correct value
which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API
returns the "cached" value which was set while tuning (GUARD_INTERVAL_1_32).

So, the driver is able 1) to find the correct actual parameter and 2) to
report this actual value since API V3 returns it.

But it seems that API V3 returns the actual tuning parameter as used by the
driver while S2API returns a cached value which was used while tuning.

This seems an annoying regression. An application is no longer able to
determine the modulation parameter of an actual stream.

As a final note, there is no difference if the tuning operation is performed
using API V3 or S2API, the difference is only in the reading operation
(FE_GET_FRONTEND vs. FE_GET_PROPERTY).

Best regards,
-Thierry

Re: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

[Andreas Oberritter]

Hello Thierry,

On 01/14/2011 02:35 PM, Thierry LELEGARD wrote:
> Dear all,
> 
> I would like to report an annoying behavior difference between S2API and the
> legacy DVB API (V3) when _reading_ the current tuning configuration.
> 
> In short, API V3 is able to report the _actual_ tuning parameters as used by
> the driver and corresponding to the actual broadcast steam. On the other hand,
> S2API reports cached values which were specified in the tuning operation and
> these values may be generic (*_AUTO symbols) or even wrong.

if that's still the case in Git (I didn't verify), then it should indeed
be changed to behave like v3 does. Would you mind to submit a patch, please?

> But there is worse. If I set a wrong parameter in the tuning operation,
> for instance guard interval 1/32, the API V3 returns the correct value
> which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API
> returns the "cached" value which was set while tuning (GUARD_INTERVAL_1_32).

That behaviour, however, is implementation specific and can't be relied
upon. In theory, the driver should always use the specified parameters,
unless set to *_AUTO. But there are cases like yours, where the driver
forces automatic detection of some parameters. This may or may not be
required by the underlying device.

Regards,
Andreas

Re: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

[Devin Heitmueller]

On Fri, Jan 14, 2011 at 8:35 AM, Thierry LELEGARD
<tlelegard@logiways.com> wrote:
> But there is worse. If I set a wrong parameter in the tuning operation,
> for instance guard interval 1/32, the API V3 returns the correct value
> which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API
> returns the "cached" value which was set while tuning (GUARD_INTERVAL_1_32).

This is actually a bad thing.  If you specify the wrong parameter and
it still works, then that can lead to all sort of misleading behavior.
 For example, imagine the next person who submits scan results based
on using such a driver.  It works for him because his driver lied, but
the resulting file works for nobody else.

If you specify an explicit value incorrectly (not auto) and it still
works, that is a driver bug which should be fixed.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

[Andreas Oberritter]

On 01/14/2011 04:12 PM, Devin Heitmueller wrote:
> On Fri, Jan 14, 2011 at 8:35 AM, Thierry LELEGARD
> <tlelegard@logiways.com> wrote:
>> But there is worse. If I set a wrong parameter in the tuning operation,
>> for instance guard interval 1/32, the API V3 returns the correct value
>> which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API
>> returns the "cached" value which was set while tuning (GUARD_INTERVAL_1_32).
> 
> This is actually a bad thing.  If you specify the wrong parameter and
> it still works, then that can lead to all sort of misleading behavior.
>  For example, imagine the next person who submits scan results based
> on using such a driver.  It works for him because his driver lied, but
> the resulting file works for nobody else.

Scan results should contain the input parameters, because the
transmission parameters can change any time (not included in any
official frequency sheet of the provider) and because some parameters
vary slightly with environmental influences (e.g. DVB-S frequency - i've
heard of that a lot and there's code to handle it in dvb_frontend.c, but
is it actually true?) and some might be read back too imprecisely to be
usable with a different chipset (e.g. symbol rate).

> If you specify an explicit value incorrectly (not auto) and it still
> works, that is a driver bug which should be fixed.

It's not possible to manually specify every single parameter or every
combination of parameters (i.e. some AUTO, some not) with all devices.

If you want to catch this, you'd have to compare the data read back to
the data from userspace to clear the lock status on mismatch, even if a
valid TS is being received. This would be worse, in my opinion. How much
tolerance would you allow for parameters that aren't enums, e.g.
frequency and symbol rate?

Albeit, DVB-SI data isn't perfect and misconfiguration at the
transmitter happens (e.g. wrong FEC values), especially where most of
the parameters are signaled in-band (e.g. TPS for DVB-T). It's a better
user experience if the reception continues to work, even if the user
didn't specify AUTO.

I'd rather understand non-AUTO parameters that way: "Try these first,
but if you want and if you can, you're free to try other parameters."

After all, most of the users tune to a mux in order to acquire a lock
and not to prove that there's no signal.

Regards,
Andreas

RE: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

[Thierry LELEGARD]

> -----Original Message-----
> From: Andreas Oberritter [mailto:obi@linuxtv.org]
> Sent: Friday, January 14, 2011 5:32 PM


> Albeit, DVB-SI data isn't perfect and misconfiguration at the
> transmitter happens (e.g. wrong FEC values), especially where most of
> the parameters are signaled in-band (e.g. TPS for DVB-T). It's a better
> user experience if the reception continues to work, even if the user
> didn't specify AUTO.

Exactly. In the French DVB-T network, there is no regional NIT, only one
common national NIT. As a consequence, all tuning parameters (frequency
but also FEC, guard interval, etc) are wrong in the terrestrial delivery
descriptors because for a given TS they are obviously not identical on all
transmitters. Moreover, these parameters change over time (many transmitters
recently moved from 2/3 - 1/32 to 3/4 - 1/8).

In such networks, nobody "knows" for sure the modulation parameters. This is
why it is a good thing that the tuners can 1) find the actual parameters and
2) report them to the application whenever it requests them.

> I'd rather understand non-AUTO parameters that way: "Try these first,
> but if you want and if you can, you're free to try other parameters."

Exactly, for the same reasons as above.

This is why the new behavior of S2API (compared to API V3) is quite unfortunate.
On a pragmatic standpoint, this is really a major step backward.

-Thierry

RE: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

[Thierry LELEGARD]

OK, then what? Is the S2API behavior (returning cached - but incorrect - tuning
parameter values) satisfactory for everyone or shall we adapt S2API to mimic the
API V3 behavior (return the actual tuning parameter values as automatically
adjusted by the driver)?

-Thierry

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-owner@vger.kernel.org] On
> Behalf Of Thierry LELEGARD
> Sent: Friday, January 14, 2011 5:44 PM
> To: linux-media@vger.kernel.org
> Cc: Devin Heitmueller; Andreas Oberritter
> Subject: RE: [linux-media] API V3 vs SAPI behavior difference in reading tuning
> parameters
> 
> > -----Original Message-----
> > From: Andreas Oberritter [mailto:obi@linuxtv.org]
> > Sent: Friday, January 14, 2011 5:32 PM
> 
> 
> > Albeit, DVB-SI data isn't perfect and misconfiguration at the
> > transmitter happens (e.g. wrong FEC values), especially where most of
> > the parameters are signaled in-band (e.g. TPS for DVB-T). It's a better
> > user experience if the reception continues to work, even if the user
> > didn't specify AUTO.
> 
> Exactly. In the French DVB-T network, there is no regional NIT, only one
> common national NIT. As a consequence, all tuning parameters (frequency
> but also FEC, guard interval, etc) are wrong in the terrestrial delivery
> descriptors because for a given TS they are obviously not identical on all
> transmitters. Moreover, these parameters change over time (many transmitters
> recently moved from 2/3 - 1/32 to 3/4 - 1/8).
> 
> In such networks, nobody "knows" for sure the modulation parameters. This is
> why it is a good thing that the tuners can 1) find the actual parameters and
> 2) report them to the application whenever it requests them.
> 
> > I'd rather understand non-AUTO parameters that way: "Try these first,
> > but if you want and if you can, you're free to try other parameters."
> 
> Exactly, for the same reasons as above.
> 
> This is why the new behavior of S2API (compared to API V3) is quite unfortunate.
> On a pragmatic standpoint, this is really a major step backward.
> 
> -Thierry
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-media] API V3 vs SAPI behavior difference in reading tuning parameters

[Andreas Oberritter]

On 01/19/2011 06:03 PM, Thierry LELEGARD wrote:
> OK, then what? Is the S2API behavior (returning cached - but incorrect - tuning
> parameter values) satisfactory for everyone or shall we adapt S2API to mimic the
> API V3 behavior (return the actual tuning parameter values as automatically
> adjusted by the driver)?

To quote myself:

if that's still the case in Git (I didn't verify), then it should indeed
be changed to behave like v3 does. Would you mind to submit a patch, please?

I haven't heard any objections, so just go on if you want. Otherwise I
might prepare a patch once time permits.

Regards,
Andreas