Audio player toy using Gstreamer

In order to learn more about some other Open Source projects and different development environments, I started to read about Gstreamer.

The idea was implement a very simple player, where the medias that will be played are passed by argument in the command line.

The main pipeline has only one element, the playbin2, witch has the autonomy to autodetect the file extension and, for example, choose the most appropriate outputstream. Because of this, the player has the "capacity" of playing both audio and video files.

Was very interesting playing with an area of computer science that I never had any kind of experience before.

Here is the code:

#include 
#include 


GstTagList *tags;


static void
print_tags()
{
  gchar *artist = "Artist";
  gchar *title = "Music";

  /* If already known, get the Artist and Title tags of the media  */
  gst_tag_list_get_string(tags, GST_TAG_ARTIST, &artist);
  gst_tag_list_get_string(tags, GST_TAG_TITLE, &title);
  g_print("%s - %s :", artist, title);
}

static gboolean
cb_print_position (GstElement *pipeline)
{
  GstFormat fmt = GST_FORMAT_TIME;
  gint64 pos, len;

  /* Keep printing informations about the media that is playing */

  print_tags();

  if (gst_element_query_position (pipeline, &fmt, &pos)
    && gst_element_query_duration (pipeline, &fmt, &len)) {
      g_print (" %" GST_TIME_FORMAT " / %" GST_TIME_FORMAT "\r",
               GST_TIME_ARGS (pos), GST_TIME_ARGS (len));
  }

  /* call me again */
  return TRUE;
}

static gboolean
bus_call (GstBus     *bus,
          GstMessage *msg,
          gpointer    data)
{
  GMainLoop *loop = (GMainLoop *) data;

  switch (GST_MESSAGE_TYPE (msg)) {

    case GST_MESSAGE_EOS:
      g_print ("\nEnd of stream\n");
      g_main_loop_quit (loop);
      break;

    case GST_MESSAGE_ERROR: {
      gchar  *debug;
      GError *error;

      gst_message_parse_error (msg, &error, &debug);
      g_free (debug);

      g_printerr ("Bus error: %s\n", error->message);
      g_error_free (error);

      g_main_loop_quit (loop);
      break;
    }

    case GST_MESSAGE_TAG: {
      GstTagList *newTags = gst_tag_list_new();
      gst_message_parse_tag(msg, &newTags);
      tags = gst_tag_list_merge(tags, newTags, GST_TAG_MERGE_PREPEND);

      gst_tag_list_free(newTags);

      break;
    }

    default:
      break;
  }

  /* call me again */
  return TRUE;
}

static void
add_bus_watch(GstElement *pipeline,
              GMainLoop *loop)
{
  GstBus *bus;
  bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));
  gst_bus_add_watch (bus, bus_call, loop);
  gst_object_unref (bus);
}

static GstElement *
init_pipeline(GMainLoop *loop)
{
  GstElement *playbin;

  /* Create gstreamer elements */
  playbin  = gst_element_factory_make ("playbin2", "play");

  if (!playbin) {
    g_printerr ("One element could not be created. Exiting.\n");
    return NULL;
  }

  add_bus_watch(playbin, loop);

  return playbin;
}

gboolean
set_uri(GstElement *playbin,
        const char *uri)
{
  /* Set the input filename to the source element */
  GError *error = NULL;
  g_object_set (G_OBJECT (playbin), "uri",
      gst_filename_to_uri(uri, &error), NULL);

  if (error) {
      g_print("Filename to URI error: %s\n", error->message);
      g_error_free(error);

      return FALSE;
  }

  return TRUE;
}

gint
main (int   argc,
      char *argv[])
{
  GMainLoop *loop;
  GstElement *pipeline;
  gint i;

  /* Initialisation */
  gst_init (&argc, &argv);

  if (argc < 2)
    g_error ("Usage: %s   ...", argv[0]);

  loop = g_main_loop_new (NULL, FALSE);
  pipeline = init_pipeline(loop);

  if (!pipeline)
    return -1;

  g_timeout_add (200, (GSourceFunc) cb_print_position, pipeline);

  for (i = 1; i < argc; i++) {
    if (!set_uri(pipeline, argv[i])) {
        continue;
    }

    tags = gst_tag_list_new();

    /* Start playing */
    g_print ("Running...\n");
    gst_element_set_state (pipeline, GST_STATE_PLAYING);
    g_main_loop_run (loop);

    /* Out of the main loop, clean up nicely */
    g_print ("Returned, stopping playback\n");
    gst_element_set_state (pipeline, GST_STATE_NULL);
    gst_tag_list_free(tags);

    /* Has the execution ended? */
    g_print("\n");
    if (i < argc - 1) {
        g_print("Next track...\n\n");
    } else {
        g_print ("Deleting pipeline\n");
        gst_object_unref (GST_OBJECT (pipeline));
        g_print("End of execution!\n");
    }
  }

  return 0;
}

Playing with Linked Lists

It seems silly post some code that lies in a such basic concept, but, lately I was asking myself about my basic coding skills, and decided to practice to see how I'm doing.

Since my first semester in College, I had never implemented again a Linked List manually, actually, I had never implemented it in C, only in Pascal. During the coding process, I became impressed on how much I had to struggle to simply add new elements in order to the list.

Here is the code (very ugly, btw):

#include 
#include 

typedef struct nodeT {
 int value;
 struct nodeT *next;
} node;

//insert always at the head
void insertBeginning(int number, node **head) {
 node *newNode = (node *) malloc(sizeof(node));
 newNode->value = number;
 newNode->next = *head;
 *head = newNode;
}

//insert in order
void insertInOrderRecursive(int number, node **head) {
 //walk through the tail
 if (!(*head)->next) {
  node *newNode = (node *) malloc(sizeof(node));
  newNode->value = number;
  if ((*head)->value > number) {
   newNode->next = *head;
   *head = newNode;
  } else {
   newNode->next = NULL;
   (*head)->next = newNode;
  }
 //found the right place
 } else if ((*head)->value >= number) {
  node *newNode = (node *) malloc(sizeof(node));
  newNode->value = number;
  newNode->next = *head;
  *head = newNode;
 } else {
  //walk to the next node
  insertInOrderRecursive(number, &(*head)->next);
 }
}

void walkThrough(node *head) {
 if (!head->next) {
  printf(" %d\n", head->value);
  return;
 }

 printf("%d -> ", head->value);
 walkThrough(head->next);
}

int main() {

 //init the linked list
 node *list = (node *) malloc(sizeof(node));
 list->next = NULL;

 printf("Enter a number:\n");
 int number;
 scanf("%d", &number);

 list->value = number;

 //insert numbers
 while (1) {
  printf("Enter a number: (-1 to stop)\n");
  scanf("%d", &number);

  insertInOrderRecursive(number, &list);
  walkThrough(list);

  if (number == -1) {
   break;
  }
 }

 return 0;
}

OurGrid - Bug 871

This bug was consequence of a strange behavior of Openfire XMPP Server. Some s2s messages were arriving out of order.

We struggled through different approaches and ideas until find out "the truth", here is the complete history:

A new Peer wanted to join OurGrid's community, in this way, it joined to LSD's Discovery Service and began to be shown at http://status.ourgrid.org/, but, sometimes it strangely disappears and appears again. This Peer had a particular feature, it was not connecting to xmpp.ourgrid.org [1], but in another one (Openfire's too).

Changing the logs level to debug, we verified that LSD's Discovery Service was receiving failure notifications of this Peer, what was not expected, because it was never stopped. After some debugging, we discovered that Commune was sending failure notifications because it was receiving messages with unexpected sequence number (Commune should shutdown the connection with an external component that sends messages with sequence numbers different of those that are expected).

The first approach was, of course, verify Smack (that is used by Commune) to find possible bugs that could interfere at the order of arriving messages, but, after some Google research, we discovered that this issue was a known and already registered bug of Openfire. In this way, we tried to install other XMPP Servers, like ejabberd and Tigase, although, they are very different of Openfire, witch has a pretty and user friendly webconsole (where you can change all the configurations). Tigase did not work at all and ejabberd was very "slow" and also, some control messages like the components status, were not being delivered.

After those tries, the only solution envisioned was the implementation of a buffer for reordering messages at Application's level (Commune). So, every time that a message arrives, the application verifies if it has the expected sequence number, if not, the message should be buffered and wait for a limited timeout for the right sequence message.

The solution was implemented, tested and util there, everything worked fine.

The OurGrid's version 4.2.4 was released and deployed...

Users started to run their jobs...

The community froze, the jobs were not ending and some Workers were being allocated for the Brokers permanently...

Let's do some log analyse...

Messages are getting lost!

Hmm... Seems that the out of order messages buffer is not working very well.

What do to now? After doing some "backtracking", we remembered that ejabberd is the most used XMPP Server by all kind of organizations and has a very active community, but... Why? It is very slow... And what about some larger messages, like the OurGrid's components status?

The answer: you're doing it wrong! There is a lot of configuration properties at ejabberd, like c2s and s2s shappers, max_stanza_size for file transfers, and etc. After properly configurations, ejabberd is working very well without out of order messages traded between distinct servers.

The truth: Openfire has a very strange bug, maybe caused by a concurrency problem and not fixed until the most recent release, ejabberd hasn't, maybe for this (and a lot of other reasons), ejabberd is currently the most used.

The lesson: doesn't matter how much your boss is putting pressure on you, never leave a tentative (specially the one that is more likely to succeed) until you have investigate it as deep as possible (or until your boss commands you to, of course).

--

[1] - OurGrid's public XMPP Server

Cheese - Bug 647229

My first experience of contribution to Cheese was a patch that intend to fix the bug: https://bugzilla.gnome.org/show_bug.cgi?id=647229

The first thing that I noticed was that this bug happens only when the user closes the Preferences dialog with the escape key... But, why? That happens because the GtkDialog has a "close" signal that by default is called when the escape key is released and as consequence it also triggers the "delete-event", that destroys the dialog.

After few research I discovered that exists a way to handle exactly this kind of issue. There is a method at GtkWidget called "gtk_widget_hide_on_delete()", so, what I did was connect this method with the handle of "delete-event" signal. This ensure that the escape key has the same result as the click on the "Close" button.

Here is the patch.