Welcome to the Phonon wiki space. Here, we try to document what is being worked on, and our plans for the immediate future. New tasks should go to Phonon/Ideas instead of being added here.
Releases are documented at Phonon/Releases.
Feature matrix is at Phonon/FeatureMatrix.
QA process is described at Phonon/QA.
Amarok finds an Equalizer by looking at the names of the available effects, for xine that would be KEqualizer (which is what Amarok looks for), Gstreamer however uses completely different names...
States are a mess right now, not very well defined and attached to some very weird signals (like aboutToFinish)... nothing is reliable and it causes crappy implementations (see Amarok EngineController why that is bad). In particular discussion with some of our major API consumers should be conducted to find a solution. Suggested discussion partners: Amarok, Dragon, Bangerang
Amarok's enginecontroller has a function called initializePhonon which gets executed when phonon enters error state (in case of missing codec for example). This function deletes all phonon objects held by amarok and reconstructs the whole thing. While this is not a very good practise at all it raises the general concern that Phonon can not administer global graph destruction and instead depends on the backends to handle this (we also see this issue with runtime backend switches). This is a problem as the logic is only implemented in the xine backend and ends up in undefined behaviour land with other backends (mostly resulting in a segfault at some point). Harald suggested the introduction of a Phonon::MonsterNode which then ought to be used as base for the backend's media nodes. Within the ctor of the MonsterNode it can then register with some sort of global node tracker. Upon destruction the MonsterNode unregisters and takes care of path destruction etc. That way it can be ensured globally that the graph is always in a consistent state.
All signals that get forwarded by Phonon from the backend to the consumer should be queued. This is to "simulate" threading, as signal within the same thread context (i.e. the main app one) would get executed right away ontop of the currently present stack. If a backend emits statechange to error without queuing this will directly end up in a slot call in for example Amarok (note: no stack unwinding happened at this point, in fact it grew), Amarok then does things to it (at the time of writing: reinitialize everything by deleting all Phonon objects), once Amarok is done the stack unwinds to the emission in the backend, and the backend continues excuting statements (if any). At this point the presen stack operates on not allocated memory! To prevent this all signals must be queued, so that a backend can finish whatever it is doing, and only once the stack returned to the mainloop the slot on Amarok's side of things actually gets called. This allows both the backend and the consumer to do whatever they want to do. General note: it should be enforced that backends must not be running in a different thread context or if they do they must ensure that all used contexts are cleaned up properly (i.e. the dtors must only return once all threads are cleaned up).
We should not forget to QA QIODs as those will be used in Qt-only Phonon. It would appear that there are also some problems there. While ongoing kio related fixes should also bring great improvements to the QIOD side of things there are some special things that should be considered. In general it would appear that reading from a KIO slave before it is ready will lock the application as the read will never get data. Similar behaviour is to be expected with QIOD, which should only be read once it emitted its readyRead signal.
It should be evaluated where we should/could/need to introduce threading. Some general possibilities:
Phonon has a vast amount of KDE specific stuff going on that makes it terrible to use Phonon for Qt. This is becoming a major issue as Qt 4.8 will not have a bundled outdated version of Phonon anymore, but instead point interested parties to our tarballs. Out of the top of the writer's head standing issues here are: installation of backends to kde plugin paths && installation of headers to KDE/Phonon only. For source compatibility reasons we need to maintain the KDE header stuff, but at the same time also need to provide convenient ways to keep includes like <Phonon/MediaObject> working.
If you want to get involved with Phonon backend development please subscribe to email@example.com. If you want to contribute, make comments or useful suggestions you can also write to the KDE Multimedia mailinglist. You can join the mailinglist using the web interface or take a look at the archives.
There's also a #kde-multimedia channel on freenode where you may find developers.
$ git tag -s VERSION $ git clone kde:releaseme $ cd releaseme $ ./phonon-backend-gstreamer.rb --git-branch master -b trunk -v VERSION -p ssh -u tdfischer $ scp phonon-backend-gstreamer-VERSION.tar.bz2 some-public-server:phonon-backend-gstreamer-VERSION.tar.bz2
Get a number of people to test the tarball to make sure it passes the sanity checks (configures, compiles, installs, plays media). Afterwards, create a KDE sysadmin report at https://bugs.kde.org/enter_sysadmin_request.cgi. Include the SHA-1 and SHA-256 sums so they can verify. Also note that the destination for the upload should be stable/phonon/phonon-backend-gstreamer/4.5.1 (replace values as needed). Wait ~6 hours. Finally, announce it to the world via blog and mail to firstname.lastname@example.org along with your backend's own mailing announcement lists.