From owner-freebsd-multimedia@freebsd.org Fri Dec 15 14:17:59 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DD92E82776 for ; Fri, 15 Dec 2017 14:17:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EC1D7748D for ; Fri, 15 Dec 2017 14:17:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9D013260152; Fri, 15 Dec 2017 15:17:56 +0100 (CET) Subject: Re: FreeBSD amd64 GENERIC kernel To: blubee blubeeme Cc: "freebsd-multimedia@freebsd.org" References: <4c3ae20e-b6dd-d5db-0b93-2e1225daa658@selasky.org> <4eb0c57e-96fa-b75a-17f8-750154aa247a@selasky.org> From: Hans Petter Selasky Message-ID: Date: Fri, 15 Dec 2017 15:15:08 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 14:17:59 -0000 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 Hi, > > 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. --HPS