Canberra

blubee blubeeme gurenchan at gmail.com
Wed Dec 20 07:26:43 UTC 2017


On Wed, Dec 20, 2017 at 3:04 PM, Sid <sid at bsdmail.com> wrote:

> According to http://0pointer.de/lennart/projects/libcanberra/#status
> updated September 2012
>
> "libcanberra is mostly feature complete. For now however it includes
> backends only for ALSA, PulseAudio, OSS and GStreamer."
>
> "The OSS driver is incomplete: only sound files that are in a format
> natively understood by the sound card are supported. If the sample type,
> channel map or sampling rate of the sound file are not supported by the
> sound card no automatic conversion will take place and the file will not be
> played. Also note that the OSS backend is most likely incompatible with
> OSS4, due to subtle incompatibilities between OSS4 and the OSS 3.x."
>
> "It is recommended to always take the "shortest" path from libcanberra to
> the audio device. I.e. don't use the GStreamer plugin if libcanberra
> supports the final output target natively. Besides being more
> resource-friendly and less error-prone, some advanced functionality might
> get lost with each layer you add to your stack. For example: while you
> could use libcanberra's Gstreamer backend to output to a PulseAudio server
> this will not be able to make use of sample cacheing or will be able to
> attach additional meta data to the sounds played, which might be necessary
> for effects like positional event sounds."
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>

@Sid
I know this.
These are just some of the reasons why I wanted to make sure that the OSS
in FreeBSD is actually up to snuff
because working on fixing issues like these the easiest route is; just use
ALSA or some such crap which is
unacceptable to me if it can use OSS.

When devs take the easiest path then instead of fixing the root issues,
problems are compounded;
just like the example you gave of layering pulse on top of gstreamer, those
"solutions" are brittle and will
inevitably break.

I'd like to have a solid foundation and build from there, not be constantly
trying to re-implement the wheel.

This is just one OPTIONAL dependency for a piece of software that I want to
port and this software isn't
even audio related, it's an ibus plugin.


More information about the freebsd-ports mailing list