FreeBSD amd64 GENERIC kernel

Hans Petter Selasky hps at
Fri Dec 15 10:10:50 UTC 2017

On 12/14/17 14:23, blubee blubeeme wrote:
> On Thu, Dec 14, 2017 at 4:35 PM, Hans Petter Selasky <hps at>
> wrote:


>> 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 

> 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
> whatever.

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 

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:
> 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.


More information about the freebsd-multimedia mailing list