FreeBSD amd64 GENERIC kernel
gurenchan at gmail.com
Sat Dec 16 01:47:00 UTC 2017
On Sat, Dec 16, 2017 at 9:39 AM, blubee blubeeme <gurenchan at gmail.com>
> 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
>>> 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
>> 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
>> - 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
>> - 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
> 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
> 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
> 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.
>> http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
>> http://www.FreeBSD.org netchild at FreeBSD.org : PGP 0x8F31830F9F2772BF
> 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
>> 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
> 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
>> 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
> 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
> 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
> 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.
> 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
> 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,
> 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
> 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/
> What part of this setup looks simple: http://i39.tinypic.
> 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
> Keep It Simple Stupid.
What would be easier, trying to update FreeBSD sound and patching around
4Front oss or maintaining these eight files?
<http://manuals.opensound.com/sources/os_freebsd.h.html> OS specific
definitions for FreeBSD
for routines and variables exported by osscore.c
<http://manuals.opensound.com/sources/os_freebsd.c.html> Operating system
abstraction functions for FreeBSDFiles used to build OSS and the drivers
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
OSS driver module interface for FreeBSD
FreeBSD/devid.h <http://manuals.opensound.com/sources/devid.h.html> Source
functions for PCI drivers under FreeBSD
More information about the freebsd-multimedia