The summer is over

Today is the last day of August, which means that Summercode 2009 is over for me. Well, almost over. I will have to write the final report this week, and then there’s the Openmind conference in which I will take part as a summercoder. I will also need to produce a short video presentation for the conference.

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.

Finishing touches

The D-Bus interface for PulseAudio is now in some sense complete. All features listed in the interface documentation have been implemented.

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.

The end is near

This week I completed the Device and DevicePort interfaces, and started the Stream and Client interfaces. What’s still missing are the Sample and Module interfaces, and of course the rest of Stream and Client. I think I have a good chance of completing those next week. Implementing all these interfaces is quite repetitive, and at this point the rest is almost competely routine work. The last week will then be spent on testing and writing the final report.

Memstats, Card and CardProfile interfaces done

This week I implemented the Memstats, Card and CardProfile interfaces. Memstats allows clients to query how much memory PulseAudio uses for audio data. Card provides information about sound cards (including bluetooth devices etc.). One important aspect of Cards is that they may contain multiple switchable CardProfiles, one of which is “active” at any given time. The active profile determines how many and what kind of sinks and sources the user can use. For example, analog stereo output + digital stereo input would be one profile, and analog 7.1 surround output would be another.

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…

Stream restore extension done

I just finished implementing a D-Bus interface for the “stream restore” module. The module remembers which streams play to which device with what volume. Whenever a new stream appears, that module looks up from its database whether a similar stream has been playing before. If an entry for the stream is found, the saved state is restored. The work now done allows D-Bus clients to inspect and modify the database, and also get notifications whenever changes are made. The interface went through some changes, because the original version tried to mimic the C API a bit too faithfully.

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.

New GUI program for testing

This week began with testing the Core interface that was finished at the time I created my previous post. (Finished as in “it compiles and doesn’t crash right away”.) I found some bugs and fixed them. While doing that I grew tired of the command line based testing script I had developed. It felt clumsy, and making it useful for testing signals seemed difficult. A GUI would be much more natural interface for displaying events in real time. And clicking around in a GUI should be much quicker way to try out the interface, anyway. So I wrote a new graphical controlling program for PulseAudio. I created a new project for it in Gitorious. If someone wants to try it out, it’s written in Python and requires pygtk and the D-Bus bindings for Python. Running “python padbustester.py” should start the program, no other installation is needed than copying the source files to some directory. Currently the program shows and lets edit properties; methods are yet to be implemented. Signal handling needs to be added too.

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

Core interface: pretty much done

Finally, the Core interface is implemented. I didn’t yet test it thoroughly, that’s for tomorrow. Especially the signals are interesting, since I haven’t seen any of those in action yet, and they work quite differently compared to properties and methods.

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.

Some more progress

Last time I set myself a goal of finishing the Core interface this week. Sadly, I didn’t achieve that. Of the 48 properties, methods and signals (one property got added this week) I only got done 16 new ones, total being now at 22.

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.

Week 5 of PulseAudio’s D-Bus interface

Week ago I posted an RFC of the interface draft to the PulseAudio mailing list. It didn’t generate many responses. Lennart reviewed it, and Pierre Bossart also gave a couple of suggestions privately. I agreed with most feedback, but not all. Lennart is currently at the Gran Canaria Desktop Summit, so it will probably take a while for him to respond to my reply.

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).

First API draft completed

I have spent the previous week designing and documenting the PulseAudio D-Bus API draft. I finally got it finished, and sent a request for comments to the mailing list.

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.