From owner-freebsd-multimedia@freebsd.org Sat Dec 16 01:39:07 2017 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31881E93577 for ; Sat, 16 Dec 2017 01:39:07 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAD3A6F462 for ; Sat, 16 Dec 2017 01:39:06 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x234.google.com with SMTP id o130so202482itg.0 for ; Fri, 15 Dec 2017 17:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oMRFJ8Zk6Hb4z8GiJL1+eJJzdOq63K6ST6BysM13mVM=; b=MICg5Ch8FSSCVEjsNht3/tgufIQokoz4h488883FPWBcsgqJmQUZ/5LzGDQAaQK2CP ZXl5BXRpjzzxJJStNIUEXIJiRiVBw0TavIf5izBI2EDmig4K1fTiMuHMGHSe3I95Lkqr HbRjaz4FeW03KHEhH49qciphR4tYXlOmplyo8kPrsUBDPMTxUkcABEbNmR8+H0fxVa4N PQ+onDgWrVRgtW5i6Juj1qyD5F985GKPc2y8hj3+9rneX98rnxuQbwR9kMDL8tFA0+Kv HUlGA88Yf5MKO4tOSDj4YB9aqqnZfFfaqG6yO32cJipR3PcRWIdPEQe28APJbwArXt6Z 69Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oMRFJ8Zk6Hb4z8GiJL1+eJJzdOq63K6ST6BysM13mVM=; b=MsM1mvKDtb+vHGp8D0D6xLxXvm59wrjUWq2cbhRNkodyoHTzGEHjbGGYm+3Xf1LyPy FaO2bZh9JDn7KmuEE0xc5ic7bdU3rnssXvxxtMX/HrMU+WHiQk1qjCuckEmcTw5ugy57 qpWpBpUhXMxtQbZwO+eCIV0C8RRSFo+LLg52xA4RUZKfIp1y9uC2bximcccwtw/ROM0i 3o7cKqbM/tciOF99dnMKx+DBYWy8MjUS49hCX6zLYIICMOCCAYJ9QdowHbVy+nfrvjh8 oiaBhrcD6limeYXjSNIFCrvLCftPCvSuPvyzgPixJujjmMp/ciANwjdYMeW87unM0lDk 0vxw== X-Gm-Message-State: AKGB3mIuQvWse9KAMnR63uBvEvz6lklPHxcQ+Yw9xpSxZVPZW6PUJFvj ljgUwVeRl6ZbY9cdFHCkUyBh511t4KmM0XY/m225aTRP X-Google-Smtp-Source: ACJfBotOBWfHt9lB23KaxrAPYtDZwmQRfphhuu4nOfydJI/UaD+goCpku/UnL/ER3FwFifpOtsya/Mt9j7PjN5nC/pI= X-Received: by 10.36.221.147 with SMTP id t141mr10766015itf.140.1513388345836; Fri, 15 Dec 2017 17:39:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.134.9 with HTTP; Fri, 15 Dec 2017 17:39:04 -0800 (PST) In-Reply-To: <20171216011614.Horde.Uitm74qhBEwh_NRo9RgDgu3@webmail.leidinger.net> References: <4c3ae20e-b6dd-d5db-0b93-2e1225daa658@selasky.org> <4eb0c57e-96fa-b75a-17f8-750154aa247a@selasky.org> <20171216011614.Horde.Uitm74qhBEwh_NRo9RgDgu3@webmail.leidinger.net> From: blubee blubeeme Date: Sat, 16 Dec 2017 09:39:04 +0800 Message-ID: Subject: Re: FreeBSD amd64 GENERIC kernel To: Alexander Leidinger Cc: Hans Petter Selasky , freebsd-multimedia@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 01:39:07 -0000 On Sat, Dec 16, 2017 at 8:16 AM, Alexander Leidinger < Alexander@leidinger.net> wrote: > Quoting blubee blubeeme (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@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@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.