From owner-freebsd-multimedia@freebsd.org Sat Dec 16 13:34:36 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 7EE0DE82885 for ; Sat, 16 Dec 2017 13:34:36 +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 03E3863EF2 for ; Sat, 16 Dec 2017 13:34:35 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Sat, 16 Dec 2017 14:33:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1513431266; bh=KfJPvGEKZeh/eCrQV7lxhBF+MxZnHlLZbwRbjBsf4+E=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=0oQDI3YkstA/CYsou+qUfjKsK2B6+zZYdCQzATvdOy0NnXnqv09JMpXGYsPqsOhIz QJLQhBTPVUn8rIE8yn3OCSFucCgh9Lc7LvZOo3PyiEIGOiCdl3NA0smX+5W9NnTMhG BHkWrJqUCWF6Pir1WPF1iQPRYJiL45Q/EbgozBBprvKPRtO5wZbNi3BOdAPuCmbyNs ixTAqGdHzZ+YLuN9IkfoMO0yzwkyZ7ZRhQFrPAGvOt2omuxg/d80QnBqOxova3/Yfj DkpvDa6HsLAXCQPq/NbWEyVdDzW4mjH9QG76+7zSH9/rnBbS66pKzeUEoMDtVcryYN cPiMbCPQJGbsQ== Message-ID: <20171216143349.Horde.VJOddyv79ydlAmvsvoTRhMP@webmail.leidinger.net> From: Alexander Leidinger To: blubee blubeeme Cc: Hans Petter Selasky , 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> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_K580ClzmmfOP_x0pb-vaMYh"; 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: Sat, 16 Dec 2017 13:34:36 -0000 This message is in MIME format and has been PGP signed. --=_K580ClzmmfOP_x0pb-vaMYh 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 09:39:04=20+0800): > On Sat, Dec 16, 2017 at 8:16 AM, Alexander Leidinger < > Alexander@leidinger.net> wrote: > >> Quoting blubee blubeeme (from Fri, 15 Dec 2017 >> 22:39:25 +0800): >> >> What's with the stuck up attitude? Stay focused on the issue at hand whi= ch >>> is FreeBSD's fork of OSS makes it a challenge to implement software tha= t >>> sticks to the OSS standard. >>> >>> There's nobody actively working on improving the audio situation on >>> FreeBSD. You have a user/developer who wants to do the work and you rea= ct >>> >> >> Can you please describe in features / bullet-points what is missing >> instead of saying "X is better than Y"? >> >> like it's some personal attack on your person to update the underlying >>> code. >>> >>> Guess what, most of the clever features you talk about are in OSS4 and = if >>> they are not, they can still be added. >>> >> >> What I understand what you say is: >> - I want to replace X by Y, because Y is better. >> - Anything what is better in X can be added to Y. >> >> So basically I understand that you want to replace incomplete feature-se= t >> in X by an incomplete feature-set from Y (without knowing what the >> incompleteness in either X or Y is). > > There's no incomplete "feature" what I am saying is the changes made for > compatibility brought forward legacy application bugs. > When you update to clang 4 and a lot of your code breaks because they use > depreciated coding standards, do you patch clang or > do you fix your software? I consider this a bad example. The word "legacy" already implies that=20=20 you=20have a new way of doing things, wheres as comparing clang and gcc=20= =20 is=20not putting a new meaning to the input source code, but=20=20 transforming=20the source code based upon pre-defined rules. And yes, if=20= =20 there=20are cases where the source code which is compiled is wrong, and=20= =20 not=20clang. Regarding the issues you have with "compatibility aspects", I will=20=20 comment=20upon below. >> And to bring in some technical info (parts of "AFAIR", I may >> misremember...): >> - The OSS code in FreeBSD was at some point in time the 4Front OSS code= . >> - At some point 4Front closed-source their implementation and FreeBSD >> deviated. >> - At some point Ariff put in an effort to advance the OSS code in FreeB= SD >> which made it the best in various aspects (one of them latency) when >> compared to 4Front code, Windows, MacOS and Linux ALSA. >> - Then in 2006 Ryan was adding OSSv4-API compatibility to the FreeBSD >> sound code as part of the Google Summer of Code, mentored by Ariff and m= e. >> - Since then I don't remember big API changes/improvements... HPS worke= d >> a lot on USB audio support, userland drivers and AFAIK some MIDI stuff a= s >> part of the userland drivers, but all that is more or less drivers, not >> API... please correct me if I got this wrong; and mav(?) worked on HDA >> support (also driver, not API). >> > I posted a link below as a reference and some reasons why those changes > were not a good idea. > The whole point of ossv4 was to implement simpler API and depreciate lega= cy > audio application coding styles. And we have the OSSv4 (=3D simpler) API, as such we are not different=20=20 from=20an API point of view. >> Note, various aspects of the FreeBSD sound code can be tweaked by sysctl= s, >> e.g. latency, virtual channels, direct physical access ("bitperfect"), >> automatic resampling, equilizer, ... (see "sysctl hw.snd dev.pcm dev.hda= a >> dev.hdac" and "man sound snd_hda snd_uaudio" and the SOUND_4.TXT of Arif= f >> you mentioned). >> >> And regarding your comment about SOUND4.TXT: if you read this document >> carefully, you will notice that the part you quoted as being bad can be >> disabled. >> > It's not about being bad and can be disabled, if the API is still there > then people will copy old coding practices guaranteeing that newer audio > applications > are still plagued by the crud from legacy audio API. So you suggest we remove parts of your sound API? Which ioctls do you=20=20 want=20to remove? > So you leave that stuff there, with FreeBSD providing NO documentation/ > tutorials/ example programs of how to write decent sound applications. As we implement the OSSv4 API, why should we come up with a newly=20=20 written=20documentation of it? > A dev comes along and copies some code from an older application and brin= gs > forward all the legacy coding practices, but sure they use JACK audio, > it seems to run okay, now you try to port the application to FreeBSD, the > sound quality is bad or it's janky oh, FreeBSD sucks at audio. You think that people target FreeBSD with audio applications? I wish=20=20 this=20were true. Normally an application is written for Linux, and then=20= =20 someone=20tries to make it work on FreeBSD. It then all depends upon the=20= =20 skills=20of the person trying to make it work on FreeBSD, and on the=20=20 internal=20architecture of the program in question. No matter what kind=20= =20 of=20implementation of whatever API we use in FreeBSD, it doesn't matter=20= =20 as=20long as nobody targets FreeBSD in an audio application as (one of)=20= =20 the=20primary OS. > 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=20=20 sound=20code) and ways to change its behavior (sysctl). > 2)OSS v4 API docs explain how NOT to keep programming in the legacy style > that causes jank audio > The main way this was accomplished was by removing the exclusive acces= s > to the sound hardware, And we do that (several applications can access in parallel by default=20= =20 =3D no exclusive access). So what is not OK here? > this > > link: https://people.freebsd.org/~ariff/SOUND_4.TXT > > hw.snd.vpc_mixer_bypass (default=3D1, enabled) > > OSSv4 Compatibility: > Mostly, but we did it a 'better' way, like providing a special > bypass mode for legacy applications. > > This linuxism literally carried forward all the bugs from the past, 4Fron= t > oss handles this transparently, no need for these types of switches since > they'll allow devs to carry forward their bad programming habits. What this is about that we allow that old applications still work.=20=20 This=20is a part of the FreeBSD guarantee that old applications still=20=20 work=20on newer releases (ABI compatibility). The FreeBSD community=20=20 considers=20this as a benefit. For this specific case, what is the bug you see here? For a legacy=20=20 application=20it looks like it has exclusive access to the mixer, while=20= =20 it=20hasn't. For the application itself there is no bug here (it only=20=20 controls=20the mixer part of its own sound stream), and the user has the=20= =20 benefit=20of having multiple applications accessing the sound system. > If you update to the latest version of 4Front oss, this is handled, no ne= ed > to main the code behind this stuff. I fail to see the bug in FreeBSD here. So I see no benefit in=20=20 replacing=20this with 4Front oss. What did I miss? > ----- > > ----- > > dev.pcm.X.[play|rec].vchanmode (default=3Ddepends...) > 'fixed' or '0': > The good old mode. Channel mixing is done using fixed > format/rate. Digital passthrough or other advanced operat= ions > will not work in this mode (consider it as a 'legacy' mod= e). > For hardware channels that doesn't support digital=20=20 >=20formats, this > is the default mode. > > 'passthrough' or '1': > Channel mixing is done using fixed format/rate, but advan= ced > operations such as digital passthrough or 'Exclusive Acce= ss' > (#6 down below) will start working. All channels should > produce sound as usual until there is a request for a dig= ital > format playback, which in this case will 'mute'=20=20 >=20other channels > and let the latest incoming digital format pass through > undisturbed. Multiple / concurrent digital streams are > supported, but the LATEST stream will take precedence and > mute all other streams. > > 'adaptive' or '2': > Advanced mode. Works like much like'passthrough' mode, bu= t is > a bit smarter, especially for multiple pcm channels with > different format/rate. Whenever a new channel is=20=20 >=20about to start, > it will scan the entire list of virtual channels and > decide which > format/rate is the best (mostly, the higher/bigger).=20= =20 >=20This will > ensure that the quality of mixing depends on the best of = all > channels. The (bad) side effect of this mode is that the > hardware DMA needs to be restarted and might cause annoyi= ng > pops/clicks, but for a long running playback, this issue > might be acceptable. Any changes for current format/rate = can > be seen through the output of sysctl > dev.pcm.[play|rev].vchan[format|rate]. > > OSSv4 Compatibility: > 4front OSS incapable of doing this magic. > > There's nothing K.I.S.S. about this and again, all this "magic" is what's > making audio programming a mess. The default is what works for a lot of users, and doesn't contain any=20=20 magic=20at all. Only when you enable it on purpose you will get extended=20= =20 possibility.=20At least in 2009 when this document was last updated,=20=20 4Front=20did not provide those extended features. I don't know the state=20= =20 of=20this in current 4Front code. Feel free to explain if and how they=20= =20 handle=20it today (if they catched up to what FreeBSD is able to do, and=20= =20 how=20the handle it in the API). > ----- > > ----- > > 5) Bitperfect > > OSSv4 Compatibility: > SNDCTL_DSP_COOKEDMODE is mostly compatible, except that it=20=20 >=20will handle > complex situation with vchans enabled 'better' compared to=20=20 >=204front OSS. > > Again "better" compared to 4front oss, how so? That's off course a good question. My guess is, that this refers to=20=20 the=20extended features which are possible (see "adaptive" above). So=20=20 still,=20currently I fail to see what is less good in FreeBSD than in=20=20 4Front=20code. > ----- > > ----- > > 6) Exclusive Access > > OSSv4 Compatibility: > This feature is mostly compatible with OSSv4, except that 4front = OSS > prevents all other applications from running (stalled/halted, oth= er > unknown grave effects) if any sound device being accessed in a su= ch > way. FreeBSD does this smartly on top of the Transparent / Adapt= ive > Virtual Channel. > > This is the main issue and a cause for so many sound systems. If this isn= 't > removed and have those applications use legacy mode of the default 4Front > soundcard.h and follow better codinig practices into the future, no amoun= t > of sound architecture rewrite will help. You have not included the remark that this is not enabled by default.=20=20 This=20means that an user has to specially enable it to have exclusive=20= =20 access=20working. The outcome is that in case an application wants to=20=20 have=20exclusive access (e.g. by accident or programming error or legacy=20= =20 code),=20this is not respected and the user still gets sound output from=20= =20 multiple=20applications. > This bypass is what lead to ALSA, JACK v1-v2, and Pulse, which still don'= t > solve the problem of janky audio. This isn't a feature it's a bug. When you have multiple applications doing sound output, there is no=20=20 janky=20audio output. At least not to m knowledge. IF there is, then=20=20 please=20provide a way to reproduce this behavior. Additionally those audio systems - to my knowledge - have "multiple=20=20 audio=20streams at the same time" as a feature, which we don't need in=20= =20 FreeBSD=20because it just works by default. > audio/virtual_oss doesn't make up for that. virtual_oss is not meant as a competition to ALSA, Jack or PulseAudio.=20= =20 Think=20about it as a way to implement userland audio devices or virtual=20= =20 hardware. >=20----- > > You guys say I am claiming that X is better than Y, maybe you should read > the reference link that I shared above. > > 4Front oss already has a soundcard.h file that implements and support all > the legacy applications, they could've ripped that code out but left it > there for compatibility. > > Read the warnings about legacy audio applications and why ossv4 was > implemented the way it was: > http://manuals.opensound.com/developer/ossapi.html You are talking about the API here. The way a program is written to=20=20 access=20the sound system. When you complain about by telling we shall replace the sound code in=20=20 the=20kernel by the opensound code is not the API, it is the behavior=20=20 which=20is invoked when a program uses the API. Those are two different things. Maybe this is the cause of misunderstanding here. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_K580ClzmmfOP_x0pb-vaMYh Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJaNSC9AAoJEKrxQhqFIICEfI0QAJoGau2MjRWrHQJFto3oSygO E4YsVSwGWeG8gbUtRbswqBmK5XJoDPLOTOedMNXBYETD0VVC0+ECJxNqjsokIsvA vBzzYbgbV5Y9xmW6Y6/ahaMngcaPKjjvQsLjvrHHRKnnxMB+nqIaOvTsf1u5xDwT XGtAnV97h3GWqPQijK3F0e25q/JV1C5tadAvE10IuWx5KMPWrw2az9xvpHWKUdqC KaO6gDjWvQmK1aXnDmxQeYH6tAZBOPHxHoDsI2i1rrNqTT/AFwJoDCDT1ZAFGGAw xq3CElHouS1zub6vA5R8z8tG2y6HaAv28tk3TkMXQBPi3uFB0zkwTzsfNXdTLlL4 78ZdLwyP+7FNXDTEbo2ssqIwprpMDHMZkqzO5hbfs11W6CO17VqYPYHDL3r5ztGr ii2R7PbUooTvIm59Y43sQEMdar6r5a2dmbM/zvHaFUOGmoOR83iZNjSAf0Li1RyB 03wHt+Vm5tsfWS8HaTl7lb/UQuTQZbdKhRZGZ7NIp4ohkcOc3MjtpxebHqonaEi7 DZvVxDFqjhjpMb3DxzFPBGO/cud8wVtwT/Hfxmm71t3EHjnZtVs/rKOAPVYelAh1 cWiNp3aBOHXR7duVlO3qzbpZVKI4/n9krwt55FXLnxbet5rrbUTbwjDiolf+0Sjt iSsWPHSB+49sXgQLDV9b =tp19 -----END PGP SIGNATURE----- --=_K580ClzmmfOP_x0pb-vaMYh--