From owner-freebsd-multimedia@freebsd.org Fri Dec 15 12:52:09 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 E674DE80D41 for ; Fri, 15 Dec 2017 12:52:09 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6FE0750B9 for ; Fri, 15 Dec 2017 12:52:09 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x242.google.com with SMTP id f143so18763195itb.0 for ; Fri, 15 Dec 2017 04:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1FyD13XPiM7v04ImK++zAGWqdONBfZSZoHfmxTZd2Hs=; b=TUO0EJz6ZJxFAw9LD/J3sm3fk5pV7yFK7bM2j077jkEIF84D36Jl3OJgax4U5Y8z1A QbK6ChlrFsx5W9eJp2KsEsaSgyxtRaDykSjO+kz00qsdYCUCDNIwJ/UV8lyz3muVcm2A SuxXy8wqBKBv8YlpOcgXvCCma5yyfLmOGUuX5QFJ7YbGG7swwWmW/nNPyHDWlmY7kqgT in//PbdH+gQ9exs1etTje3urUr5JrAGotrfE0g/SXvzSvTiwXyP+o0zn7acJTlixZ1fl mI48DLhfifnN0tEm0otgY1qUF7ioTeHP2civ/5/1DjeIDToxjhxC+QiAZfNfi5pHnRms tXNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1FyD13XPiM7v04ImK++zAGWqdONBfZSZoHfmxTZd2Hs=; b=Aco959Ck3uh/PV1Eaz+vu1tg6LIwy3bDzR87BsujdhVuuIfwav9BIFlkhoL+fwPTU0 Z4kbB1G+KLVVFwvL71WmG4cWf9pdUJiQULp1QVTm2elLYgp2o77+T5x/xI/DlP46ASOe ZU8nEUEnzg4ua8YOCXk5Hos3oBgH+6e8w/Mxijt+VQzsKxLGHIwkyRpIuU3DoIvjfy7C 6KUHyeBb6OkDXGZrMmGz+HMTDYd+Ip8amjEWF/YTXRnwAVHvsl7nHN8FjvtQRFLMvizA jC0Bhqx3lIZWsbu4SvoOs7ckYVNUXtsecjsqQOasTGhigSdbrtVJXI5MplgrWhzhYbQd EG0g== X-Gm-Message-State: AKGB3mIjPclCGAWySJZvzBpwVlwPdhb7P+0sXNBZC7lXGbKeXpv12F0p +uktMAG4F+fScP5dQY9teREAfnM6PfhulMzBxSAOw7wq X-Google-Smtp-Source: ACJfBot/jVF7Fies4MNPM9NCB/PbWwCHzsXlSfM0lBMaq0bWuZ08mdkgTtGiXWk4bfQ4XV2UKtv58kqNzh3QfZYaaWo= X-Received: by 10.36.116.135 with SMTP id o129mr7404066itc.119.1513342328899; Fri, 15 Dec 2017 04:52:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.134.9 with HTTP; Fri, 15 Dec 2017 04:52:08 -0800 (PST) In-Reply-To: <4eb0c57e-96fa-b75a-17f8-750154aa247a@selasky.org> References: <4c3ae20e-b6dd-d5db-0b93-2e1225daa658@selasky.org> <4eb0c57e-96fa-b75a-17f8-750154aa247a@selasky.org> From: blubee blubeeme Date: Fri, 15 Dec 2017 20:52:08 +0800 Message-ID: Subject: Re: FreeBSD amd64 GENERIC kernel To: Hans Petter Selasky Cc: "freebsd-multimedia@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 12:52:10 -0000 On Fri, Dec 15, 2017 at 8:27 PM, Hans Petter Selasky wrote: > On 12/15/17 13:03, blubee blubeeme wrote: > >> On Fri, Dec 15, 2017 at 7:33 PM, Hans Petter Selasky >> 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. >>> >>> https://forums.freebsd.org/threads/163/ >>> >>> >>> What part of oss source: >>>> https://sourceforge.net/p/opensound/git/ci/master/tree/ >>>> 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: >> https://wiki.freebsd.org/RyanBeasley >> 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: https://people.freebsd.org/~ariff/SOUND_4.TXT 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. --- How: open("/dev/dsp", O_ | 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 hardware. 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 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?