Version: (using KDE KDE 3.5.2) Installed from: SuSE RPMs OS: Linux Phonon should be able to switch engines dynamically dependant on MIME type, KIO Slave and availability. I've seen non-technical users stumbling over media too often just because the right amarok/kaffeine engine wasn't active. Phonon should be 'just like magic!' ;-) (which is much better than today's 'just like hell'). What I mean is for instance: - user wants to play local vorbis file - Phonon delegates to xine engine - now user wants to play remote real audio stream - Phonon delegates to helix engine, if it's available - user wants to play podcast - gstreamer engine handles podcast metadata best, so let it do the job - user wants to play file from HTTP source - user now brings in an audio cd - xine engine cannot translate from AudioCD KIO slave (ouch!), but NMM engine is very good at that, and we happen to have it available. Use it. (of course, the examples are fictitious) If the best engine for the job isn't available, talk to the second. This might not apply to windows, for instance, where it might not be needed or not be doable, but on Linux/UNIX I could finally tell people that they can play mostly everything if they switch to it. Configuration could then be done in a cascading fashion: - KDE ships its set of rules, assumed to be best for most people - distributors know better how a specific engine works for them, so they tweak the rules (or they don't, if there's no need to) - in the assumingly very rare circumstances when this is actually needed, the user can decide to learn about it and change some rules. However this is almost never needed.
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.