1. I don't think we should ship sound files ourselves. There is a freedesktop standard for sound files and we should use it and thus use the sounds files proposed by the current sound theme instead of our own.
2. Surely we could implement the freedesktop standard without using libcanberra. As libcanberra uses gstreamer in the background, I doubt there is any OS supported by directly using gstreamer that isn't supported by libcanberra. I also don't understand what you mean with API being incomplete: Canberra.Context.play_full() can be invoked with a callback which can be used to replay the file in a loop - same as your current code does with GStreamer.
3. I don't think we'd need any configuration for incoming/outgoing call sounds. They are always a sane option. If you want your device to be silent, just mute it.
4. We're currently playing sounds via the desktop's notification system. This doesn't work perfectly (as some desktops don't support it or delay the playing of the sound to the point when the notification is shown). As you do a proper sound playing, it would probably a good idea to at least remove the sound from the notification (as otherwise some users will have the sound played twice).

Another small note about point 1.: This means also that its important to add freedesktop sound as a (optional) dependancy for packages otherwise you can get the fantastic user experience where it seems there is no sound but its just that you dont have a sound theme. But this is more of a distro maintainer's responsability I guess.

About 1: You'd also need to use the active theme (if any) from Gtk.Settings.gtk_sound_theme_name. Check the specification for a detailed pseudocode on the sound lookup routine.

About 2: The _userdata_ is implicitly used in Vala to allow you to either create closures or put a method pointer (which, in contrast to a function pointer, requires the reference to the containing object). I think the not about the context is that the callback may be called from another thread. In this case, you'd need to attach a signal source to the maincontext to ensure you are running on the main thread. The easiest way to do so is by using Idle.add() (which you give a reference to a method or a closure to be invoked on the main thread). The following should give you an idea of how this should probably work (untested):

private Canberra.Context ctx;
private Canberra.Proplist props;
private uint32 id;
private boolean playing;

public void play_again() {
  if (!playing) return;
  ctx.play(id, props, () => {
    Idle.add(() => {
      play_again();
      return Source.REMOVE;
    });
  });
}

public void play_loop() {
  playing = true;
  play_again();
}

public void cancel_loop() {
  playing = false;
  ctx.cancel(id);
}

Bonus: You can easily add a few ms of silence between the sound plays by using Timeout.add() instead of Idle.add() - in case that makes it sound better.

Nice! Thanks for the info. Il look into it.

• main should not have a dependency on GStreamer.
• I guess you misunderstood my comment about the notification thing. There is absolutely nothing wrong with listening on call specific events in the NotificationEvents module. What I meant was, that we already do play a sound on incoming calls (but only once and it depends on the notification system supporting it) via

  dino/main/src/ui/notifier_freedesktop.vala

  Line 120 in 408406e

  hash_table["sound-name"] = new Variant.string("phone-incoming-call");

  We don't want to play the sound twice at the same time (as it would sound ugly), so you'd need to make sure that won't happen.

Okay, I will remove the singular sound also. I don't understand what you mean by 'main should not have a dependency on GStreamer', I did remove my dependancy on gst back to libcanberra already, did I forget a refrence somewhere ?

BTW, I am meaning to redo the commits once you guys are happy with the code because I find them very ugly (no/bad messages, redundancy) if you would like that ofcourse. (and do rebase if needed)

And if you like when we are done here I can put libcanberra on the deps wiki page.

@emildekeyser, I tried this out, and I like it... except the call is ringing tone is made even if I'm making the call using another client.

What's worse is that that sound continues even after the call is connected (on the other device) and disconnected.

So big 😢 and 👎 until that's fixed. (it should only make that noise if you're placing the call from this device.