FreeBSD amd64 GENERIC kernel

[blubee blubeeme]

On Sat, Dec 16, 2017 at 9:39 AM, blubee blubeeme <gurenchan at gmail.com>
wrote:

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

What would be easier, trying to update FreeBSD sound and patching around
4Front oss or maintaining these eight files?

Source Explanation
FreeBSD/os_freebsd.h
<http://manuals.opensound.com/sources/os_freebsd.h.html> OS specific
definitions for FreeBSD
FreeBSD/bsddefs.h
<http://manuals.opensound.com/sources/bsddefs.h.html> Definitions
for routines and variables exported by osscore.c
FreeBSD/os_freebsd.c
<http://manuals.opensound.com/sources/os_freebsd.c.html> Operating system
abstraction functions for FreeBSDFiles used to build OSS and the drivers
during install
Source Explanation
FreeBSD/bsdvirtual.inc
<http://manuals.opensound.com/sources/bsdvirtual.inc.html> Wrapper
functions for virtual drivers under FreeBSD
FreeBSD/osscore.c <http://manuals.opensound.com/sources/osscore.c.3.html> OSS
core functions that need to be compiled in the target system
FreeBSD/module.inc
<http://manuals.opensound.com/sources/module.inc.6.html> Generic
OSS driver module interface for FreeBSD
FreeBSD/devid.h <http://manuals.opensound.com/sources/devid.h.html> Source
file os_build/FreeBSD/devid.h
FreeBSD/bsdpci.inc
<http://manuals.opensound.com/sources/bsdpci.inc.html> Wrapper
functions for PCI drivers under FreeBSD