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>