Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Dec 2017 17:47:11 +0800
From:      blubee blubeeme <gurenchan@gmail.com>
To:        Sid <sid@bsdmail.com>
Cc:        FreeBSD Ports <freebsd-ports@freebsd.org>
Subject:   Re: Canberra
Message-ID:  <CALM2mEnoY7ckajow7ydcBj6OTsauqyxRPxzCOc3wHwkx_QohZg@mail.gmail.com>
In-Reply-To: <trinity-31e68301-3574-4114-83c1-d05b06d4ad56-1513762058927@3c-app-mailcom-lxa14>
References:  <trinity-6848ca10-405f-41ae-a91f-7024aacfaf00-1513753440748@3c-app-mailcom-lxa08> <CALM2mEmfSot7UPPT=VyBKieAoM_1TAcOeRR9%2BZwN%2BQ_2C3cUEw@mail.gmail.com> <trinity-31e68301-3574-4114-83c1-d05b06d4ad56-1513762058927@3c-app-mailcom-lxa14>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 20, 2017 at 5:27 PM, Sid <sid@bsdmail.com> wrote:

> The problem with libcanberra is around pulseaudio and gstreamer. It is
> also with how gtk, a Visual Graphical toolkit, is mixed in with an Audio
> application.
>
> I didn't say you didn't know about it, I was just putting it out there.
> They've done a good job of cleaning up and fixing ALSA to work on top of
> OSS: the most obvious problems with that are fixed. Pulseaudio hasn't been
> cleaned up, which it is better for applications to avoid it all together,
> and I don't know if Pulseaudio is worth fixing.
>
> It is really a travesty that a simple program that plays simple sounds
> like "Ding!" has to be this complicated, when OSS, and sndio work, and even
> when something as complicated as ALSA was simplified enough to work
> efficiently on top of OSS.
>
> "When devs take the easiest path..." This is the Linuxism route, to pile
> on. I don't even consider that the easiest path, a lazy path instead,
> considering its usual outcome, of requiring hours to compile something
> which should compile in 5 minutes. FreeBSD and other BSD's have largely
> simplified many of these issues, recently.
>
> > blubee blubeeme; Wed Dec 20 07:26:43 UTC 2017
> > 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.
>
> Sid; Wed Dec 20 07:04:08 UTC 2017
>
> >> According to http://0pointer.de/lennart/projects/libcanberra/#status[
> 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."
>
> I'll work on it but let me get the port in the tree first, then I can
refine it.

Just as i've done with my previous ports.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALM2mEnoY7ckajow7ydcBj6OTsauqyxRPxzCOc3wHwkx_QohZg>