On Mon, May 31, 2010 at 8:55 AM, Igor Stoppa <igor.stoppa@xxxxxxxxx> wrote: > ext Felipe Contreras wrote: > >> I think this information can be obtained dynamically while the >> application is running, > > yes, that was the idea > >> and perhaps the limits can be stored. It would >> be pretty difficult for the applications to give this kind of >> information because there are so many variables. >> >> For example, an media player can tell you: this clip has 24 fps, but >> if the user is moving the time slider, the fps would increase and drop >> very rapidly, and how much depends at least on the container format >> and type of seek. >> > > I doubt that belongs to typical QoS. Maybe the target could be to be able to > decode a sequence of i-frames? I'm not sure what you mean. I-frames comes usually one per second, so if you only decode I-frames, your experience would be really bad. Moreover, you don't know beforehand when an I-frame is coming, only when it's there, and some clips can have only one I-frame at the beginning. >> A game or a telephony app could tell you "I need real-time priority" >> but so much as giving the details of latency and bandwidth? I find >> that very unlikely. >> > > from my gaming days the games were still evaluated in fps ... maybe i made > the wrong assumption? Yes, the more fps, the better, but you calculate that by counting the amount of frames rendered over a period of time; you know the fps *after* the fact. > A telephony app should still be able to tell if it's dropping audio frames. Yes, which could be unrelated to PM, like bad network conditions, but yeah, it should also be able to tell if the problem is with the application itself (audio decoder too slow). > In all cases there should be some device independent limit - like: what is > the sort of degradation that is considered acceptable by the typical user? It is easy to tell after the PM actions have been made, as in "wait! I'm not able to perform gimme more power!". But I don't see how that could be done _before_ the PM actions are done. >From all the QoS proposals I have seen here, and considering that some people said that suspend blockers could be a specific case of QOS, I don't think people have been considering QoS as something to state _after_. > Tuning might be offered, but at least this should set some sane set of > defaults. Huh? Defaults in what units, based on what, and when and how to update? Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
