Summary: | Magical Switching of Phonon Engines | ||
---|---|---|---|
Product: | kdemultimedia | Reporter: | min <mihnea_capraru> |
Component: | general | Assignee: | Multimedia Developers <kde-multimedia> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
min
2006-05-14 15:48:29 UTC
OK, here's a problem that you need to solve first: amaroK has the 'local vorbis file' and the 'remote real audio stream' in its playlist. Now from your example it has to switch Phonon backends in between. But amaroK is doing a crossfade. So there's at least 3 seconds where both backends need to be loaded and used. That looks like a real big can of worms to me. Also you have to consider that switching backends is a really heavy operation: the first backend has to clean up and the backend plus all its dependent libs need to be unloaded. Then the second backend and all its dependent libs are loaded. This can easily take 2 seconds. If somebody can solve those problems I'm happy to look into that, but at this point I can only tell that this problem cannot be solved on the Phonon side. > Now from your example it has to switch Phonon backends in between. If I understand the Phonon concept correctly, it's Phonon that needs to switch backends, amaroK is just telling it to play something no matter how. (This is not an objection, it's just to make sure that I get it right.) > the first backend has to clean up and the backend plus all its > dependent libs need to be unloaded. Then the second backend and > all its dependent libs are loaded. Is this so, or can the second backend be loaded while the first one is unloaded? I mean does Phonon heavily rely on the assumption that there is a 'THE backend', or might this be made a function? (I mean 'the backend suitable for x, y', whereby x and y are mimetype and location.) Maybe the loading of the second backend doesn't need to wait for the unloading of the first one to complete. As I haven't gathered the necessary information, I cannot provide a conclusive answer. However at first sight I can think of: - maybe clients can be provided the ability to tell phonon in advance what URLs they will need playback for. Of course this doesn't solve the problem altogether, but it does solve it where it's likely to occur most (i.e. within apps that make heavy use of Phonon and implement these ahead-of-time signals). It's not difficult to do them when you have a playlist anyway. - maybe the whole problem is 'you ain't gonna need it'. Video players are most of the times started for just one thing (like 'play this trailer' or 'watch this DVD'), they don't have playlists. And even if they do, video files are realtively long so switching can be assumed to not happen often. Also remote audio streams are often radio stations, and these ones are not normally queued into playlists, since none of them ever 'ends'. They can also be podcasts, and these ones do end, admittedly. So perhaps the problem is real, but it does seem overestimated. Andmething does not sound well at all (at least to my ignorant mind :-) ) - amaroK has local vorbis file and remote real stream - phonon has loaded gstreamer engine to play vorbis - now amaroK wants crossfading - phonon keeps gstreamer, because switching would consume resources - the stream happens to be one of those that can't be played by gstreamer, for whatever obscure reason - so gstreamer fails, phonon fails, amaroK fails, 'linux' fails, and all of these because of the need to avoid loading the library that does the job However if the problem is not loading a library from time to time, but loading it fast when it needs to work realtime (as with crossfading), then Phonon can indeed not make the hard drive faster. But maybe this can be helped with preloading, so that at least they're available in disk caches on not-so-loaded systems. Or maybe not since this sacrifices loaded systems. From a pragmatical point of view the best I can think of is: - do the 'magical switching', but only do it if there's no need for real-time operation. This means if amaroK wants to do a crossfade and this is not possible otherwise, let it try with whatever we have loaded, even if it fails. But if, for instance, amaroK is just starting up to play a podcast, then load whatever is best for the podcast. |