Looks like I’m bumping into some pretty large issues. I’m really not that familiar with multimedia.

I’ve made another code dump. This is a (hopefully correctly working) bzr branch. You can find it here.

I’m currently still experiencing the problems from my last post: I’m streaming way too fast, and I have no idea how control GStreamer in this way, or if it’s even necessary. I don’t see JustePort doing it.

I have an Apple Lossless “encoder” (uncompressed ALAC; it just slaps a header on it, and byteswaps), but I’m not sure if it’s actually doing things correctly. I should really start verifying individual elements for correctness.

The main sink element also doesn’t clean up at all, but that’s for later.

The result of all this is that I can connect, set up a session and pump stuff to the Airport, but it’s not at all playing anything.

Would be swell if someone could lend a hand at this point. Motivation is slowly sinking again, here.

So I actually got some renewed interest in finishing this.

Things I did wrong:

• I didn’t know the hash used for RSA’s padding actually mattered. I thought: “it’s just padding, after all”, so I used whirlpool. Turns out I needed SHA1.
  
  I’m basing most of my code on JustePort, and I didn’t see any mention in it, in Mono’s documentation or Microsoft’s documentation what .NET was using.
  
  (I finally got the right idea from this document, which is also very interesting and on my TODO list, but entirely unrelated.)


• My filter for encrypting the stream was screwed up. I’ve been reading too little GStreamer documentation, obviously. And I still haven’t looked at how I should be doing it properly, but the solution I have now seems to work.


• I totally forgot about having to encode the stream to Apple Lossless. I think this is one of the two things that are currently keeping me from getting this working.


• The other thing is that I’m not sure if I’m streaming too fast. Right now, there’s nothing limiting it, so the pipeline processes data at rapid speeds by the looks of it. I’m not sure what I’m supposed to do here, and I don’t see JustePort doing much about this.

So this is proceeding at a slow but sure pace, a couple of hours a day, lots of interruptions, lots of implementation mystery.

Last month I started work on a sink for streaming to Apple Airports. I never really got around to finishing it. I got stuck in the authentication at some point.

I plan on looking at this again soon, but for now I’ve decided to upload a code dump, because a friendly fellow contacted me by email and insisted on helping out. You can grab the tarball here.

I used libtomcrypt (with libtommath) for all the cryptography. I built the plugin in Eclipse, so some project files are included (but they’re most likely not reusable). Importing libtom* into my Eclipse workspace wasn’t too much trouble from what I can recall.

It builds for me, but is not very functional. The airport disconnects me on the first message I send to it, and I’m not sure why. Right now, the code is supposed to go up to that, retrieve and print the transport header from the airport response and bail out. I’m doing this, because the transport header tells us where to connect next, and I need to see what it looks like. But I’m not even getting that far.

The thing in general is probably a big hack now. I’m wondering if it’s not possible to turn this into a general RTSP sink, and reuse that in a RAOP sink as some sort of parent class. Right now I copied the tiny RTSP library the rtspsrc gstreamer plugin uses, and made some small modifications.

But I don’t care too much about that for now. It’s great if this can finally be made to work!

SecondLife has been GNU GPL’d.

Now I just wait for someone to call dibs on the .debs.

This is so exciting. I will definitely glance over this for educational purposes.

Happy new year, everyone!

Just bumped into this video on YouTube. Do I see a Nokia 770 there? A Nokia tablet sure would be the ideal platform for something like that.

Besides that, I can imagine people leave their Bluetooth connectivity on all the time. I would if I had it on my phone. A lot of car kits use Bluetooth, and it’s a hassle if I have to turn it off and back on every time I leave the car.