FreeBSD amd64 GENERIC kernel

[Alexander Leidinger]

Quoting blubee blubeeme <gurenchan at gmail.com> (from Sat, 16 Dec 2017  
09:39:04 +0800):

> On Sat, Dec 16, 2017 at 8:16 AM, Alexander Leidinger <
> Alexander at leidinger.net> wrote:
>
>> Quoting blubee blubeeme <gurenchan at 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 which
>>> is FreeBSD's fork of OSS makes it a challenge to implement software that
>>> 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 react
>>>
>>
>> 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-set
>> 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  
you have a new way of doing things, wheres as comparing clang and gcc  
is not putting a new meaning to the input source code, but  
transforming the source code based upon pre-defined rules. And yes, if  
there are cases where the source code which is compiled is wrong, and  
not clang.

Regarding the issues you have with "compatibility aspects", I will  
comment upon 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 FreeBSD
>> 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 me.
>>  - Since then I don't remember big API changes/improvements... HPS worked
>> a lot on USB audio support, userland drivers and AFAIK some MIDI stuff as
>> 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 legacy
> audio application coding styles.

And we have the OSSv4 (= simpler) API, as such we are not different  
from an API point of view.

>> Note, various aspects of the FreeBSD sound code can be tweaked by sysctls,
>> e.g. latency, virtual channels, direct physical access ("bitperfect"),
>> automatic resampling, equilizer, ... (see "sysctl hw.snd dev.pcm dev.hdaa
>> dev.hdac" and "man sound snd_hda snd_uaudio" and the SOUND_4.TXT of Ariff
>> 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  
want to 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  
written documentation of it?

> A dev comes along and copies some code from an older application and brings
> 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  
this were true. Normally an application is written for Linux, and then  
someone tries to make it work on FreeBSD. It then all depends upon the  
skills of the person trying to make it work on FreeBSD, and on the  
internal architecture of the program in question. No matter what kind  
of implementation of whatever API we use in FreeBSD, it doesn't matter  
as long as nobody targets FreeBSD in an audio application as (one of)  
the primary 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  
sound code) 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 access
> to the sound hardware,


And we do that (several applications can access in parallel by default  
= 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=1, 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, 4Front
> 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.  
This is a part of the FreeBSD guarantee that old applications still  
work on newer releases (ABI compatibility). The FreeBSD community  
considers this as a benefit.

For this specific case, what is the bug you see here? For a legacy  
application it looks like it has exclusive access to the mixer, while  
it hasn't. For the application itself there is no bug here (it only  
controls the mixer part of its own sound stream), and the user has the  
benefit of having multiple applications accessing the sound system.

> If you update to the latest version of 4Front oss, this is handled, no need
> to main the code behind this stuff.

I fail to see the bug in FreeBSD here. So I see no benefit in  
replacing this with 4Front oss. What did I miss?

> -----
>
> -----
>
>         dev.pcm.X.[play|rec].vchanmode (default=depends...)
>             'fixed' or '0':
>                 The good old mode. Channel mixing is done using fixed
>                 format/rate. Digital passthrough or other advanced operations
>                 will not work in this mode (consider it as a 'legacy' mode).
>                 For hardware channels that doesn't support digital  
> formats, this
>                 is the default mode.
>
>             'passthrough' or '1':
>                 Channel mixing is done using fixed format/rate, but advanced
>                 operations such as digital passthrough or 'Exclusive Access'
>                 (#6 down below) will start working. All channels should
>                 produce sound as usual until there is a request for a digital
>                 format playback, which in this case will 'mute'  
> other 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, but is
>                 a bit smarter, especially for multiple pcm channels with
>                 different format/rate. Whenever a new channel is  
> about to start,
>                 it will scan the entire list of virtual channels and
> decide which
>                 format/rate is the best (mostly, the higher/bigger).  
> This 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 annoying
>                 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  
magic at all. Only when you enable it on purpose you will get extended  
possibility. At least in 2009 when this document was last updated,  
4Front did not provide those extended features. I don't know the state  
of this in current 4Front code. Feel free to explain if and how they  
handle it today (if they catched up to what FreeBSD is able to do, and  
how the handle it in the API).

> -----
>
> -----
>
> 5) Bitperfect
>
>     OSSv4 Compatibility:
>         SNDCTL_DSP_COOKEDMODE is mostly compatible, except that it  
> will handle
>         complex situation with vchans enabled 'better' compared to  
> 4front OSS.
>
> Again "better" compared to 4front oss, how so?

That's off course a good question. My guess is, that this refers to  
the extended features which are possible (see "adaptive" above). So  
still, currently I fail to see what is less good in FreeBSD than in  
4Front code.

> -----
>
> -----
>
> 6) Exclusive Access
>
>     OSSv4 Compatibility:
>         This feature is mostly compatible with OSSv4, except that 4front OSS
>         prevents all other applications from running (stalled/halted, other
>         unknown grave effects) if any sound device being accessed in a such
>         way.  FreeBSD does this smartly on top of the Transparent / Adaptive
>         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 amount
> of sound architecture rewrite will help.

You have not included the remark that this is not enabled by default.  
This means that an user has to specially enable it to have exclusive  
access working. The outcome is that in case an application wants to  
have exclusive access (e.g. by accident or programming error or legacy  
code), this is not respected and the user still gets sound output from  
multiple applications.

> 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  
janky audio output. At least not to m knowledge. IF there is, then  
please provide a way to reproduce this behavior.
Additionally those audio systems - to my knowledge - have "multiple  
audio streams at the same time" as a feature, which we don't need in  
FreeBSD because 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.  
Think about it as a way to implement userland audio devices or virtual  
hardware.


> -----
>
> 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  
access the sound system.
When you complain about by telling we shall replace the sound code in  
the kernel by the opensound code is not the API, it is the behavior  
which is invoked when a program uses the API.
Those are two different things.

Maybe this is the cause of misunderstanding here.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.freebsd.org/pipermail/freebsd-multimedia/attachments/20171216/d2ce2640/attachment.sig>