Em Thu, 17 Jan 2013 21:11:08 +0200 Antti Palosaari <crope@xxxxxx> escreveu: > On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote: > > Em Fri, 18 Jan 2013 00:07:17 +0530 > > Manu Abraham <abraham.manu@xxxxxxxxx> escreveu: > > > >> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@xxxxxx> wrote: > >> > >>> > >>> > >>> Resetting counters when user tunes channel sounds the only correct option. > >>> > >> > >> This might not be correct, especially when we have true Multiple Input Streams. > >> The tune might be single, but the filter setup would be different. In > >> which case it > >> wouldn't correct to do a reset of the counters ona tune. Resetting the counters > >> should be the responsibility of the driver. > > > > I moved the counters reset to the driver's logic on v11. I'm posting the > > patches in a few. > > > >> As I said in an earlier > >> post, anything > >> other than the driver handling any statistical event monitoring, such an API is > >> broken for sure, without even reading single line of code for that API for which > >> it is written for. > > > > Yes, driver should have full control on it. > > > >>> OK, maybe we will see in near future if that works well or not. I think that > >>> for calculating of PER it is required to start continuous polling to keep up > >>> total block counters. Maybe updating UCB counter continously needs that too, > >>> so it should work. > >> > >> > >> With multi-standard demodulators, some of them PER compute is a by-product > >> of some internal demodulator algorithmic operation. In some cases, it might > >> require a loop in the driver. As I said, again; It is very hard/wrong > >> to do basic > >> generalizations. > > > > Agreed. > > > > I think we will have soon kinda consensus everyone could approve! > Anyhow, I didn't liked that kind of PATCH RFC process. That change was > too big for PATCH style RFC and it was hard to keep track what going on > looking those patches. Maybe requirement specification RFCs first and > when requirements are clear => PATCH RFC for implementation. Works for me. > What I know understand, requirements are: > > signal strength: > ============== > Offer both discussed methods. > Simple [0...n] scale and dB... > Driver must support simple scale over dB. > > CNR (SNR) > ============== > Offer both discussed methods. > Simple [0...n] scale and dB... > Driver must support simple scale over dB. Yes. For simple scale, n = 65535 should be, as most drivers that use the simple scale use 0 to 65535 range. So, this range means less driver changes. > > BER > ============== > Offer global BER and per layer BER. > Measure is returned as two numbers, one for error bit count and one for > total bit count. > > uncorrected packets/blocks > ============== > Offer global UCB and per layer UCB. > Measure is returned as two numbers, one for uncorrected packet count and > one for total packet count. > > counter reset > ============== > counters are reset when channel is tuned > > And if we end up returning "simple" values over dB values, then I think > driver could be simple and implement only dB and dvb-core is responsible > to convert dB => simple. That should quite be possible as we know which > dB value is good signal and which is bad signal. > > > Are these requirements now in line what is spoken? Yes. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
