Tuesday, July 31, 2007

End of July Status

Here's the skinny on the Banshee port to Windows:
  • Major re-factoring of the audio CD code. I abstracted a bunch of Linux-specific code and implemented classes for Windows. Made some interfaces into abstract classes where helpful and re-jiggered some of the architecture.
    • The Cool Thing: It's all really pretty and audio CD detection works.
    • The Not Cool Thing: CD playback does not work. This is because Gstreamer on Windows doesn't handle cdda:/ URIs. This is because libcdio doesn't build on Windows. This is because, while it used to build on Windows, the Visual Studio solution has terrible bitrot. Solutions:
      • Build with Cygwin and...
        • Live with a dependency on cygwin0.dll, or
        • Find some way of circumventing cygwin dependencies (ideal).
      • Fix the Visual Studio solution. This consumed much of my time recently. I emailed the guy who previously maintained the VS solution, but he hasn't gotten back to me.
      • Write a new cdda handler for Gstreamer using the Win32 API. Ug.
  • Implementation of CD burning for Windows.
    • The Cool Thing: It's partially done (and was loads of fun), but I need to be able to test it to continue with the work.
    • The Not Cool Thing: I can't test it. This is because Banshee's Gstreamer transcoding code doesn't work. This is because it references libgnomevfs-2-0.dll and there is no libgnomevfs-2-0.lib against which to link and when I link against libgnomevfs-2-0.a, Visual Studio produces a malformed DLL which crashes upon loading. Solutions:
      • Build gnome-vfs with MSBuild. I gave that a try and it looks like a lot of work before it will work.
      • Contact whoever maintains Mono's Windows binaries and ask for their advice (ideal).
      • Remove the gnome-vfs code from libbanshee.
  • Improvements to importing from iTunes.
    • The Cool Thing: Following Jonathan Pryor's post on monodocer performance, I switched from XmlDocument to XmlTextReader. Much memory savings. Not a lot of speed savings (XML handling isn't a bottleneck).
    • The Not Cool Thing: Nothing. The code is faster and prettier.
  • Misc. Other Things:
    • I'm hoping the Gstreamer people will add a function export that I need: _gst_plugin_register_static. It's in the code but it just isn't exported for Windows. Waiting to hear back.
    • The CD reading and burning code are from code example sites. Both are just encapsulation of COM interfaces. I'm 99% sure the CD reading code is license compatible (I'm still looking into it), but the CD burning stuff defiantly isn't. I've contacted both authors to see if they will release the code under MIT/X11. Waiting to hear back. If I can't get clearance, I'll have to do the COM wrappings myself. Ug.
    • Gtk is slow on Windows. Even when not debugging. Aaron's new view model should make things much better.
    • Gstreamer is slow on Windows. It's fine most of the time, but when the CPU gets hammered, the audio will become choppy. This doesn't happen when using DirectSound in similar situations. I don't know yet if it's a significant problem.
I find I'm spending most of my time struggling with unmanaged code. When I tackle a new problem, like audio CDs, I hammer out the C# lickety split and have a great time. But then I hit a snag in native land (like the cdda/libcdio problem) and spend days trying to sort out the C libraries which is no fun. After a few days of wrestling with unmanaged code, I'll put it on the back burner and start on something else (CD burning or iTunes importing, for instance) but I really need to address these native issues. Tomorrow I'll start emailing around and see where I can get with cdda support in Gstreamer or gnomevfs linking on Windows. If you have info on this stuff, especially using Cygwin to build Windows stuff which is not Cygwin-dependent, please leave a comment.

Peace,
Scott.

3 comments:

Anonymous said...

You need a way to "Build with Cygwin and...Find some way of circumventing cygwin dependencies (ideal)."

That's possible. You need to pass -mnocygwin to gcc, e.g. `gcc -mnocygwin foo.c`.

Anonymous said...

Did you try to compile with Mingw?

Paul said...

If you're having trouble with native code, you should definitely try out WinDbg for your debugger - while its syntax is frightening, it's got a lot of extensions for debugging both .NET and native code, situations where VS often punts.

http://weblogs.asp.net/scottgu/archive/2006/02/02/437231.aspx after a quick Google gives you some good info (even though it's for ASP.NET)