Date: Mon, 18 Dec 2017 18:33:53 +0100 From: Alexander Leidinger <Alexander@leidinger.net> To: freebsd-multimedia@freebsd.org Subject: Re: FreeBSD amd64 GENERIC kernel Message-ID: <20171218183353.Horde.xayrSeFXKKiQwenaLS-GOsK@webmail.leidinger.net> In-Reply-To: <CALM2mE=eDY0%2B1-O4HWLJ2C-FG_tjRb7goX1D_1WkmPiw_bB%2B=g@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> <d92eae76-831b-3a6f-a7a6-4f4d7e66df99@selasky.org> <CALM2mEmnxsdwy5rr9ApC3q7kZ2-EK2YYBqMAibd9nA3XRfhKhQ@mail.gmail.com> <20171216011614.Horde.Uitm74qhBEwh_NRo9RgDgu3@webmail.leidinger.net> <CALM2mEm0WWqHx=67tPf9_ah1PAfUEirREpTiRmvEKxZ_YR7u-g@mail.gmail.com> <20171216143349.Horde.VJOddyv79ydlAmvsvoTRhMP@webmail.leidinger.net> <CALM2mEkhFVbDKVbx-1BcP355-mOqfsYUeDOPkVisWT3_6AKh2g@mail.gmail.com> <20171218161614.Horde.rLEhw6yp6nTppNjkXU-WxBF@webmail.leidinger.net> <CALM2mE=eDY0%2B1-O4HWLJ2C-FG_tjRb7goX1D_1WkmPiw_bB%2B=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed. --=_ephHPOxRN0aWP4QZjDjQISA Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting blubee blubeeme <gurenchan@gmail.com> (from Tue, 19 Dec 2017=20=20 00:08:41=20+0800): > On Mon, Dec 18, 2017 at 11:16 PM, Alexander Leidinger < > Alexander@leidinger.net> wrote: > >> >> Quoting blubee blubeeme <gurenchan@gmail.com> (from Sat, 16 Dec 2017 >> 21:49:08 +0800): >> >> On Sat, Dec 16, 2017 at 9:33 PM, Alexander Leidinger < >>> Alexander@leidinger.net> wrote: >>> >>> Quoting blubee blubeeme <gurenchan@gmail.com> (from Sat, 16 Dec 2017 >>>> 09:39:04 +0800): >>>> >>> >> The whole point of implementing 4Front oss and not a FreeBSD for is to >>>>> K.I.S.S. >>>>> Here's why >>>>> 1)OSS v4 soundcard.h and code already hdandles ALL legacy application= s >>>>> w/o >>>>> needing to implement special kernel kludges >>>>> >>>>> >>>> You are mixing API (soundcard.h) with implementation (FreeBSD kernel >>>> sound >>>> code) and ways to change its behavior (sysctl). >>>> >>> >> I just had a look at our soundcard.h and their soundcard.h. >> Yes there are differences, but this is expected as it is not a copy but >> another implementation of the same API. >> >> I had a look (well... more a glance) at the IOCTLs and other stuff (=3D = the >> API). Most of them are the same. There are minor differences which most >> probably mean we are implementing the OSSv4 API in v4.0, while 4Front ha= s >> moved on to OSSv4.2. Those few differences, can probably be implemented = in >> FreeBSD by someone who is interested easily. The main point here is, are >> those differences that important? The parts you complain about are not >> related to those differences of the API. >> >> [a lot of technical details and questions from me cut... you didn't >> respond to any of the serious questions I've put there] >> >> These are some blog posts from mid to late 2000; Please read it and >>> understand what's he's trying to express; Then look at the audio progra= ms >>> and see how they continue to make the same exact mistakes in 2017 going= on >>> 2018. >>> >>> https://web.archive.org/web/20111001142728/http://4front-tec >>> h.com/hannublog/?page_id=3D34 >>> >> >> I've read this article. It talks about userland issues in applications, >> not about issues we have in our kernel code. >> >> Where are these audio app developers who should be chiming in? The few >>> applications that I've ported: audio/amsynth and audio/yoshimi >>> one has OSS support already, the other one I am developing. >>> Working on implementing the OSS support I am running into issues >>> >> >> Feel free to open a new thread about your issues in multimedia@, maybe >> someone can point you in the right direction. >> >> Instead of listening u guys keep repeating FreeBSD audio is Great.... >>> >> >> I don't tell it is great. I tell you haven't managed yet to point out >> where it is bad. Concrete examples instead of just telling it is bad. My >> questions you skipped were targeted to find out what is not OK. So far y= ou >> haven't delivered an answer. I'm eager to see answers to them. So far I'= ve >> seen you (at least to my understanding) mixing up "implementation of an >> API" (=3D kernel code) and "API" (soundcard.h), and in the API mixing up >> "there are differences which don't matter for the API" (but matter for t= he >> ABI, but this is relevant for compatibility between FreeBSD X and FreeBS= D >> Y) with "this is not OSSv4 API". You complained about optional parts in = the >> sound system which are disabled by default (sysctl) in a way I was >> understanding as that you complain that they are there at all (while the >> presence of the possibility not being related or affecting the ABI nor c= an >> be attributed to misbehavior). >> >> I'm sure we will be open "to do something", but only if there are specif= ic >> areas pointed out and validated to be bad, instead of just telling "all = is >> bad" mixing up things while talking about it and not being specific at a= ll >> so that other people can validate that the parts you complain about do n= ot >> work as intended. >> >> And if you reference to "linuxims" refers to the fact that we have jack >> and portaudio and whatever in the ports collection... well, this is not >> related to the FreeBSD sound system at all, those are 3rd party >> applications. We will not restrict which program someone wants to use on >> FreeBSD, and if those using those programs are happy with it, it is not >> related to the FreeBSD project at all. Do I agree that programs would be >> better of to use the FreeBSD native API instead of of some intermediate >> layer? In a lot of cases surely yes. Is this a responsibility of the >> FreeBSD project? Not at all. We are an open source project which relies = on >> contributions to get "linux-programs" up and running (=3D ported) to Fre= eBSD. >> If you find such a program which doesn't behave very good on FreeBSD, yo= u >> can help fixing it (by sending patches which make it work better on Free= BSD >> to the developers of the application in question), or find people in the >> FreeBSD community which may be interested to help fixing those programs. >> Removing those middle-layers from the ports collection is surely out of >> question as long as there is a program which depends upon one of them. >> >> In short: if you want that people agree that something is not good, you >> need to come with specific items and detailed instructions how to repeat >> what you see, so that it can be validated / repeated by someone else. >> >> >> Bye, >> Alexander. >> >> -- >> http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF >> http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF >> > I was actually having this conversation on both current mailing list and > multimedia. > The conversation is still on going on multimedia list somewhat. > > There seems to be a lot of misinformation out there about OSS that needs = to > be dispelled first. > Then I wanted to get to the actual point of implementing the 4Front OSS a= nd > sticking to that API. > > Before things can be fixed, the problem has to be clearly defined and I'v= e > been looking at this issue > for a while since I am interested in multimedia. > > My main purpose is simplicity. > > Here's a general overview of the problem as I see it. > > There's no real audio programming guide to speak of on FreeBSD, pointing = me > to OpenBSD doesn't cut it. > Most of FreeBSD audio tools come from other platforms, even the OSS > implementation is a fork of an earlier > version of 4Front OSS. > --sure FreeBSD was able to implement some features [virtual mixing, etc] > before 4Front, then came sndio, pulse and all those other frontends > that were basically copying Linuxisms right into FreeBSD. > --Linux did the same thing with ALSA, then Jack1, Jack2, Pulse and whatev= er > else the come up with next. > > They didn't understand the main issue and were trying to reduce latency > when that's not really a concern for most devs or users. > Then Hannu closed source his code to try to make a living off of his work= , > that didn't go so well and now we have; > ALSA, JACK1, JACK2, PULSE, SNDIO and others that I don't care to look int= o. > > It doesn't matter how many times they create new sound architecture, unle= ss > the root issue of bad audio programming > is rooted out, they'll just keep on coming up with the new next best thin= g. I understand this as you say that the audio applications which make=20=20 use=20of no matter which sound architecture need to be fixed first. But=20= =20 then=20you start below with modifying the FreeBSD kernel... > Remember that it was Hannu who created the first audio driver for Linux, > it's that same legacy that everyone has been using > to this day. > > This is how I think that all this could be simplified. > 1) Get OSS 4.2 into FreeBSD kernel This can mean looking at what the differences between our OSSv4 and=20=20 the=204Front 4.2 API are, and then implementing them in the FreeBSD=20=20 code,=20or to take the 4 Front code and put it into FreeBSD. > 2) create proper audio programming guide for the FreeBSD Handbook > based on: http://manuals.opensound.com/developer/ > making sure to remove all the depreciated API calls, the manual is > very well documented. Given that with the OSSv4 API we implement, you can already program a=20=20 lot=20of audio applications without missing any functionality, why not=20= =20 first=20create such a documentation for the existing implementation, and=20= =20 then=20to look at changing the FreeBSD kernel. With this some=20=20 (interested)=20people could have already a look at improving audio=20=20 programs=20in parallel. This would fit what you write above about (as I=20= =20 understand=20it) first fixing the applications. As the API will be=20=20 mostly=20the same (let's say 95%) no matter which implementation is in=20= =20 the=20kernel, this seems to be a non-regret starting move in my opinion. Besides this, the FreeBSD handbook is not a programming manual, it is=20=20 more=20an operations guide / sysadmin tasks manual. As such what you=20=20 want=20to do doesn't really fit for the target audience of the FreeBSD=20= =20 handbook.=20What you talk about is more a developer manual (the=20=20 architecture=20manual may fit... to be evaluated). Right now we don't=20=20 really=20have a "one manual for all FreeBSD programming related things".=20= =20 As=20such I would suggest to have a "FreeBSD sound programming" (or=20=20 similar)=20document first. This could even be started in the FreeBSD wiki. Maybe you want to have a look at: https://wiki.freebsd.org/Sound > One of the nicest feature of 4Front OSS is that, > without changing a line of code legacy OSS applications should just work. This is the same for the FreeBSD sound code. > The main issue is that new audio programs are being written based on > the legacy programming style. And as FreeBSD implements the OSSv4 API, this looks again like work=20=20 should=20first be put into a programming manual instead into kernel code. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_ephHPOxRN0aWP4QZjDjQISA Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJaN/wBAAoJEKrxQhqFIICEzEUQAIcxLIJfyHcTOp6110iVkhRT jBSzkhl53C9Ljb238Rpl2sY3bwmBGCR/doJQLscIz/DnC6HNFsdez39couL5z7JE DQaYiX4DW+Kni5EW3ytkM46zCiA7c1ixm307RzcCGsPcR4O7/Uf5IlKdP7JQImlt pXkdjFfgpDceoze/+0NdPzgFM/LLZ1SfW1d7j/SlBCeq/4oBfJ9TAyIXvkKcKKu/ I7dd+fOUpTN05zsRQK2vgurr+0TTSncQxjyitEISu6NWFLSqZ7KDkU0eYhsYVnnn vdgi5uPlPIMP5eHl6s83rTkmiTKYhFvTe3lvFnxYkZXShiri74sVEsVXTW4m5t6x oeW40Ex5QYbzYfuwG+yHmvOf3giRYOkEN4piMQAO3epGrhrSlcgY90QDUohY4vFS CvQ/dp8SFfqvO2yNDr0P5DJRr3Q+DRBag3vohC0PL8BwqQ0gHx1OBF2AE1SwD5+z RKewMm+iezmii5xfllCaMbIaijrIw3fwmVdMwkzDFt2yrEvCHnc9DSsjukvQo4Pi 7q+zJRLmHuMfy9ToRQuxkRNoVclgj+HjxIjcvansssmglp47UrVBzjF+uULgmt3P XcgRADM/K4YzNGL18nh+ETdoQd18Ft7t2HATzPSj4IQJ7eG8PztMpWv3OpIwfJJE 4hTM2kHMplahEVUW/cMv =UNRk -----END PGP SIGNATURE----- --=_ephHPOxRN0aWP4QZjDjQISA--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171218183353.Horde.xayrSeFXKKiQwenaLS-GOsK>