FreeBSD amd64 GENERIC kernel
blubee blubeeme
gurenchan at gmail.com
Sat Dec 16 13:49:10 UTC 2017
On Sat, Dec 16, 2017 at 9:33 PM, Alexander Leidinger <
Alexander at leidinger.net> wrote:
> 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
>
These are some blog posts from mid to late 2000; Please read it and
understand what's he's trying to express; Then look at the audio programs
and see how they continue to make the same exact mistakes in 2017 going on
2018.
https://web.archive.org/web/20111001142728/http://4front-tech.com/hannublog/?page_id=34
Where are these audio app developers who should be chiming in? The few
applications that I've ported: audio/amsynth and audio/yoshimi
one has OSS support already, the other one I am developing.
Working on implementing the OSS support I am running into issues
Instead of listening u guys keep repeating FreeBSD audio is Great....
There is misunderstanding.
Where are the devs porting audio programs, writing new ones or bringing
online new devices? Why can't they speak up?
Or will you guys just sit back and watch FreeBSD absorb Linuxism until it's
just a bastardization of Linux?
More information about the freebsd-multimedia
mailing list