Date: Mon, 18 Dec 2017 16:16:14 +0100 From: Alexander Leidinger <Alexander@leidinger.net> To: blubee blubeeme <gurenchan@gmail.com> Cc: freebsd-multimedia@freebsd.org Subject: Re: FreeBSD amd64 GENERIC kernel Message-ID: <20171218161614.Horde.rLEhw6yp6nTppNjkXU-WxBF@webmail.leidinger.net> In-Reply-To: <CALM2mEkhFVbDKVbx-1BcP355-mOqfsYUeDOPkVisWT3_6AKh2g@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>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 applications 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 (= 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 has 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 programs > and see how they continue to make the same exact mistakes in 2017 going on > 2018. > > https://web.archive.org/web/20111001142728/http://4front-tech.com/hannublog/?page_id=34 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 you 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" (= 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 the ABI, but this is relevant for compatibility between FreeBSD X and FreeBSD 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 can be attributed to misbehavior). I'm sure we will be open "to do something", but only if there are specific 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 all so that other people can validate that the parts you complain about do not 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 (= ported) to FreeBSD. If you find such a program which doesn't behave very good on FreeBSD, you can help fixing it (by sending patches which make it work better on FreeBSD 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJaN9u+AAoJEKrxQhqFIICEDtwP+QGA/OlYcRGFuhXxbZT85xS8 v0GY6dmzuR+e6PU07nbl+QafQ87FLUj0IAXhr/ucd4huSvZ+njJYUDzZ5YlZxhoI 5LSVQZi1qLkfTDegubm+T9eJzh+eGsDaPJ3g64/140LTGcnmudpAQ3r9sv9nHhaS p4pKR5R+L80aBHdwOciA9iGllf8zn6HMOfTyq4CjsPvJ6bkW1BV2XW2XEzqDsHIm W7SZ/0jO1jUczCRsMwltxpQ6TxOli9LoSUNZzQrwCqJJ9okYW+1hAEYs6991jvC2 t8dMTzCo6KfOc1uSHC/PVpapwDmC7gmCjw2ZYoiwr5yCBku/ycsD0YtWAHgv4pAn LdQNQ46RPxf7etSFBI1RaF+NwvdCufIrfLI+VVYu9EHH1raMQQpM9wn9bjDFb48F b4+y/8/hQzFUWz+mdO6o5cYZVnKV+oF6wx18fDxCOl8jY8DPl7BpYEPyedZakTdl VTE9MXRecoqgSH+i+PnknMoUrxelvJYvJvqfYC2bXB2DIIlg0TNiNoEYoLqv6Yh8 8G/owoVBauitmP6e+l3nve/F44diF2/OtGC4RQOxbzpFA8/5Lfo6Nak7es6yo/jU mtbPxwD427CqPzzucshN/7gRSOAMqJejoxe21l2XMW/4GzZ7QJfw2oIzlhnkFNzd Drmi77kdCBiu87uHCTvA =O6Fg -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171218161614.Horde.rLEhw6yp6nTppNjkXU-WxBF>