Date: Tue, 19 Dec 2017 01:46:09 +0800 From: blubee blubeeme <gurenchan@gmail.com> To: Alexander Leidinger <Alexander@leidinger.net> Cc: freebsd-multimedia@freebsd.org Subject: Re: FreeBSD amd64 GENERIC kernel Message-ID: <CALM2mEkhz4PgSeHq5TNp=5CnxtrFYPzMq_73uF3qUjz5KQ9wrA@mail.gmail.com> In-Reply-To: <20171218183353.Horde.xayrSeFXKKiQwenaLS-GOsK@webmail.leidinger.net> 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> <20171218183353.Horde.xayrSeFXKKiQwenaLS-GOsK@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 19, 2017 at 1:33 AM, Alexander Leidinger < Alexander@leidinger.net> wrote: > Quoting blubee blubeeme <gurenchan@gmail.com> (from Tue, 19 Dec 2017 > 00:08:41 +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 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-tec >>>> h.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 >>> >>> 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 >> and >> sticking to that API. >> >> Before things can be fixed, the problem has to be clearly defined and I've >> 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 >> whatever >> 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 >> into. >> >> It doesn't matter how many times they create new sound architecture, >> unless >> the root issue of bad audio programming >> is rooted out, they'll just keep on coming up with the new next best >> thing. >> > > I understand this as you say that the audio applications which make use of > no matter which sound architecture need to be fixed first. But then you > 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 the > 4Front 4.2 API are, and then implementing them in the FreeBSD code, or 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 lot > of audio applications without missing any functionality, why not first > create such a documentation for the existing implementation, and then to > look at changing the FreeBSD kernel. With this some (interested) people > could have already a look at improving audio programs in parallel. This > would fit what you write above about (as I understand it) first fixing the > applications. As the API will be mostly the same (let's say 95%) no matter > which implementation is in the kernel, this seems to be a non-regret > starting move in my opinion. > > Besides this, the FreeBSD handbook is not a programming manual, it is more > an operations guide / sysadmin tasks manual. As such what you want to do > doesn't really fit for the target audience of the FreeBSD handbook. What > you talk about is more a developer manual (the architecture manual may > fit... to be evaluated). Right now we don't really have a "one manual for > all FreeBSD programming related things". As such I would suggest to have a > "FreeBSD sound programming" (or similar) document 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 should > first be put into a programming manual instead into kernel code. > > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > The whole goal of starting this discussion was to get this started. There's no "Audio Programming Guide" in FreeBSD and that's a problem since the applications just get ported over and instead of implementing the OSS API people do a patchwork of kludges to get audio sorta kinda working on FreeBSD; We can do better and send the patches upstream to see if they can get accepted, if not keep them in FreeBSD. Is it possible to get FreeBSD soundcard.h in line with the one from: https://sourceforge.net/p/opensound/git/ci/master/tree/include/soundcard.h I was writing some test programs based on the documentation and a surprising amount of audio formats were not defined in FreeBSD's soundcard.h
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALM2mEkhz4PgSeHq5TNp=5CnxtrFYPzMq_73uF3qUjz5KQ9wrA>