FreeBSD amd64 GENERIC kernel

Hans Petter Selasky hps at
Fri Dec 15 14:17:59 UTC 2017

On 12/15/17 13:52, blubee blubeeme wrote:
>> When you read this document:
> and search for all the "OSSv4 Compatibility:" comments


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

FreeBSD's OSS subsystem supports both exclusive access, called 
bitperfect, where no timers are involved, and the latency follows the 
selected buffer size, and virtual OSS channels, which is the default, 
which let multiple applications perform playback at the same time w/o 
any need for any special library handling like JACK or ALSA.

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

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

It is not a bug nor failure, it is an excellent feature. It also allows 
multiple different system users to playback audio at the same time.

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

I find the logic in your English inverted. Did you forget the word "not"?

> 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
> things.
> 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?
Please spend some time to write proper English. I'm finding it hard to 
understand what you mean.

Summing up:

You want to make audio/oss from ports the default, because the latency 
in sys/dev/sound causes "janky" audio, because Chromium doesn't play 
well with FreeBSD's OSS and libalsa?    This doesn't make sense.  I 
suspect there is some misconfiguration on your side, that libalsa 
doesn't see the default FreeBSD's OSS devices through its alsa-OSS plugin.


More information about the freebsd-multimedia mailing list