Month: April 2006

Been working with Marlin over past few days. Mostly in my head.

The upgrade to GStreamer 0.10 has allowed me to rethink how everything fits together.

The old way

The old pipeline was two threads: The decoding thread, and the sink thread. The src passed it to the decoder which decoded it, passed it to audioconvert because we’re pretending we’re proaudio and so we want audio/x-raw-float.

After this we split the audio into mono streams. The Deinterleaver splits the data and creates a new src pad for each stream. As these pads are created we create the queue element and get a new sink pad on the sink. This increments the number of channels in the sink (duh) and also sets the number of channels on the sample that is associated with the sink.

This is quite annoyingly complicated and a lot of weird stuff went on in the sink to co-ordinate the incoming pads and link the pads.

The new way

First thing to notice is one thread. wooo. Hopefully I won’t need any other threads but because I’ve not coded this yet I dunno.

The src and decoder do the same. However, the decoder isn’t linked to anything until it knows the number of channels/sample rate etc and creates the srcpad for it. Because we now know this when we create the rest of the pipeline, we can set the format on the sample associated with the load pipeline in one go, not first create one pad, set it to mono, create the second, stereo, third….etc like we used to. This means we can remove the logic for controlling the sample format away from the sink.

Audioconvert and deinterlacer do their same thing (although deinterlacer should be deinterleaver, but its 2am, so sue me.)

Now however, instead of having on sink that deals with the sample as a whole, we have a sink for each channel. Instead of having lots of sinkpads, this sink only has one, and doesn’t care about the other channels.

Advantages

We can now associate a channel sink with a certain channel, which we couldn’t before. So even if we disconnect the pipeline, the left channel will still be connected to the left channel when we reconnect. Moving the sample logic simplifies whats going on a lot, and making each sink be mono allowed us (me) to use GstBaseSink which seems to deal with all the hard stuff for me. The sink code has shrunk from 800 lines to about 300. Wooo

Productive Easter Monday

I have a hardware sampler now and I have a CD collection of samples. 10,000 samples on 8 discs. Except they all have very helpful names like “rcx00003.wav”. So I wrote this:

It plays the samples as you scroll around them with your cursor keys.

Simple, but lets you preview all the samples really quicky.

Then, for a laugh I wrote this:

I call it Lyricist. At the moment it adds a button to the Muine player window (I made a few modifications to Muine for that…yey for iMuine), and retrieves the lyrics for the family singalong. Sorry Ross, but no bouncing ball.

Also visible in the shot is the button that I added to Muinescrobbler that allows you to tag songs in Last.FM but its not finished yet, so let’s not talk anymore about it.

I also got the first ever “present” for a piece of software I wrote. Chris Daniel paid for 3 months of Last.FM scription for me. Thanks Chris, you rock.

Once upon a time there was an application called Marlin that used GStreamer 0.8. It used GStreamer 0.8 quite heavily, with about 8000 lines of code solely to deal with GStreamer. Then GStreamer 0.10 came out and there was much rejoicing as it was superior in many respects. But Marlin was unable to take advantage of it.

Then early one very cold morning in Helsinki, it was decided to make Marlin run. But it refused. “No!” it said. Repeatedly. Looking at the code after 6 months revealed new insights about why would always refuse, and it was categorically decided to make it work with the new GStreamer.

A plan was concocted in a warm bed, and the plan was thus:

The first step was to tidy the existing code up. All warnings and errors were fixed and removed, and silly bits of code were made less silly.

This revealed many silly errors, such as

MarlinUndoable *
marlin_undoable_new (MarlinUndoableFunc undo,
		     MarlinUndoableFunc redo,
		     MarlinUndoableFunc destroy,
		     gpointer closure)
{
	MarlinUndoable *u;

	u = g_new0 (MarlinUndoable, 1);
	u->undo = undo;
	u->redo = redo;
	u->destroy = destroy;
	u->closure = closure;
}

Once these errors were eradicated the next step was to disable the GStreamer code.

One sidetracking later, in which the evil witch of libxml was banished being replaced by the good GMarkup fairy, and all 8000 lines of GStreamer 0.8 code were disabled and Marlin would run once more, albeit not actually do anything.

Finally it was decreed that the code would be put back in place slowly and carefully, starting with the dead easy simple stuff, and then plan out how to integrate GStreamer 0.10 correctly into Marlin.

Currently, GStreamer is now correctly initialised, and the file chooser can preview a sample…more stuff will come. There is an understanding in the country of how the GStreamer stuff will work.