Hi, 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... Hartmut _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
