FreeBSD amd64 GENERIC kernel

blubee blubeeme gurenchan at
Fri Dec 15 12:52:10 UTC 2017

On Fri, Dec 15, 2017 at 8:27 PM, Hans Petter Selasky <hps at>

> On 12/15/17 13:03, blubee blubeeme wrote:
>> On Fri, Dec 15, 2017 at 7:33 PM, Hans Petter Selasky <hps at>
>> wrote:
>> Hi,
>>> On 12/15/17 11:34, blubee blubeeme wrote:
>>> I feel like you're talking at something and not understanding my
>>>> objectives.
>>>> It's pretty simple: replace ALSA w/ upstreamed OSS.
>>> I think you need to dig a bit more into the code itself to see what are
>>> the actual differences before I can say if your idea is good or not. I'm
>>> sorry, but I don't know opensound's code well enough to comment further
>>> on
>>> this.
>>> FreeBSD's implementation of OSS is missing a few features that hamstring
>>>> the development on FreeBSD.
>>> What are those features exactly? Why can't they be implemented in
>>> FreeBSD's sound stack?
>>> Also, why would FreeBSD want to maintain it's own implementation of an
>>> open
>>>> source project?
>>>> I believe this has been discussed before and maybe there are more
>>> threads
>>> around which will answer your question.
>>> What part of oss source:
>>>> is a binary blob?
>>>> OK, I see the source code is available and that "audio/oss" is compiled
>>> from source.
>>> --HPS
> Hi,
> Can you answer my questions please? I feel like arguing with a bot.
> You claim:
> FreeBSD's implementation of OSS is missing a few features that hamstring
> the development on FreeBSD.
> I ask:
> What are those features exactly?
> Why can't they be implemented in FreeBSD's sound stack?
> --HPS
> This is exactly what I am talking about.
>> FreeBSD OSS implementation is better, let's update it:
>> That was created in 2008 and never touched a day after, why?
>> Hey guys why don't you use oss in base, because our oss is better and we
>> make it match our kernel.
>> Okay great, can we update it, nope we don't have the manpower to do that.
>> Did "RyanBeasley (last edited 2008-06-17 21:37:27 by localhost)"
>> ever come back and did any work other than create a wiki page?
>> So, when will FreeBSD OSS fork get in sync with what's available online
>> right now?
>> What's with the circular logic here?
> When you read this document:
and search for all the "OSSv4 Compatibility:" comments
You'll see that these devs in their wisdom introduced many bugs.

One of the main ones that I'll spend some time with is this line below.
        open("/dev/dsp", O_<insert your typical open mode> | O_EXCL);

    OSSv4 Compatibility:
        This feature is mostly compatible with OSSv4, except that 4front OSS
        prevents all other applications from running (stalled/halted, other
        unknown grave effects) if any sound device being accessed in a such
        way.  FreeBSD does this smartly on top of the Transparent / Adaptive
        Virtual Channel.

This is the exact reason why so many *unix developers and users are always
claiming that the latency is high in their audio programs or *unix needs a
real time OS to do proper audio.

That was designed to fail to fix the issues from Jack/ ALSA/ OSSv3 and the
other legacy audio interfaces.

I can't name any audio program that needs exclusive access to sound

Here's the bug these "clever" developers introduced by purposefully going
around the API.

When an audio application gets exclusive access to the device, they then
try to implement their own timers as to when to release the hardware, this
is inevitably done incorrectly, this leads to janky audio because janky
developers don't want to follow protocol.

oss v4 made sure to make this type of access fail, so developers could
learn good practices but clever devs patch it out.

Then you have ALSA trying to reduce latency or Jack trying to reduce
latency or Pulse trying to reduce latency when the issue is, ignorant
developers grabbing exclusive access to sound hardware and making a mess of

There's a reason why the FreeBSD kernel guys design a few mutex locks and
tell you to use those and not try to make ur own mutex and even then people
still make a mess sometimes.

That's just one reason why what those clever FreeBSD guys did was a
terrible idea.

Can anyone on this list give me any reason they think that any piece of
software should have exclusive access to sound hardware?

More information about the freebsd-multimedia mailing list