On Fri, 22.08.08 00:02, Brian Cameron ([EMAIL PROTECTED]) wrote: > One quick question about canberra-gtk-play. Is this program intended > to be run by end-users, or only by libcanberra internally? I am > wondering if it makes more sense in /usr/bin or /usr/libexec. I suspect > it might make more sense in /usr/libexec?
I thought about this already. However, c-g-p has a clean user interface, and might be useful for end users, especially for testing when designing themes. So I decided to stick it in bin. > The main topic I wanted to discuss is adding some GStreamer backend > support to libcanberra. > > For Solaris, we need to get Canberra working to support system sounds. > I would like to avoid writing a SunAudio backend since I know that Sun > is in the middle of rewriting the low-level Sun Audio interfaces, and > seems to be moving towards an OSS based solution. Please note that we now have an OSS backend, contributed by Joe Marcus Clarke. Not sure though if it is compatible with OSS4 though, since OSS4 breaks compatibility in certrain places. The changes to make it work should be trivial however. > So, it sort of seems to make sense to write a GStreamer backend that > could be used as a fallback if the OS does not support any other > backends that talk directly to the audio devices (such as ALSA or > OSS). > > I wrote the attached patch which just makes canberra support GStreamer > via the gst-launch system command to play the specified audio file. > This just seemed simpler and more straightforward than using the > GStreamer library interfaces directly. It also seems to work reasonably > well on Solaris. > > However, for this to work I had to add a new interface > (ca_sound_get_filename) to read-sound-file.[ch] since the filename > that the gst-launch command needs is not otherwise exposed. > > Is this a reasonable way to solve the libcanberra backend problem > (at least for now) on Solaris? Or do people think it is really > necessary to write code that links with the GStreamer or Sun Audio > interfaces directly? I am not generally against having a gst backend. Multiple people have asked for this. However, I am not particularly fond of a solution that forks off gst-launch for every single sound, because it is very slow, and also dirty in my eyes. A while back, Marc-Andre Lureau from Nokia sent a patch for a gst backend, which linked directly against the gst libraries. And was also capable of cacheing prebuilt pipelines. I'd much rather see this patch cleaned up and merged than the fork solution you proposed. Maybe you guys can work together and make this work? I don't think it is a particular good idea to stack abstraction layers on top of each other. Which means I'd much rather prefer if libcanberra would have native backends for all output systems in question, than running the abstraction layer that libcanberra is on top of another abstraction layer that is Gst. OTOH I of course don't care enough about Solaris, to really mind if you guys stack your layers as you wish. The main reason why Nokia wants this gst backend is not such much abstracting output backends but their endless love for MP3 and hatred for Vorbis -- at least as far as I understand. Having said all this, you can of course always patch the libcanberra version you guys package with this patch of yours. But I am not really happy with merging it upstream like this. Finally, I think code that first checks if a file is there and then opens it is racy. It would be better to extend ca_lookup_sound() to take a callback function which is called for each possible candidate and then can be used to open it directly via GstFileSrc or similar. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ libcanberra-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/libcanberra-discuss
