From owner-freebsd-multimedia@freebsd.org Mon Dec 18 17:34:51 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12E0AE9E37F for ; Mon, 18 Dec 2017 17:34:51 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 972AD661BC for ; Mon, 18 Dec 2017 17:34:50 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Mon, 18 Dec 2017 18:33:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1513618486; bh=+mX0fm3GMQ7mqbAJ56dmT65pa47Kisw2fLFEasmZPKM=; h=Date:From:To:Subject:References:In-Reply-To; b=xfH4HyqTPPjRnNtIHp7azojLTZsZvLtxY4cnhU/ibjaxMvTdsr8fa5c21fkwRRGSA thc+t5n66et+RYNCYSC9CXS473vrS+DC6sYPs9+e0FHD4h4JBmD/GEDPp6XlnyYWq3 kTyn7MD1/bIf7aUBogv/4RF/t12G7CqimpALrG+P0sW2ylSX9RZNI53Jgrm3cDR4MF 3tbCy58WZZ+Q+NHBY7Wpz4CalbfRbSI1MGSGyi5iAWx2SifZORzyYvZvCcsaMHzixz xFkle6uNky1PUOab4c/5CfGzfuoZE+++c3OTMFZjwihXDb6XsUz6LmUTPO3ZfGWvir 5HVvLLlF21wjA== Message-ID: <20171218183353.Horde.xayrSeFXKKiQwenaLS-GOsK@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-multimedia@freebsd.org Subject: Re: FreeBSD amd64 GENERIC kernel References: <4c3ae20e-b6dd-d5db-0b93-2e1225daa658@selasky.org> <4eb0c57e-96fa-b75a-17f8-750154aa247a@selasky.org> <20171216011614.Horde.Uitm74qhBEwh_NRo9RgDgu3@webmail.leidinger.net> <20171216143349.Horde.VJOddyv79ydlAmvsvoTRhMP@webmail.leidinger.net> <20171218161614.Horde.rLEhw6yp6nTppNjkXU-WxBF@webmail.leidinger.net> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_ephHPOxRN0aWP4QZjDjQISA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 17:34:51 -0000 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 (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 (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 (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--