I have been very happy about this Summercode thing. I applied, because working as a open source developer is what I regarded, and still regard, as my dream job. An unexpected side effect of being a summercoder was that already in June I was contacted by Digia; they asked whether I’d be interested in working for them. Tomorrow is my first work day there. One could even say that Summercode changed my life :)

I have enjoyed working from home and being my own boss. The only downside with the freedom has been that I feel I haven’t been as efficient as I could have been, because of some tendency to procrastinate. I’m still quite happy about what I’ve achieved: the whole D-Bus interface got implemented (with some minor improvements still in the plans), and as a side product PulseAudio will have a reasonably well-designed (IMHO) framework for future D-Bus related work, as soon as my work gets merged with upstream. In terms of source code lines, “git diff –stats origin/master dbus-work” reports that there are 49 files changed, 11608 insertions and 48 deletions.

This will be the last post in the “Summercode 2009″ category, but I plan to keep blogging about my free time coding. I’m not sure if anyone is interested in it, but I imagine making my plans public will have some motivating effect for myself. Speaking of plans, here is the top of my todo list, in descending order of priority:

• Finish redoing the system that D-Bus clients use to discover the PulseAudio server’s address.
• Expose the recently introduced device priorities through the D-Bus interface.
• Stop assuming that the Driver property is always available in the various objects that may have the property.
• Add IncreaseVolume and DecreaseVolume methods to Device and Stream interfaces, if such features are deemed useful.
• Test the D-Bus interface somewhat thoroughly.
• Improve the ability to configure server access permissions.
• Update relevant manpages.
• Start discussing with Lennart about merging the D-Bus work into PulseAudio’s master branch.

After those the next thing will probably be either helping Jason to fix remaining problems in his equalizer or finishing the filter framework for PulseAudio that I started in spring.

I had a late realization that the D-Bus framework of PulseAudio still has one more good chance to reduce the amount of future work: the message argument types can be checked automatically, because the framework already forces the implementers of any D-Bus interface to tell the expected argument types of all method and property calls. Implementing this automatic checking is not finished yet (it requires changes to many places), but after it’s done, very often there will be no need to worry about message argument presence or type in received messages.

There are some other minor cleanups I want to do, but those shouldn’t take too long. I hope these tasks will be completed tomorrow or on Saturday. Then I will attempt to hack up a helper program that clients use to find out the server address. Currently the server lookup service is implemented in the main PulseAudio daemon executable, which has turned out to be a flawed idea. If I have any regular readers, they might remember that I planned in my previous post to do testing before fixing the server lookup logic. Well, I changed my mind. Testing will be left for a later time (it will be the top item on my todo list after writing the final report, so there should be no worry about me postponing it indefinetely).

If all goes well, maybe I can manage to write up the final report on Monday. If not, I will have enough time for it next week.

I have now about three weeks left. Completing the D-Bus interface requires implementing the Device, DevicePort, Stream, Sample, Module and Client interfaces. I believe there won’t be trouble achieving that. I have neglected testing lately (I only make sure the D-Bus module loads without errors or crashes), and I really hope I will have time for testing after all the initial implementations are done. Before I consider the work worth merging in upstream I will need to reimplement the server discovery logic, as I’ve mentioned earlier. There’s some chance that I can do it this month, but I don’t have high hopes about that. It will get done eventually, however, even if it means that I will do it on my free time later this fall.

Well, time to start working on the Device interface…

I continued helping Jason with the new equalizer module. Realtime control with a GUI should happen any day now. The module’s client communication is now based on my D-Bus work. I was happy to see that the D-Bus infrastructure work suited quite well for the equalization module too – no additional helper functions were needed and message handling functions were rather short.

I’ll try to do the Memstats interface tomorrow.

I hope to finish method and signal handling in the testing program this week. Additionally, because Jason Newton (the guy who has been working with equalization lately) has expressed interest in using D-Bus for communicating with clients, implementing extension registration has become a priority. In order to make sure it works well, I’ll try to implement the interface for the stream restore extension as soon as possible.

Below is a screenshot.

Screenshot of PadBusTester

Although at this point the work doesn’t need very much creative thinking anymore, implementing the stuff seems to take a lot of time. I think doing about 30 properties/methods/signals is pretty much the maximum what I’m able to complete within a week. This means that finishing the whole interface might still take about four weeks, and that’s without the equalization extension. I realized last week that while the current server discovery works, it should be done differently. Lennart is having a vacation, so I’m still waiting for feedback on that issue, but I’m fairly sure I’m going to need to rework the server discovery logic (possibly by creating a separate program that takes care of it).

Drawing conclusions, it seems like I won’t have time to port pavucontrol and paman to use the D-Bus interface instead of the current native interface. Nor can I finish the equalizer and do the D-Bus interface for that (Jason Newton has been interested in taking my equalizer project forward, though, and it seems that he might actually have the needed motivation to eventually finish it). Those things make up the four last weeks of my original project plan – I wonder if my funding will continue for the last month… Luckily it the most important things will likely get done.

This week I aim to finish the Memstats, Card and CardProfile interfaces.

New helpers for building and parsing D-Bus messages were needed, so it wasn’t all so trivial as I last time predicted. More of that will likely still be needed. The Python script that I use for testing is getting more complex too (I wonder if I should publish that, it might be useful as example code). That said, this was one of those weeks that could have been more productive. I was secretly aiming at completing the main functionality within next two weeks (the “official” project plan has still four weeks for that), so that I could take some time to finish my equalizer work for PulseAudio. At this pace it looks unlikely :(

Next week… just more interface items, should be straightforward work. Let’s set some concrete goal again: finish Core and the small Memstats interface.

I spent the beginning of the week updating the documentation and code to reflect the feedback. After that I implemented the first six properties of the Core interface. It turned out that it’s often rather trivial to get the answers to the property queries (and I suspect implementing methods will in many cases be almost as easy). Most of work is with parsing and generating the D-Bus messages. Parsing and especially generating the messages is quite repetitive. After a few properties I started to see what code is getting copy-pasted, which led me to write some more framework stuff for working with D-Bus, and also to rewrite parts the earlier framework. That rewriting is still underway. After that’s done, generating responses should require very little code.

I try to get the framework working again tomorrow, after which I hope I can do some rapid progress with the interface. Getting the Core interface done by the end of the week feels like a realistic goal (Core has 47 of the current total of 170 properties, methods and signals).

In the current form of the API I have a total of 172 properties, methods and signals to implement. That feels quite a lot, but next week I should have much better idea of the real work amount. Before I can start implementing the API, I will still need to add property and signal support to the D-Bus infrastructure in the server. I expect that to be about one day of work.

Hm, another short report.