No subject

about applications it makes also sense to know in advance what are the
features that are supported by the backend or not.
Imagine you have a media player and a checkbox decides whether or not you
preroll, you would probably want to enable it only if the backend supports
this functionality.

Thierry

-----Original Message-----
From: Richard [mailto:richardmg at trolltech.com] 
Sent: mardi 10 juillet 2007 15:20
To: phonon-backends at kde.org
Subject: Re: API


> yes, but it's also connected to the source since you often want to
> enable/disable preroll depending on what source it is, like e.g. a  
> radio
> stream.
> ...
> Another one: when you stop a MediaObject will it preroll the  
> current source
> again so that a subsequent call to play() is immediate?

It sounds like there is no really clear answer to this, so it might  
be a good idea to let the user control it.

> If you setCurrentSource(someRadioStream) and preroll starts and  
> then you wait
> 5 min before calling play() what will you hear? 5min old stream?  
> current
> stream? was the stream going over the network and getting dumped  
> to /dev/null
> for the last 5 min then?

I know QT uses preroll to acquire all neccesary resources up front,  
and set up needed connections. So even for radio preroll makes some  
sense there, at least. I would say preroll in the case of radio means  
start the streaming as if you were playing, but 'mute' it.

> xinelib has no preroll concept so I have not really touched the  
> issue yet.

cool. We could do e.g:
bool MediaObject::setPreRollHint(bool preroll); // returns false if  
the backend can't handle it.

-Richard
_______________________________________________
Phonon-backends mailing list
Phonon-backends at kde.org
https://mail.kde.org/mailman/listinfo/phonon-backends