Date: Fri, 15 Dec 2017 20:52:08 +0800 From: blubee blubeeme <gurenchan@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: "freebsd-multimedia@freebsd.org" <freebsd-multimedia@freebsd.org> Subject: Re: FreeBSD amd64 GENERIC kernel Message-ID: <CALM2mEn=9eNHzezpkKSBydKzedqagLwtfMopuDQb9Xem7=OGUA@mail.gmail.com> In-Reply-To: <4eb0c57e-96fa-b75a-17f8-750154aa247a@selasky.org> References: <CALM2mEnnXKAyF_ti_zKYt=1m-ZTfjH5di1cayYjGM4hi9dOxRQ@mail.gmail.com> <aa346744-94c9-98a4-4de6-c5e956bf096c@ShaneWare.Biz> <CALM2mE=88_a-9FF3-e49TMPm1pGzwQn1h_wx2gofHK-NRKOpZA@mail.gmail.com> <cf0b39a9-8059-06c2-a033-109c626de225@selasky.org> <CALM2mEnfdv6R4YuSMSnR-SEtR1ief5uSg4qYWFb49dVQsRMw6A@mail.gmail.com> <ad2778be-a601-b825-1195-134dd02b04d9@selasky.org> <CALM2mEkKUr%2BrbMtS_ObXq0SYvZgFUKN9VXwqV-bxFrWVfizx1Q@mail.gmail.com> <4c3ae20e-b6dd-d5db-0b93-2e1225daa658@selasky.org> <CALM2mEkedLN%2Br2fk4YX3_Y01ENgvqo4s9yoyfBKTkBJkH56dcQ@mail.gmail.com> <4eb0c57e-96fa-b75a-17f8-750154aa247a@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 15, 2017 at 8:27 PM, Hans Petter Selasky <hps@selasky.org> wrote: > On 12/15/17 13:03, blubee blubeeme wrote: > >> On Fri, Dec 15, 2017 at 7:33 PM, Hans Petter Selasky <hps@selasky.org> >> 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_<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 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALM2mEn=9eNHzezpkKSBydKzedqagLwtfMopuDQb9Xem7=OGUA>