Friday, July 13, 2007

Monobuild updates

During the latter part of this week I revamped monobuild to use the .spec files from SuSE's buildservice rather than using Ximian buildbuddy. This was a long overdue move. When our build machine's 700 GB disk crashed, I decided to dive in. There are some nice advantages to this:
  • I'm not using the obsolete buildbuddy

  • I maintain only .spec files now instead of merging changes back and forth in buildbuddy

  • Those spec files can be shared with monobuild, suse build service, and suse autobuild

  • When setting up a new distro chroot, I don't have to rebuild buildbuddy with the new distro info
These spec files have been in the making since I started adding mono to the buildservice several months ago. Another thing that made this move possible: I purged the unsupported distros. Their vendors don't support them, so neither should we.

It is interesting to note that there has been some talk of coming up with a cross linux distro xml description to be used in the buildservice. Kinda funny, since buildbuddy had the ability to build rpm and deb. Oh well...

One of the other monobuild features I finished up is the ability to build rpms on your local machine. Previously you could only build on a machine connected through ssh. It's not real user friendly to get this working, but it's possible. I mainly wanted to implement this to work toward to goal of enabling others to easily create the installers.

The easiest way to build local rpms is definitely with the suse buildservice. It rocks. In fact, it has replaced much of the functionality of monobuild. But, since the build service doesn't support all the platforms or distros that we build on, we'll continue to use monobuild for releases of those missing platforms. Monobuild also works great for continuously building from trunk. (There's no reason monobuild could use the buildservice tools to locally build out of trunk, but there hasn't been a need at this point.)

Monday, July 2, 2007

Novell Hack Week

There are two technologies that I really want to use all the time:


The problem is that I run mythtv quite a bit, and myth doesn't work very well with either of the aforementioned pieces of software. As a result, I usually don't have PulseAudio nor Xgl running, because it's a pain to constantly switch them on and off.

So I decided to hack on mythtv for a week to fix this.



In order to output to pulseaudio from MythTV, you have to use an oss emulation wrapper (padsp). Patch myth to have real pulseaudio support.


I took Monday to set up the myth development environment, set up my usb tuner on my laptop, and get the build infrastructure for PULSE output set up. By Tuesday morning I had unsynchronized audio/video going to the pulse server using the simple api. I assumed that by using this api, a/v would be out of sync. But by trying it out I was able to make sure of this, as well as get the basic framework implemented.

I read some pulse documentation about the asynchronous api, and before diving in, decided to look at fixing the alsa output support to see what that would take. It ended up being really simple to fix alsa: don't use mmap access to the sound device. In case there were objections for my patch because I didn't use mmap, the final patch tries to use mmap, but then falls back to non-mmap. I spent the rest of Tuesday and most of Wednesday reading ALSA documentation, doing the final patch and making some packman derived mythtv packages that included my patch: (which are hosted here , although I'm hoping this will get into the myth sources, so these packages will eventually disappear.)

Patch posted to the myth bug .

Fixing ALSA was also nice in the fact that no new dependencies were needed for myth. If for some reason there are additional benefits of implementing native pulse support, I might re-address this later.



I usually don't run XGL because mythtv crashes Xgl when you try to display video. This needs fixing.


I figure that mplayer works under Xgl using XVideo just fine, and that Myth should be able to do the same.

MythTV has a branch called mythtv-vid where they are working on an OpenGL output driver. I spent a while installing this branch and getting the latest xgl and compiz-fusion running, just to make sure this problem wasn't fixed already. It wasn't, and I couldn't get the opengl output on myth working.

At this point I wondered if I should just drop this idea and wait for the mythtv-vid project to finish the GL out support. I decided to do some simple benchmarks with mplayer to compare gl out and xvideo out. This can be done by disabling sound and telling mplayer to spit out the frames as fast as possible. The xvideo out ended up being slightly faster. (This was using ATI's fglrx driver. It would be interesting to run the same test with some different video cards and drivers). That was Thursday and a little bit of Friday.

The rest of Friday morning I spent debugging the myth sources to find the crash. This went rather slowly because each testrun crashed Xgl and I had to constantly re-login. The crash is happening during some xvideo initializations. I've located the X calls that cause the crash, but that's as far as I got. I don't know enough about xvideo to debug this further, so I've got some more digging to do. That took me until about noon on Friday.

The next few hours were spent setting up another machine so that I could demo mythtv running on a computer with synchronized output to 2 computers. The demo was video taped, but it's kind of difficult to experience synchronized output with a video camera :) I finished the rest of the day debugging xgl a little more, but ended up not making any progress.


I have MythTV working with PulseAudio (even though it didn't quite happen as expected), and made some good progress towards finding out why MythTV crashes Xgl. The hack week was a blast and it seems like overall a lot of great progress was made. Can't wait for the next one!

Update! Lightning talk: