Development/Tutorials/Phonon/Backends
Parts to be reviewed:
- Port to KF5
- Create more complete example
Phonon itself does not implement any multimedia functionality and depends completely on a backend to do what the applications want. This is comparable to engines in Amarok or Player subclasses in JuK but with one big difference: once your backend works correctly it will make all KDE applications using Phonon use the mediaframework you used for implementing the backend.
Subscribe to the phonon-backends mailinglist if you want to discuss development of your backend or read about the development of other backends.
How to Write a Backend for Phonon
To simplify the text the following terms are used below:
The backend has to implement some abstract classes (always named Interface) and some QObject interfaces. The classes/objects that implement those interfaces I will denote with impl classes/objects. For most media frameworks the objects have to be connected in some way forming a graph. I will simply talk about a graph or flow graph. In order to get started and see some progress early, I recommend to copy the fake backend that ships with Phonon. First you'll want to edit the CMakeLists.txt and phonon_fake.desktop files. In the CMakeLists.txt you can comment out all classes except MediaObject, AudioPath, AudioOutput and Backend. Those four are the minimum requirement for audio playback. In the Backend class you return 0 for all classes that you have not implemented. In the source you then change the namespace from Fake to whatever your backend is called. Then you can get going on implementing the three classes.
To test whether your classes are working you can use the test programs from the tests directory. Compiling kdelibs with KDE4_BUILD_TESTS will create the test programs in builddir/phonon/tests/.
There are two approaches on how to implement the functionality:
- Create graph objects in impl objects
This is an approach that was already successfully used for a proof-of-concept aRts backend. The MediaObject impl creates the PlayObject. The AudioPath impl creates a StereoEffectStack and Synth_MULTI_ADD if needed. The AudioOutput impl creates the Synth_AMAN_PLAY object. You get the idea. All the common objects are held in the Backend object and are accessible for the other impl objects. Examples for this are the KArtsServer and KArtsDispatcher classes used in the aRts backend.
You might want to consider this approach if it is easy to find a 1:1 mapping between impl classes and entities of the mediaframework.
- Use the impl objects as a description to let some other entity create the graph
Create simple impl classes that do nothing else than describe the state that is requested from the application. Another class then can use that description to create the according flow graph. Whenever the state of the impl objects changes this class is notified and can take action accordingly.
This approach is what you need if you cannot find a 1:1 mapping like above, and might often be the more flexible approach even if you have a good mapping of Phonon impl classes to media framework entities.