Lennart: >> 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.
Still, it does not seem like a program an end user would ever want to run by hand. Why would an end user want to invoke a system sound? By nature they are sounds played by the system, not the user. Sun's ARC review process has made a suggestion that, on Solaris, we move this to libexec. Would the libcanberra community be agreeable if I provided a configure patch so that the location of this script could be configured? I would probably need to put a variable in the .pc file to indicate where its located, so any dependent packages could query that, if needed. >> 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. Yes, but OSS is not yet integrated into Solaris. So, we need a temporary solution until we know what is going on with OSS. > 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. Yes, I needed a quick solution to get things working since we need to integrate this module quickly. > 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 would love to, could you provide a pointer to the code? > 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. I can see your point. However, I think it makes more sense for us to use GStreamer than SunAudio. Since Sun Audio is a dying interface that is going away, and will likely be replaced by OSS interfaces in the future, I don't see much value in writing a Sun Audio backend. While I see that stacking abstraction layers is a bit ugly, I think stacking libcanberra with PulseAudio is no worse than libcanberra with GStreamer or ESD. Note OSSv4 sink interfaces are backwards compatible with older OSS, so any OSSv3 libcanberra backend would work fine with OSSv4. > 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. That makes sense. I can see the value in allowing people to use the format they want for their system sounds. > 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. Makes sense. Could you provide me a pointer to the better GStreamer code, so we can work on that also? I would love to improve it so we can get that upstream, if possible. > 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. I do not really see any practical racy problems with checking if a file is there, and then accessing it. Do you expect people will be moving around their sound theme files frequently, causing these sorts of problems? Anyway, it does seem that it would be nice if the read-sound-file logic provided some interface to access the file directly, if desired. I see no reason to make it hidden in an internal data structure. Even if you don't like my gst-launch code, it does demonstrate that it is useful to be able to get this information in the backend plugin code. Brian _______________________________________________ libcanberra-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/libcanberra-discuss
