[linux-dvb] [RFC] Should a DVB frontend report the board name?

Hartmut Hackmann hartmut.hackmann at t-online.de
Sat Feb 10 01:07:21 CET 2007


CityK schrieb:
> Hi Manu,
> Manu Abraham wrote:
>> ..snip..
>> So the concept of a frontend /nim/dc receiver are all names which are
>> used in different contexts for different categories of devices. But it
>> is quite hard to draw a distinct line, in such a case. It could be
>> argued either ways.  (Just like painting the bikeshed green) 
> True enough.
>>>> frontend = demod name (that's what we have currently),
>>> And that would technically be wrong ... although if it works into the
>>> coding framework, then so be it.
>>>> Tuner is unimportant in this case as it doesn't have much of ops.
>>> I'm not certain what you mean by "ops", but I gather that its minor role
>>> is what has lead to the project's definition of frontend to equal demod
>> The project has never stated that at any place. Or is there ?
> Not that I know of -- I was just surmising that by what you wrote i.e.
> "frontend = demod name (that's what we have currently)"
>> But i don't understand what your argument is -- for example when i
>> have a "tuner module" (tin can inclusive of the demod) say one based
>> on a STV0299, what advantage do you get by telling the user that it
>> uses a TSA5059 PLL in the RF stage ?
> My point, as I mentioned I at the very beginning, wasn't related to the
> central premise. 
> I  understand that your argument in the discussion proper is: give the
> component name in it's own relevant place and not in the frontend code.
> What I had interjected was a sidebar, based largely upon your words of
> "frontend = demod name (that's what we have currently)".  I thought it
> might be prudent to address this secondary point.  In particular, it
> sounded like the project's definition of what constituted a frontend was
> a little constrained or limited in scope.  I thought perhaps some
> discussion was warranted.  I'm satisfied by your explanation.
>>> Lastly, as some food for thought -- we're already starting to see the
>>> move towards multi-purpose IC's.  Examples:
>>> - Xceive 3028 tuner and analog demod;
>>> - ATI theater 650 analog demod, A/V decoder & mpeg encoder.
>>> It likely will be a few years yet, but pretty soon we WILL run into the
>>> case where the traditional frontend and "backend" components on the DTV
>>> devices merge into one IC.  How then does one define the abstraction?
>> even though the entire thing is in one chip, it is an abstraction, so
>> it doesn't matter whether the MPEG decoder and the demodulator are on
>> the same chip. Still they are separate functional blocks requiring
>> separate control (You can't ask a MPEG decoder to do some job on a RF
>> signal)
>>> At that point, the concept will only refer to the relevant processing
>>> stages carried out in that single IC.
>> IC  = Integrated Circuit. Integration doesn't mean that you loose
>> control. Of course noise is added into the system. The greater the
>> integration the greater the noise, in a constant environment.
> Yes, I agree of course.   But I think you missed what I was driving at. 
> This section, which wasn't expressed well, was also related to my
> sidebar point, and not to the discussion proper -- specifically, I was
> directing commentary as to what a frontend should be defined as, and how
> it should be treated.
>>> Will this solution account for a single, multifunctional IC, as I have
>>> just described?
>> Why not ? look at the MB86A15/16 (tuner + demod in a single chip in
>> that sense)
> Okay.
> In case it wasn't clear (and it really wasn't :) ! ) I had switched
> gears here and was expressing concern, just as Hartmut and a few others
> had, in regards to "naming conventions which are useful for the average
> user".  As I said, I completely understand your argument: give the
> component name in it's own relevant place and not in the frontend code. 
> But as I also prefaced at the start of the message, I don't think
> everyone was on the same page.  I believe that the other prevailing
> point of contention was not so much as to whether having the demod name
> listed in the frontend output, but rather whether information relevant
> to the average user is being conveyed as a whole.
> My hypothetical example of a multifunctional, single IC was meant to
> exemplify this point .... although I think I trailed off with my train
> of thought.  Anyway, not to worry.
> Cheers
I understand the "give the component name in it's own relevant place and
not in the frontend code" but the point is: there is no such place!
And we can't easily create one because this would mean a API change -
IMHO this is not an option.
And the information is useless if it isn't reported to the user space.

Just my opinion...

More information about the linux-dvb mailing list