FreeBSD amd64 GENERIC kernel

Sat Dec 16 01:39:07 UTC 2017

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?

Why is this so hard for you guys to understand?

>
>
> I'd really appreciate it if you refrained from your continued attempts at
>> ad hominem against me and stick to code and a discussion around ideas and
>> implementations.
>>
>
> I understand HPS as asking you to explain in different words what you want
> to tell, as he is not understanding what you want to tell. To my knowledge
> HPS is not a native english speaker (neither am I). I don't know if you are
> a native english speaker or not.
> As a person working in a multi-language (at least 10, with english being
> the common one) environment I suggest not getting upset about phrases like
> "I don't understand your english", it doesn't necessarily mean a deficit on
> the receiver side of this phrase, but most often just means both ends don't
> share the same language background. Often it helps in such situations to
> switch from implicit ("it") references to explicitly mention an
> item/feature/object/... and to use short phrases.

>
> 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.

>
> 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 leave that stuff there, with FreeBSD providing NO documentation/
tutorials/ example programs of how to write decent sound applications.
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.

>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
>

Hi,

On 12/15/17 15:39, blubee blubeeme wrote:

> I'd appreciate it if you kept the discussion on sound and improve your
> English comprehension.
>

See below.

I gave one example of a Chromium bug where they said they'd accept an OSS
> patch. I did not say janky audio in Chromium have anything to do with why I
> think OSS is a better choice for the default audio system.
>

Can you explain again using technical terms:

1) Why is 4Front's OSSv4 better than the in-base FreeBSD OSSv4?

2) Why do we need native OSSv4 support in Chromium?

3) Why can't we use the library provided by the port at
/usr/ports/audio/alsa-lib to implement audio support in Chromium?

You've made that assumption in this thread numerous times and I've ignored
> it because I wouldn't expect someone to be that dense.
>

Can you expand the word "that" in the sentence above? What are you
referring to? I see no connection :-(

It doesn't make sense because you fail to understand English, that's not my
> fault.
>

If you want to get a message through on this list keep it simple and
stupid, KISS, for a start. I'm sorry my comment about your English was seen
as a personal attack, "ad hominem". That was not my intention.

> I have been porting synth tools to FreeBSD and I'd like to continue to port
> the software, implementing OSS backends for them based on the current
> upstream I am running into errors because of these so called "excellent"
> features which causes a lot of headache.
>

Exactly what are the "errors" you refer to in the paragraph above? Can you
list them up one by one, including a brief explanation about the problem
and the solution the way you see it?

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.
>

Can you give a reference to the claim FreeBSD's OSSv4 is a fork of 4Front's
OSS?

> There's nobody actively working on improving the audio situation on
> FreeBSD.
>

Words like "nobody", "noone", "everyone", "everybody" and so on are
frequently used to create a conflict. Is that what you are trying to do?

> You have a user/developer who wants to do the work and you react
> like it's some personal attack on your person to update the underlying
code.

I'm sorry and I don't understand what you are trying to express in the
paragraph above. Who are you addressing in the paragraph above? Is it me,
HPS, or is it the "FreeBSD developers" in general?

What do you mean by "underlying code"? The underlying code of what? This is
a half of a sentence in my opinion!

these "clever" developers
>

Who are the "clever" developers you refer to? Can you list their names?

Guess what, most of the clever features you talk about are in OSS4 and if
> they are not, they can still be added.
>

OSS4 what? Again, please expand the sentences so that I and others reading
this list understand better what you actually mean. When I'm reading: "most
of the clever features in OSS4" , it can mean multiple things. Either you
refer to OSS4 as 4Front's opensound code, or OSS4 means the OSS4 IOCTL API
for interfacing with audio character devices. What do you mean? Do you mean
the smart features are in 4Front's opensound code or do you mean all the
smart features are in the OSS4 IOCTL API?

I'd really appreciate it if you refrained from your continued attempts at
> ad hominem against me and stick to code and a discussion around ideas and
> implementations.
>

Try to put in a few more words when explaining technical things in this
thread. Try to limit the scope of what you are trying to say. I've tried as
best as I can to point out where our communication stalls. This is not
meant as a personal attack. Again, I'm having a hard time trying to fully
understand what you mean or maybe someone else on this list will understand
you better.

@Hans
Forget that I said anything about Chromium, this is a lot lower level than
any specific application.

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
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,
    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.

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

-----

        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.
-----

-----

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?
-----

-----

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.

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.
audio/virtual_oss doesn't make up for that.
-----

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

What part of this setup looks simple:
http://i39.tinypic.com/adfdwz.png?w=240

And I would really like to ask, all the people replying in this thread how
many actually make music?

The biggest reason to implement the official 4front oss is like hans said
above
Keep It Simple Stupid.