Am Donnerstag, den 11.09.2008, 08:51 -0400 schrieb Steven Toth:> hermann pitton wrote:> > Am Mittwoch, den 10.09.2008, 22:59 -0400 schrieb Steven Toth:> >> hermann pitton wrote:> >>> Hi,> >>>> >>> Am Mittwoch, den 10.09.2008, 21:00 -0400 schrieb Steven Toth:> >>>> Christophe Thommeret wrote:> >>>>> Le Thursday 11 September 2008 00:59:31 Andreas Oberritter, vous avez écrit :> >>>>>> Hans Werner wrote:> >>>>>>>> So applications could know that these 2 frontends are exclusive.> >>>>>>>> That would not require any API change, but would have to be a rule> >>>>>>>> followed by> >>>>>>>> all drivers.> >>>>>>> Yes, if we keep to that rule then only frontends which can operate truly> >>>>>>> simultaneously should have a different adapter number.> >>>>>> An adapter refers to a self-contained piece of hardware, whose parts can> >>>>>> not be used by a second adapter (e.g. adapter0/demux0 can not access the> >>>>>> data from adapter1/frontend1). In a commonly used setup it means that> >>>>>> adapter0 is the first initialized PCI card and adapter1 is the second.> >>>>>>> >>>>>> Now, if you want a device with two tuners that can be accessed> >>>>>> simultaneously to create a second adapter, then you would have to> >>>>>> artificially divide its components so that it looks like two independant> >>>>>> PCI cards. This might become very complicated and limits the functions> >>>>>> of the hardware.> >>>>>>> >>>>>> However, on a setup with multiple accessible tuners you can expect at> >>>>>> least the same amount of accessible demux devices on the same adapter> >>>>>> (and also dvr devices for that matter). There is an ioctl to connect a> >>>>>> frontend to a specific demux (DMX_SET_SOURCE).> >>>>>>> >>>>>> So, if there are demux0, frontend0 and frontend1, then the application> >>>>>> knows that it can't use both frontends simultaneously. Otherwise, if > >>>>>> there are demux0, demux1, frontend0 and frontend1, then it can use both> >>>>>> of them (by using both demux devices and connecting them to the> >>>>>> frontends via the ioctl mentioned above).> >>>>> Sounds logical. And that's why Kaffeine search for frontend/demux/dvr > 0 and > >>>>> uses demux1 with frontend1. (That was just a guess since i've never seen > >>>>> neither any such devices nor comments/recommendations/rules about such case).> >>>>>> >>>>> However, all dual tuners devices drivers i know expose the 2 frontends as > >>>>> frontend0 in separate adapters. But all these devices seems to be USB.> >>>>>> >>>>> The fact that Kaffeine works with the experimental hvr4000 driver indicates > >>>>> that this driver populates frontend1/demux1/dvr1 and then doesn't follow the > >>>>> way you describe (since the tuners can't be used at once).> >>>>> I would like to hear from Steve on this point.> >>>>>> >>>>>> >>>> Correct, frontend1, demux1, dvr1 etc. All on the same adapter. The > >>>> driver and multi-frontend patches manage exclusive access to the single > >>>> internal resource.> >>>>> >>> then please explain what is about the analog usage, which can always be> >>> first and don't tell it has to stay back, since you always sit on that> >>> bridge and else come nowhere ...> >> Hermann, I'm not sure I understand your question, but I'll try.> >>> >> This has nothing to do with analog, I never suggested these patches > >> effected analog.> >>> >> Either you're confused, or I am :)> >>> >> The multifrontend patches are related to DVB only, the analog ports on > >> the cx88 remain untouched, unchanged.> > > > Steve,> > > > likely we should have all some sleep previously again.> > Hermann, I have problems trying to understand your written English, I do > not always understand what you write. This leads to confusion. Sorry, let me know if you have any further question about the MedionQuad or any other multiple frontend device on the saa7134 and I try toanswer it taking more care on my English. > > > > But I'm quit sure what I'talking about.> > Of course you do, I never suggested that you were not.> > > > > If using the dma engines of the saa713x at once, you can't say analog> > and dvb are not related!> > Oh, I understand the topic you are mentioning now.> > I have no experience with the 7134 and I'm not aware of it's hardware > capabilities, or lack of. I'm not fit to comment on what resources can > be shared and the implications of.> > What I can say with confidence, is that if it has a digital transport > port, and if some of the cards share this port with DVB-T and DVB-S then > the multiple-frontend patches will probably help with those designs. > Rather than having to specify DVB-T or DVB-S during module load time, > the patches will negotiate user access and allow both to be present.> > This may be a good feature for the 7134, it may not. Yes, for sure it will be and no additional problems with dma throughputwill appear. If kaffeine knows what to do and keeps the same usabilityas it is discussed. > > There are clear restrictions and you can cause major dammage ignoring> > them.> > Nobody is ignoring them, thank you for raising the issue.> > - Steve> Hopefully you have lots of testers and contributors and I will be one ofthem as soon I find time. I did test the latest multiproto so farwithout issues. The point I try to raise for your testers is to keep in mind, on thesaa7134 they can use analog inputs from tuners or external sources withDVB-T/S at once, but only if the analog feed is using packed formats. For example mplayer/mencoder uses a planar format by default.This will lead to a corrupted recorded file and in worst case to filesystem corruption, if used with DVB at once. Hartmut considered once to disable all planar formats because of that, but we don't have a solution yet and people should be aware. Means also, if a capture in a planar format is already running foranalog inputs, no DVB will come through. There is no priority handling, notification or anything yet and I justpoint to it again. Cheers,Hermann _______________________________________________linux-dvb mailing listlinux-dvb@xxxxxxxxxxxxxxx://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
