On Tue, 2 May 2006, Manu Abraham wrote:
> Trent Piepho wrote:
> > On Tue, 2 May 2006, Manu Abraham wrote:
> >> No, since it is part of the spec and not having anything to do with the
> >> driver as it is. Some drivers return this explicitly as part of register
> >> settings , not all drivers do comply.
> >>
> >
> > Why aren't there other enums for constants found in section data? What makes
> > modcod special?
> >
> >
> Huh ? You want to add demux specific things into the frontend ?
I wouldn't. frontend.h is describes the kernel -> user space interface,
right? No ioctls or structures in that interface use the modcod enum. So why
is it there? It's part of the DVB-S2 spec, sure. But there are tons of other
constants for DVB-S2 and ATSC that aren't defined in frontend.h.
For instance, "annex B" ATSC digital cable has a control word that encodes
which interleaver will be used. It's in SCTE 07 2000, but nothing in the in
kernel DVB API uses it, so there is no enum for it.
Now if you planned to add a DVB-S2 specific ioctl that used modcod as a
parameter, then the definition of modcod in frontend.h is obviously necessary.
Absent such an ioctl, IMHO the definition of modcod in frontend.h serves no
purpose.
> >> The driver has to choose the relevant modulation. Modulation Auto is
> >> used in the case where the hardware can tell the driver whether it can
> >> support the same. Or the driver is capable. Current single standard
> >> (delivery system) drivers/hardware do not support this.
> >
> > So what you are saying is that the ability of some demodulators to
> > automatically detect the QAM constellation will no longer be supported?
> >
>
> No. You mean, you want to add QAM_AUTO, PSK_AUTO etc ? Ok, i will add
> MOD_"MODTYPE"_AUTO, if it is useful.
Without something extra, what should the or51132 specify in the caps?
With the spec as is, I would guess this:
caps.delsys.atsc.modulation = FE_MOD_VSB8 | FE_MOD_QAM64 |
FE_MOD_QAM256 | FE_MOD_AUTO;
So, when a program gets this information on the caps, what does it mean?
There is no API specification with a clear definition of what FE_MOD_AUTO
means, but I'll assume it means that the frontend can switch between
all of the other modulation types it supports.
So (FE_MOD_VSB8|FE_MOD_QAM64|FE_MOD_QAM256|FE_MOD_AUTO) means the
frontend can auto switch beteen 8-VSB, 64-QAM, and 256-QAM. But this is
wrong! That is not what the fronend can do!
In order to be able to define any auto abilities accurately, you would
probably need to make the modulation capabilities an array. Like this:
caps.delsys.atsc.modulation[]={ FE_MOD_VSB8|FE_MOD_QAM64|FE_MOD_QAM256,
FE_MOD_QAM64|FE_MOD_QAM256|FE_MOD_AUTO,
0 };
The first entry without, which doesn't have AUTO, specifies all the
individual modulations that can be set. The second has just
64-QAM and 256-QAM, with the AUTO bit. This means that the
frontend can auto switch between these modulations. The final 0
indicates the end of the list.
This is probably much too complex to use. So, I suggest just adding something
like FE_MOD_QAM_AUTO, that means the front-end supports auto switching between
all the QAM modulations it lists as supported. This isn't as general. You
couldn't describe a frontend than auto switch between 64-QAM and 256-QAM, OR
between 512-QAM and 1024-QAM, but not between all four. You couldn't describe
a frontend than can auto switch between COFDM and 64-QAM, and also supports
Q-PSK but can't auto switch between Q-PSK and COFDM/64-QAM.
Of course all those unhandled possibilities are just possibilities, there may
never be any hardware that works that way. FE_MOD_QAM_AUTO is enough to
handle real existing hardware abilities as well as the currect API.
> > I don't think ATSC supports multiple fec rates? It only allows for 2/3.
I checked SCTE 07 2000, and ATSC digital cable uses different FEC rates.
QAM-64 uses 14/15 and QAM-256 is 19/20, but only these rates are supported.
So adding a fecrate field to the ATSC parameters is probably bad idea. Only
once fec rates per modulation is supported, but it's different for each
modulation. The unused 16-VSB high data rate mode specified in A/53 uses a
1/1 code ratio (it doesn't use Trellis coding).
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
