Date: Sat, 16 Dec 2017 14:33:49 +0100 From: Alexander Leidinger <Alexander@leidinger.net> To: blubee blubeeme <gurenchan@gmail.com> Cc: Hans Petter Selasky <hps@selasky.org>, freebsd-multimedia@freebsd.org Subject: Re: FreeBSD amd64 GENERIC kernel Message-ID: <20171216143349.Horde.VJOddyv79ydlAmvsvoTRhMP@webmail.leidinger.net> In-Reply-To: <CALM2mEm0WWqHx=67tPf9_ah1PAfUEirREpTiRmvEKxZ_YR7u-g@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <gurenchan@gmail.com> (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 <gurenchan@gmail.com> (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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171216143349.Horde.VJOddyv79ydlAmvsvoTRhMP>