FreeBSD amd64 GENERIC kernel
gurenchan at gmail.com
Fri Dec 15 10:34:38 UTC 2017
On Fri, Dec 15, 2017 at 6:07 PM, Hans Petter Selasky <hps at selasky.org>
> On 12/14/17 14:23, blubee blubeeme wrote:
>> On Thu, Dec 14, 2017 at 4:35 PM, Hans Petter Selasky <hps at selasky.org>
> Most OSS v4 IOCTLs are supported by the in-base sound stack at
>>> /sys/dev/sound . Further there is a ALSA to OSS wrapper in audio/alsa-lib
>>> and audio/alsa-plugins which Chromium can use.
>>> OSS provides ALSA emulation:
> You mean the audio/oss port provides ALSA emulation?
> ALSA is described here:
> From what I know ALSA is a user-space library for interacting with audio
> devices. The backend can vary from operating system to operating system.
>> But I also don't mind writing OSS drivers from chromium, why emulate when
>> you can go native?
> If you want to make a native OSS driver backend for Chromium for both
> recording and playback, then please go ahead.
> Making audio/oss the default audio stack in FreeBSD will not make most
>>> FreeBSD users happy.
> Why is this exactly? Most FreeBSD users don't even use the platform as
>> their daily driver,
>> it's just something they hack on in a VM from their shiny Macbook or
> audio/oss is intended for a specific group of audio professionals using
> FreeBSD on real machines. OSS in FreeBSD-base has far better support for
> the regular audio devices which you find in laptops, computers, raspberry
> PI, not to mention USB and VM's.
>> I can't speak for anyone but myself but I'd like to make FreeBSD user
>> friendly for regular people
>> who just want to surf the web and check their emails, this is just a step
>> in that direction.
> Despite your good intentions you shouldn't blame the in-base FreeBSD OSS
> stack that you cannot do what you want with Chromium, because the Chromium
> developer officially only supports the ALSA audio backend.
> If you want to do something good for FreeBSD, make sure documentation
> about new CPU architectures and coming chips both PCI and USB are made
> available before products are released and not several years after the
> Linux developers hacked together a driver. Second, make sure the different
> PCI and USB vendors test their products with FreeBSD aswell, before they
> release them into the market.
> This port is intended for studio professionals which buy $1000 PCI audio
>>> devices for audio production. Now with the advent of HighSpeed USB and
>>> SuperSpeed USB audio, there is no real need to invest in an expensive PCI
>>> device unless you need to do realtime audio processing. Further a lot of
>>> audio equipment also comes with an ethernet plug :-) Just FYI!
>> I am one of those guys and trust me I've had my fair share of issues with
>> Audio even on Linux.
>> You can even see this lil exchange on Ardours forum:
> What is written on page 24 in the document referred to in the link above
> is not fully true:
> The OSS API is not only for the kernel, it is a general purpose character
> device IOCTL API for any audio application. With the advent of CUSE and
> audio/virtual_oss this is especially true. If you're smart you can take
> advantage of CUSE's mmap() functionality to share memory between clients
> and server having zero copyin/copyout latency.
> The regular audio producing applications need no more than what the OSS
> IOCTL API can provide, namely setting the sample rate, sample format, MONO
> or STEREO, looking at how many bytes are buffered and that's it.
> Please also note that the OSS support in Linux may not be as advanced as
> that in FreeBSD. From what I know Linux the OSS support couldn't change the
> sample rate and format in-kernel, leaving this up to every application,
> which might be an argument against OSS in Linux, but not in FreeBSD:
> To my knowledge there is now a dozen software audio engines around for
> various Linux desktops and JACK is one of them.
> Again, I don't see a problem using libalsa on FreeBSD with applications
> coming from Linux. Even if this is a kind of emulation like you say,
> emulation can also be so-called seamless, that the user won't notice any
> difference. If there are bugs in the OSS ALSA backend, let's try to
> identify them and improve the current situation.
>> Anyways, everyone has this idea that OSS is dead or it's terrible but I'm
>> looking for the best performance
>> if you listen to this talk: https://www.youtube.com/watch?
>> You'll see that it's ALSA, Pulse & JACK that are dying/ dead.
> Linux guys like to "kill" stuff obviously and that is their motivation I
> guess :-)
>> I did a lot of audio work on Android and trust me, they try to avoid ALSA
>> like the plague.
> Reminds me of Samsungs attempt at JACK support for Android :-)
> You might say, what about ALSA? Well OSS supports ALSA emulation:
>> It just needs some work.
>> Once the updated OSS is a part of the kernel then things can move forward.
> audio/oss is not sourcecode. It is a binary blob. It won't be accepted
> into the kernel.
> How much audio progressed in FreeBSD or Linux in the past 10 years?
> Read the SVN history for "sys/dev/sound" in the FreeBSD source tree.
I feel like you're talking at something and not understanding my objectives.
It's pretty simple: replace ALSA w/ upstreamed OSS.
FreeBSD's implementation of OSS is missing a few features that hamstring
the development on FreeBSD.
Also, why would FreeBSD want to maintain it's own implementation of an open
What part of oss source:
is a binary blob?
More information about the freebsd-multimedia