Date: Fri, 15 Dec 2017 15:15:08 +0100 From: Hans Petter Selasky <hps@selasky.org> To: blubee blubeeme <gurenchan@gmail.com> Cc: "freebsd-multimedia@freebsd.org" <freebsd-multimedia@freebsd.org> Subject: Re: FreeBSD amd64 GENERIC kernel Message-ID: <d92eae76-831b-3a6f-a7a6-4f4d7e66df99@selasky.org> In-Reply-To: <CALM2mEn=9eNHzezpkKSBydKzedqagLwtfMopuDQb9Xem7=OGUA@mail.gmail.com> 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> <CALM2mEn=9eNHzezpkKSBydKzedqagLwtfMopuDQb9Xem7=OGUA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d92eae76-831b-3a6f-a7a6-4f4d7e66df99>