From owner-freebsd-multimedia@freebsd.org Mon Dec 18 15:16:47 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 C641DE9266C for ; Mon, 18 Dec 2017 15:16:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (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 5A6B17F029 for ; Mon, 18 Dec 2017 15:16:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Mon, 18 Dec 2017 16:16:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1513610203; bh=5jCr24u3x5i97mKO+yzJfwuCXcwd8V/DJzfjwD9RPwo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=3YhkxRoKilyBBGpUmWQ3aE80KtIFnKV2v1Cc6SvUMnfATwgxy8q9sqbhbC4WW6+eK KbwICl1x5/DagaR0vTviMWKHUYsolvuuKuEmoTAfLoRsJLWn8vIuLVAM2mfovzA2kV EIdjWBoch6LO9+7cmMJCBQJ5OEZjMY2oMzrIU6mXMvcVrzQXudTyUMMQQUKDLQO7U5 ZmfBqFBVYZj3a1NS2GuLcqzAwUUqYoFdiHmUFa/hEVny7vyNadDmAAaKLlbFvdZ2zT 1PMqyfk93hlLfXLEs8jpL1Rxm/id1wiDTSlwxPlQM6wQT2Ok8NPoUPruzejMogYCeE kYi2lIlOD8JSA== Message-ID: <20171218161614.Horde.rLEhw6yp6nTppNjkXU-WxBF@webmail.leidinger.net> From: Alexander Leidinger To: blubee blubeeme Cc: 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> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_GgH9QUiP51JY2JR_BmNv504"; 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 15:16:47 -0000 This message is in MIME format and has been PGP signed. --=_GgH9QUiP51JY2JR_BmNv504 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting blubee blubeeme (from Sat, 16 Dec 2017=20=20 21:49:08=20+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 applications = w/o >>> needing to implement special kernel kludges >>> >> >> You are mixing API (soundcard.h) with implementation (FreeBSD kernel sou= nd >> 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=20=20 but=20another implementation of the same API. I had a look (well... more a glance) at the IOCTLs and other stuff (=3D=20= =20 the=20API). Most of them are the same. There are minor differences which=20= =20 most=20probably mean we are implementing the OSSv4 API in v4.0, while=20=20 4Front=20has moved on to OSSv4.2. Those few differences, can probably be=20= =20 implemented=20in FreeBSD by someone who is interested easily. The main=20= =20 point=20here is, are those differences that important? The parts you=20=20 complain=20about are not related to those differences of the API. [a lot of technical details and questions from me cut... you didn't=20=20 respond=20to 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 o= n > 2018. > > https://web.archive.org/web/20111001142728/http://4front-tech.com/hannubl= og/?page_id=3D34 I've read this article. It talks about userland issues in=20=20 applications,=20not 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=20= =20 someone=20can 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=20=20 where=20it is bad. Concrete examples instead of just telling it is bad.=20= =20 My=20questions you skipped were targeted to find out what is not OK. So=20= =20 far=20you haven't delivered an answer. I'm eager to see answers to them.=20= =20 So=20far I've seen you (at least to my understanding) mixing up=20=20 "implementation=20of an API" (=3D kernel code) and "API" (soundcard.h),=20= =20 and=20in the API mixing up "there are differences which don't matter for=20= =20 the=20API" (but matter for the ABI, but this is relevant for=20=20 compatibility=20between FreeBSD X and FreeBSD Y) with "this is not OSSv4=20= =20 API".=20You complained about optional parts in the sound system which=20=20 are=20disabled by default (sysctl) in a way I was understanding as that=20= =20 you=20complain that they are there at all (while the presence of the=20=20 possibility=20not being related or affecting the ABI nor can be=20=20 attributed=20to misbehavior). I'm sure we will be open "to do something", but only if there are=20=20 specific=20areas pointed out and validated to be bad, instead of just=20=20 telling=20"all is bad" mixing up things while talking about it and not=20= =20 being=20specific at all so that other people can validate that the parts=20= =20 you=20complain about do not work as intended. And if you reference to "linuxims" refers to the fact that we have=20=20 jack=20and portaudio and whatever in the ports collection... well, this=20= =20 is=20not related to the FreeBSD sound system at all, those are 3rd party=20= =20 applications.=20We will not restrict which program someone wants to use=20= =20 on=20FreeBSD, and if those using those programs are happy with it, it is=20= =20 not=20related to the FreeBSD project at all. Do I agree that programs=20=20 would=20be better of to use the FreeBSD native API instead of of some=20=20 intermediate=20layer? In a lot of cases surely yes. Is this a=20=20 responsibility=20of the FreeBSD project? Not at all. We are an open=20=20 source=20project which relies on contributions to get "linux-programs"=20= =20 up=20and running (=3D ported) to FreeBSD. If you find such a program which= =20=20 doesn't=20behave very good on FreeBSD, you can help fixing it (by=20=20 sending=20patches which make it work better on FreeBSD to the developers=20= =20 of=20the application in question), or find people in the FreeBSD=20=20 community=20which may be interested to help fixing those programs.=20=20 Removing=20those middle-layers from the ports collection is surely out=20= =20 of=20question as long as there is a program which depends upon one of=20=20 them. In=20short: if you want that people agree that something is not good,=20=20 you=20need to come with specific items and detailed instructions how to=20= =20 repeat=20what you see, so that it can be validated / repeated by someone=20= =20 else. Bye, Alexander. --=20 http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_GgH9QUiP51JY2JR_BmNv504 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----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----- --=_GgH9QUiP51JY2JR_BmNv504--