Hi Everyone, If you follow certain circles you'll know what I'm working on, but for background please see this thread: http://mail.kde.org/pipermail/phonon-backends/2009-September/000304.html Now sadly I didn't get the information I needed from the above post (the mailing list is not super active) and I fear that Matthias is the only person who could answer authoritatively and I'd imagine he'll be nose to the grindstone on various study related things so I'm asking here for some advice and assistance. I've given a detailed background in the above _link_ed mail so I wont do it again, I'll just summarise shortly here. The problem is thus: The current libphonon + KDE Platform Plugin interaction is very strange (read: bad design). When presenting the GUI, the (kde_base_4-runtime) code will read in the libphonon config file and interpret it's device priority list for each category. It will then ask the platform plugin for it's devices and then the backend for it's devices and combine the lists with the order from the config to create an ordered list of devices for display. Now, when some audio is played, the backend code (libphonon) will read in the libphonon config file and interpret it's device priority list for each category. It will then ask the platform plugin for it's devices and then the backend for it's devices and combine the lists with the order from the config to create an ordered list of devices so it can pick the appropriate device for playing the current audio. Now there is obviously a big parallel there, with frontend code reading backend config and doubling up on the logic for ordering the devices. This is IMO bad design for two reasons:   1. The frontend client code has to have knowledge of how libphonon stores it's configuration and basically tweaks it's config for it. It should not do that. How libphonon does this should be a black box. If it wants to use a config file, great it can do but the frontend should not be aware of it, nor need to read or adjust it in order to get the information it needs.   2. Frontend code has to be aware of the platform plugin to list it's devices in an appropriate order - if I write a generic phonon app that lists devices, I would want to say hey libphonon gimme all your devices, in order, for this category please and have libphonon say sure, here you go . I don't want my application to be intimately away of the whole concept of platform plugins - this should be abstracted completely by libphonon. I don't think the config GUI in KDE should be any different. Now the reason this causes me problems (I'd normally just look the other way!) is that I want to override the use of the platform plugin from libphonon. I want the phonon engine itself to say actually, in this specific case, the platform plugin does not know better about audio devices than me, so I'm not going to ask it. I do not want to propigate through a flag from the backend right the way up through the API to all client applications so that the client applications can combine the two lists of devices appropriately. I just want the backend to be the only place used to dish out all devices and their priority in the first place and be able to do so in order on a per-category basis. Now I've been doing a lot of hacking on this and have more or less achieved this design goal, but it comes at a price: ABI breakage. Now I need to know how best to fit this in and what bit I should tweak in my current patches. My current patch changes only internal code, with the exception of a few additional exported calls in Phonon::Experimental::BackendCapabilities namespace. This is not really an appropriate namespace for the functions in question, but it was the easiest place to put them! Here is the public API tweak as it stands: http://colin.guthr.ie/git/phonon/tree/phonon/experimental/backendcapa... (all methods except the first one are mine). There are lots of internal changes, especially to phonon/phonon/globalsettings.cpp This class is private, i.e. not exported to the clients. (currently, this class is also copied to the frontend code which is IMO, as I mentioned above, bad design - you shouldn't work around a non-exported class in a library by copying it - you need to address the design problems properly!). So in my libphonon changes, I've made this class able to be queried in such a way that I can get useful listings for devices on a per-category basis from it. It is becomes the sole class at the backend responsible for interpreting/writing it's own config file and providing devices indexes in the appropriate order for a given category etc. I've added calls to tweak e.g. the hiding/showing of advanced devices and to write updated priority lists. IMO, this class needs to be exported in some capacity (replacing my backendcapabilites API) to allow clients the ability to present GUIs appropriately, and allow the user to change the configuration, while remaining abstract as to how the actual storage should be. With the current changes I've been able to modify the runtime components such that the copy of globalconfig.cpp is removed and only the backend is asked for device listings and all configuration changes are passed through these wrappers. So, here is the question: Can we export the backend's globalconfig? If this is done, I wouldn't need my wrappers in the BackendCapabilities namespace. It doesn't change the API in any major way (e.g. it only adds to it - it does not change it) and would allow IMO a cleaner design. If this is possible I'd propose to clean up the API a bit, so we can be confident going forward that it will meet everyone's needs. IMO configuring libphonon's operation should be as much part of the API as just playing sound. That's not to say that globalconfig in it's current form is suitable for export but if at least the principle is sound, that would be good to know going forward. Thanks for reading and I hope I've explained my needs accurately. Here are my current code changes: http://colin.guthr.ie/git/phonon/log/?h=pulse http://colin.guthr.ie/git/runtime/log/?h=pulse (PS ignore the first runtime commit - it's subsequently been superseded and is the main problem I was concerned about in point 1 above!) These changes require an additional pulseaudio module here: http://colin.guthr.ie/git/pulseaudio/log/?h=history Cheers Col

Here are my current code changes: http://colin.guthr.ie/git/phonon/log/?h=pulse http://colin.guthr.ie/git/runtime/log/?h=pulse Your phonon-gst fixes look intriguing. Regards,  - Michael Pyne






 

signature.asc
< 1K
Download




- Hide quoted text -- Show quoted text - Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Your phonon-gst fixes look intriguing. Aye, most of the changes are not gst specific, but I think gst is working a bit better now too. That said, I did fix several bugs earlier in gst which are all in svn now (you can tell as my username is cguthrie on the bits already committed to subversion). Neoclust (another Mandriva guy) is also fixing serveral bugs in phonon-gst too. We're on a bit of a triage mission to get it working better before the next Mdv release hits. Col

Your phonon-gst fixes look intriguing. Aye, most of the changes are not gst specific, but I think gst is working a bit better now too. That said, I did fix several bugs earlier in gst which are all in svn now (you can tell as my username is cguthrie on the bits already committed to subversion). Neoclust (another Mandriva guy) is also fixing serveral bugs in phonon-gst too. We're on a bit of a triage mission to get it working better before the next Mdv release hits. Awesome.  I think I'm in the minority of KDE users who use phonon-gst mostly, which I think is due only to the bugs present in our backend, so it's nice to hear there's work being done on it. Regards,  - Michael Pyne






 

signature.asc
< 1K
Download




- Hide quoted text -- Show quoted text - Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Your phonon-gst fixes look intriguing. Aye, most of the changes are not gst specific, but I think gst is working a bit better now too. That said, I did fix several bugs earlier in gst which are all in svn now (you can tell as my username is cguthrie on the bits already committed to subversion). Neoclust (another Mandriva guy) is also fixing serveral bugs in phonon-gst too. We're on a bit of a triage mission to get it working better before the next Mdv release hits. Awesome.  I think I'm in the minority of KDE users who use phonon-gst mostly, which I think is due only to the bugs present in our backend, so it's nice to hear there's work being done on it. Yeah we use it by default in Mandriva for various reasons, and I stick with it mainly due to some perverse opinion that it's technically most appropriate than therefore is the one I should use, even if it does have annoying bugs, problems and limitations in it's current form. Fingers crossed we can bring it up to speed. Thanks loads for your replies Michael. Col

(although if we export it we need to be ready for any Phonon-using app to get a hold of it Yeah true, but I guess that isn't too bad overall considering it's a fairly simple API. Is there some other trick we could do to make this harder? Or perhaps just by copying the header but not the full implementation? (although that latter option feels ugly too!) No need to put the clamps down, client code that really cares about it will just edit the phononrc on disk or various other sundry hacks. Well this is really what I'm trying to avoid. While the config file will be used in some cases, what I'm actually implementing at the backend is an alternative to the config file used when the audio backend ultimately uses pulseaudio. So the main design goal from my perspective here is to make sure client code is totally unaware of any config file at all... i.e. it must have an API to access, query and change the config, never access it directly via a file. All I mean is that there's no reason to put a lot of time into trying to keep clients from abusing the exported class and yet allow the KCM to work.  If it's an internal API for instance but must be public for this reason we just document it as such in the APIDOX for the methods involved. i.e. @internal Another evil thing to do is something like our virtual_hook(int method, void* data) but don't document how to use it.  (When we mean for client code to call a virtual_hook we provide wrapper functions to marshal/demarshal appropriately). But there's no reason to go this route as long as the public API can be used as documented (which can include documented as do not use unless you are kcm_phonon ) Regards,  - Michael Pyne






 

signature.asc
< 1K
Download




- Hide quoted text -- Show quoted text - Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<