FreeBSD amd64 GENERIC kernel
gurenchan at gmail.com
Fri Dec 15 14:39:27 UTC 2017
On Fri, Dec 15, 2017 at 10:15 PM, Hans Petter Selasky <hps at selasky.org>
> On 12/15/17 13:52, blubee blubeeme wrote:
>> When you read this document:https://people.freebsd.org/~ariff/SOUND_4.TXT
>> 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
>> 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
>> 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.
I'd appreciate it if you kept the discussion on sound and improve your
I gave one example of a Chromium bug where they said they'd accept an OSS
patch. I did not say janky audio in Chromium have anything to do with why I
think OSS is a better choice for the default audio system.
You've made that assumption in this thread numerous times and I've ignored
it because I wouldn't expect someone to be that dense.
It doesn't make sense because you fail to understand English, that's not my
I have been porting synth tools to FreeBSD and I'd like to continue to port
the software, implementing OSS backends for them based on the current
upstream I am running into errors because of these so called "excellent"
features which causes a lot of headache.
What's with the stuck up attitude? Stay focused on the issue at hand which
is FreeBSD's fork of OSS makes it a challenge to implement software that
sticks to the OSS standard.
There's nobody actively working on improving the audio situation on
FreeBSD. You have a user/developer who wants to do the work and you react
like it's some personal attack on your person to update the underlying code.
Guess what, most of the clever features you talk about are in OSS4 and if
they are not, they can still be added.
I'd really appreciate it if you refrained from your continued attempts at
ad hominem against me and stick to code and a discussion around ideas and
More information about the freebsd-multimedia