electrograv

So I looked the model up on rtings (who does their own objective measurements — a much more reputable source than some random blog post / sponsored link ad) and their tests show it’s not much different from the LG C9: https://www.rtings.com/monitor/reviews/asus/vg248qe

At best, the Asus VG248QE achieves 5.1ms input lag, with 2.1ms 80% transition response time.

At the same resolution (1440p) but lower refresh rate (120hz vs 144hz) the LG C9 achieves 6.6ms input lag, with 0.2ms 80% transition response time.

The LG input lag time you quoted is when running 4K at 60hz, which is a fantastic input lag for that mode, and as far as I know about as good as any 4K gaming monitor out there. The C9 is actually capable of variable refresh rate though at 4K via HDMI 2.1 as well, but no current video cards or drivers are yet capable of this — but when they are, the expectation is that the LG C9 will be a serious contender vs even many dedicated gaming monitors.

Be very careful when comparing specs between different sources, combining different measurement methods, or comparing input lag numbers when the displays are configured at different refresh rates and screen resolutions.

For the same price, you can buy the latest brand new 55” OLED TV from LG, which has absolutely spectacular picture quality in every respect (including fantastic color calibration capabilities), raw pixel response times better than any “PC gaming monitor”, and even input lag (overall end-to-end latency) rivaling or beating many gaming monitors today[2]. Nothing else even comes close, aside from Sony models (also in this price range) which also use LG’s OLED panels.

So rather than hacking your Samsung or buying an inferior Dell monitor meant for PowerPoint presentations, a far better solution is to just stop buying Samsung TVs. In addition to their deceptive marketing and other issues like intentionally bad (over saturated) color calibration out of box, they are designed to be impossible to correctly calibrate due to always-on tone mapping. They do this because they think it makes their TVs look better, and they’re fighting a losing battle against OLED TVs which Samsung does not have any answer to at the moment[3]. Tone mapping that cannot be turned off is a cheap software trick that compromises the accuracy of the source material in hopes of making their TVs have a higher contrast appearance than their hardware is actually capable of (but it does cause artifacts and other downsides, even in regular streaming content).

[1] If you’re really concerned about privacy, LG’s TVs allow you to decline all the terms of service and still use them as “old fashioned TVs” with just the non-smart inputs like HDMI. I’ve tested this on my new LG C9, and it works great.

[2] Objective measurements of the LG C9 OLED series: https://www.rtings.com/tv/reviews/lg/c9-oled

[3] Samsung (and everyone else) is way behind LG’s OLED tech, until they manage to get micro-LED technology to scale up and reach affordable prices. Micro-LED will be superior even to OLED, but right now it is not a production reality, and exists only as multimillion dollar display tech demo prototypes. One other possible alternate to OLED is dual layer LCD, but I don’t think anyone is seriously pursuing that for consumer TV use due to their power and heat issues.

BTW I highly recommend you do some research into HDR, and color gamut. I don’t think you know just how much you’re missing in terms of HDR, color gamut, contrast ratio, etc, that comes with modern TVs. Color gamut goes way beyond sRGB. Modern HDR TVs are far, far more than just “10 bit color”, and allow an express-able color gamut and color volume far beyond sRGB. A LG C9 achieves sound 99% DCIP3 color gamut and 75% REC2020.

To make a crude example, it’s kind of like 150% sRGB coverage, over a range from perfect black to extremely bright for each pixel individually, with enough precision for smooth gradients across these colors. These TVs can display colors that your sRGB monitor is physically incapable of reproducing, and they can display pixel by pixel contrast radios that allow realistic details and specular highlight brightness levels that cannot be done on regular LCD monitors or TVs. And it all absolutely shows in the picture quality when viewing recent movies/TV that are mastered well.

P.S. Stay away from Samsung if you care about color accuracy as I do. Sony and LG and Panasonic all have excellent color accuracy, and likely will be better than any PC monitor within twice it’s price. But Samsung not only comes out of box with horrible defaults, but actually CANNOT be correctly calibrated due to always-on tone mapping. Among videophiles, it’s well known that Samsung is not the way to go. But please don’t let Samsung’s overly flashy demos turn you off to the amazing technical abilities of modern TVs in general. Just because Samsung made arguably greedy marketing-driven design choices that cheapen and destroy the artistic accuracy of the content does not mean everyone else does too. Only Samsung does this as far as I’m aware, among the top brands.

If you want color accuracy, picture quality perfection, superior color gamut, contrast, HDR, AND low latency (0.1ms response time and overall input lag on par with dedicated gaming monitors), LG OLED is THE way to go.

Color calibration isn’t everything BTW. The contrast ratio modern TVs are capable is pretty much unrivaled by any modern computer monitor until relatively recently, and even now the only ones that come close cost many times the price of an equivalent TV.

But no monitor on the market can hold a candle to the image quality experience of an OLED TV for HDR movies and TV shows. This is not really under any dispute btw among audio video forums: virtually everyone admits that emissive technology like OLED has inherent quality advantages. The main debate centers purely around whether or not OLED burn in is likely to occur for various use cases.

If you haven’t experienced modern HDR content on a flagship TV (particularly OLED), you are missing out on something really special. No current PC monitor can even come close, except those that cost >2x the price of a modern 55” OLED TV.

Compare high end models in similar price ranges (as I have) and you’ll see what I’m talking about. For example: Compare an LG OLED in a dark room to any modern PC monitor, and I would be surprised if you were anything but blown away by the OLED, and appalled by how expensive these gaming monitors are compared to what a similarly priced OLED is capable of (especially now that LG OLEDs are capable of 120hz and variable refresh rate with input lag lower than many gaming monitors).

Of course, the main reason we don’t see everyone using OLED PC monitors are concerns about burn in effects from long term use. But for most people for TV and movie viewing, it’s not a concern. My 3 year old LG B6 OLED is still going strong with no signs of burn in, and has picture quality that still puts the best of the best non-OLED TVs to shame.

And that’s an old Samsung TV. On top of that, Samsung’s current flagships are among the worst TVs right now vs the competing major brands’ flagships (because all the best are now OLED, and Samsung is the only hold-out).

Even the improvement from a Samsung Q90 (which I had for a few weeks) to LG C9 OLED has to be seem to be believed. On some content, the improvement is drastic.

The technological progress of modern OLED TVs vs LED LCD is practically magical, when viewing good HDR content. If you go for an old panel for the sake of privacy, you’re either going to be sorely disappointed or blissfully ignorant of what your missing.

I would much rather buy a modern model and figure out how to disable the radios, if I was this worried about privacy.

This is crucial because modern aerial warfare involves missile armaments effective at these distances, so much of it is a game of who can find and acquire a target lock on their enemy first.

These phenomena are interesting because (1) multiple sensor systems from multiple platforms/locations consistently tracked the object in ways that corroborate each other, and (2) other pilots have actually flown close enough to report visual contact.

That said, I wish we actually had an explicitly singular version everyone agreed upon. Since “they” is usually thought of as plural by default (at least without context), it can be confusingly ambiguous to use when referencing sets of people in both singular and plural.

Perhaps we should recycle old words like “thee” ;) (mostly joking, but it would be kind of cool).

A legitimate logical fallacy of the "slippery slope" variety is when one observes a transition from state S_0 to state S_1 via some step/action X taken, and without evidence or justification (!) assumes/claims that the step/action X will therefore be repeated indefinitely until the system evolves to state S_2, S_3, S_4, ... S_n (where S_n is presumably a state we all consider to be undesirable). The "without evidence or justification" part here is EXTREMELY important. If you actually have evidence or justification of a slippery slope, it is not a fallacy; it becomes a valid argument.

Tip: When you see what looks like a slippery slope fallacy at first glance, it's probably best to give the opposing argument the benefit of the doubt by asking for evidence/justification for the induction (S_0 -> S_1) -> S_N. In most cases, some evidence will be provided to justify. If you disagree with the justification, the debate continues in that direction (which is good, because this is productive).

However: If we open the discussion up to C++, then this is pretty easy to solve without any real syntactic or performance compromise: we can make a class/struct which defines implicit conversions to C strings, and disables any implicit conversions from C strings.

Otherwise (if we want to retain the zero-cost guarantee of converting to a C string), directly accessing the member variable is: functionally equivalent, simpler, more concise, more readable, more explicit.

  legacy_fn(my_text.s);

  legacy_fn(my_text);

In fact, I even find the explicitness more pleasantly and clearly readable: I like being able to know at-a-glance when types are changing, especially in a language as unsafe as C.

Lastly, if you can tolerate just using some of C++‘s features, you can define a no-compromise solution: A type (still represented by a single pointer under-the-hood) that will implicitly convert (with zero runtime cost) into a C string but not vice versa.

Why not just use the member explicitly? This way, converting a STS string into a legacy C string could be as simple as writing “.cstr” (or if you just be as terse as possible, it could be defined as “.s” as another poster suggests).

In this case, compromise of increased code verbosity is extremely minor at worst (just a few characters). At best, this extra explicitness can actually be seen as a good thing for code readability (not to mention the huge benefits we’re discussing of type safety).

So the question then is: Why doesn’t SDS do this? The actual library uses a regular C typedef (which is unsafe for the reasons described above).

And, this works in Rust just as it does in C. But at this point, you lose out on the benefits of Rust's static type system and borrow-checker:

1. The compiler will no longer be able to correctness-check the validity of these 'int' style references to other memory.

2. If something does go wrong and you read the array with a bad integer index, Rust will just 'panic' and crash the application. Unlike C, there will be no risk of memory errors or related security vulnerabilities. But on the other hand, each read being bounds-checked will make such Rust code slightly slower than is possible with C/C++. (Though I think you can use 'unsafe' blocks if you want to hyper-optimize akin to C.)

But regarding GC langauges, I generally agree; they're almost always more trouble than they're worth in any performance-sensitive context. You often end up using approaches like this to optimize around the GC (e.g. int indexes into pre-allocated arrays) which ultimately means you're coding C-style in a GC language anyway, which defeats the whole point of GC's productivity-enhancing benefit -- at that point, why not just go all the way and use C or Zig or Rust etc.?

Rust is more mature, well-known, and akin to C++ in its philosophy (big language with powerful features and abstraction capabilities), while Zig[2] is less well-known but IMO a beautifully designed language akin to C in its emphasis on simplicity, while remaining modern in design (e.g. unlike Google Go, which is very simple but intentionally repeats many of C's mistakes[3]).

[1] Such powerful generics usually come with unavoidable explosions in compile time (and sometimes mental complexity for the coder). This is because while it may look like you're simply calling a library function and passing in a reference to your callback function, what it's really doing most of the time (to achieve good performance) is recompiling the entire library from scratch (or nearly so) with your function inlined. Also, the performance characteristics of any given block of code won’t be as obvious and predictable at-a-glance as it would be in a simpler language.

[2] https://ziglang.org/

[3] https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

For example: Haskell has been trying to bring the performance of C to a functional language for almost 30 years now. While Haskell is a great language with impressive performance for its category, I don’t think anyone believes it renders C/C++ obsolete for scenarios where predictably high performance is crucial.

This is an interesting topic to me, because while I try to find ways to write high-performance code as functionally as possible, I can’t seem to escape the relationship where more procedural-styled code usually yields consistently/predictably higher performance.

Functional (and other paradigms) can sometimes match C’s performance -- but in non-toy scenarios, the “sometimes” clause here compounds its probabilities to ultimately become “virtually never”, as the scope and complexity of a real project grows.

As a result, performance-critical projects written in languages without predictable performance characteristics often evolve into a situation later in development where 90% of your development time is spent poking at 'black boxes' (the compiler optimizer and garbage collector), hoping (sometimes futilely) that you can prod it into spitting out the procedural machine code patterns you already knew you needed anyway — if you’re lucky. And what makes this even worse is that this situation usually arises late enough into development that it's very costly (if not impossible) to backtrack and rewrite everything in a procedural language.

Of course, writing procedurally ends up trading off readability and robustness too human error, vs better performance. I too wish there was a better way to achieve both — I just haven’t found it yet.

“When we changed the key travel from 1.0mm to 0.5mm, it was so much better that it became the best keyboard in the world. And now, with the change from 0.5mm to 1.0mm, we’ve made it even better than ever: Welcome to the world’s best typing experience.”

In such a case, how is “too introverted” as a reason for rejection or even as a negative cultural connotation not overt discrimination to exclude neurodiversity?

I’d even be willing to concede that such personality-based discrimination may need to be made for customer-facing roles or roles if being charming or extroverted is explicitly part of the job description. But other than that, it seems odd to reject an engineering candidate for reasons like this.

I think it’s cool that Tesla is finding new ways of getting value out of their cars, but to answer your question: Many people would prefer a proper theater or music experience. Also, while Tesla’s sound quality is among the best out there for cars, no car audio can hold a candle to the music (or theater) sound quality you can get from large high-quality speakers (far too large to fit in any car) in a well-damped room (with acoustic treatments if necessary, e.g. if you have hard floors or too many windows).

You could install the best speakers in the world in a car, but it would still sound worse than in an average house due to all the acoustically reflective surfaces at many angles (e.g. glass) and oddly shaped compartment which distorts the sound in ways that cannot be perfectly corrected even with DSP.

Therefore, the implementation you’re suggesting is actually not all that different from my current solution, except for a few important details related to the particular problem I’m solving — e.g. handling many parallel streams which may momentarily drift out of sync (where those that are not delayed must still be processed without the state of other streams interfering to add latency), among other important details.

Ultimately though, aside from this discussion on high performance designs (which though fun, would not work without you actually knowing the requirements of what I’m working on — e.g. it’s not HFT), I’m just glad we’re in agreement that there are applications where avoiding dynamic allocations is absolutely essential, and that it would be a huge mistake to add them to a high-performance language’s most fundamental integer types.

Performance improved by 100x - 1000x. And it was already blazingly fast before, if measured against performance standards we’ve become accustomed to from JavaScript and other GC languages.

In high performance systems (where the benefits of C/C++/etc. outweigh the downsides), dynamic allocations always come back to bite you.

If you rely on them too heavily from the start (and don’t plan for custom allocation schemes in the future), you can even get into bad situations where it’s infeasible to refactor to custom memory management (without a total rewrite), when you later need the performance gain.

Incorporating even the possibility of heap allocations into a language’s most fundamental data types will doom that language to being relegated to performance-insensitive and latency-insensitive tasks, if only because it requires that a heap exist (whereas C, Rust, etc can run on embedded real-time systems with no heap).

And that’s okay! It’s good that we have languages for that. But C/C++/Rust/etc. are definitely not where you can tolerate such a thing in the core language.

I was simply responding to the parent post’s false claim (”The human brain doesn’t use a billion dollars in compute power, figure out what it is doing.”), in isolation from the rest of the post (which I generally agree with).

This may not be true, if we’re talking about computers reaching general intelligence parity with the human brain.

Latest estimates place the computational capacity of the human brain at somewhere between 10^15 to 10^28 FLOPS[1]. The worlds fastest supercomputer[2] reaches a peak of 2 * 10^17 FLOPS, and it cost $325 million[3].

To realistically reach 10^28 FLOPS today is simply not possible at all: If we projected linearly from above, the dollar cost would be $16 quintillion (1.625 * 10^19 dollars).

So, when it comes to trying to replicate human intelligence in today’s machines, we can only hope the 10^15 FLOPS estimates are more accurate than the 10^28 FLOPS ones — but until we do replicate human level general intelligence, it’s very difficult to prove which projection will be correct (an error bar spanning 13 orders of magnitude is not a very precise estimate).

P.S. Of course, if Moore’s law continues for a few more decades, even 10^28 FLOPS will be commonplace and cheap. Personally, I am very excited for such a future, because then achieving AGI will not be contingent on having millions or billions of dollars. Rather, it will depend on a few creative/innovative leaps in algorithm design — which could come from anyone, anywhere.

[1] https://aiimpacts.org/brain-performance-in-flops/

[2] https://en.m.wikipedia.org/wiki/TOP500#TOP_500

[3] https://en.m.wikipedia.org/wiki/Summit_(supercomputer)

Of course “fast” is relative, but I would reserve it for languages that are nearly as fast as competitors in their segment. There are too many languages very similar to Go’s ergonomics that are much faster for us to meaningfully call Go “fast”.

That said, I don’t really think that’s a problem. I think people who use Go are often just happy it’s faster than Python, and that’s okay.

My personal dislike of Go comes simply from their unapologetic[1] embrace of default nullable pointers (the “billion dollar mistake”[2]): There is very strong theoretical (and practical) ground supporting the approach of Rust/Zig/Swift/etc’s (to use algebraic data types instead) as objectively better (yielding inherently more reliable results with virtually no ergonomic compromise[3]).

In other words, in the 21st century, we know how to design statically typed languages that guarantee the impossibility of null dereference exceptions (not counting bugs in external libraries from other languages). And we can do this without any runtime performance or code ergonomics compromise!

Therefore there are no good excuses anymore for any statically typed language in the 21st century to not provide this extremely beneficial guarantee.

[1] There are no plans to fix this, ever: I’ve seen entire articles written by members of the Go team not just defending “all pointers are nillable”, but encouraging this as an idiomatic Go style of coding.

[2] https://www.infoq.com/presentations/Null-References-The-Bill...

[3] The ergonomic difficulties of Rust come from the borrow checker, not from their use of algebraic data types to replace nullable pointers.

I think there's a lot of subtlety being missed between dynamic range and resolution. For example, I think your JND (just noticeable difference) assumption is incorrect; my understanding of the scientific consensus is that a 1db difference at any volume is consciously perceivable to "normal" human hearing (and 3db to virtually all humans), and a 0.2db difference has been shown to be subconsciously perceivable by most. This places the required bit depth (not counting dithering) of an audio recording spanning all human perception WELL beyond 96db, and probably somewhere in excess of 120-140db! This is consensus, BTW; hence most CD-apologists people defer to the dithering argument :)

Also, I did finish reading that article up to the point about bit depth, and unfortunately there's quite a bit of either bad and misleading data in there unfortunately. While the article does contain some very good true info, it's sadly riddled with enough bad/outdated claims that I can't really recommend it to anyone as a reputable/trustworthy source of truth. It strikes me very much as if the author is unaware of how imprecise our approximate understanding of psycho-accoustics actually is, when it makes extremely overconfident claims like "CD quality will be enough FOREVER".

For example, the point made about near infrared being invisible to all humans is obviously false: most humans can't, but a certain percentage of blue-eyed humans can see near infra-red (including remote control IR). I've known one such person personally, and have tested and confirmed this thoroughly. I agree that it's silly to try to make a TV that emits these frequencies (and cameras that capture them), but my point here is simply: there's a lot of bad info in that article, perhaps shamefully so for an article making such bold and confident assertions under the name of "science".

Regarding bit depth, the article doesn't really even try to dispute the fact that 96db is insufficient; it just says with dithering, we shouldn't have to worry about it. I'd love to agree, but the combination of the meta-analysis that shows it's not sufficient is all I need to prove that your linked article is simply wrong.

There many be a wide range of reasons why the meta-analysis found high res audio to sound slightly better, but none of that invalidates the validity of the results themselves.

For example, maybe most DACs aren't very good at replicating dithered subtleties (I'm just speculating examples here) -- supposing such a common problem exists, then we could debate whether it makes more sense to improve DACs with fancy improvements to dither reconstruction filtering -- OR -- we could just encode at least 140db of dynamic range in the sample bit depth in the first place! The latter seems a far simpler and less-overengineered solution to me.

Dithering is fine when it works, but let's be honest: fundamentally, dithering is a kind of compression algorithm that encodes a greater dynamic range within a signal with an artificially constrained dynamic range (but with the side-effect that not all DACs will handle it equally well). In the modern digital world, there's no need to rely on dithering any more in audio signals, in the same way that we don't see dithered 256-color images much any more. Why don't we leave compression up to the compression algorithms, rather than promoting ACDs/DACs that are glorified compression/decompression hardware? Modern lossless compression algorithms are vastly better anyway, if bitrate savings is the goal.

A pin drop contains a continuous and gradual decay of the ringing over time, which most certainly is audible (at least subjectively) in more gradations than just 8 levels before reaching 0.

But this isn’t just subjective: Studies have confirmed that humans can hear decibel differences of 1db quite reliably, and can even hear as little as 0.2db subconsciously (this can be objectively measured)!

So long as you can hear a pin drop ringing at 1db, and also at 10db, it’s therefore obviously true that 3 bits per sample (undithered) is insufficient to express this (keep in mind, these samples are linear amplitudes!)

So I’m not sure how you can possibly claim that 3bits is enough to replicate the continuous amplitude decay of a pin drop’s ringing sound. What am I missing?

That’s said, I will now go read your link. I agree dithering is one viable way to expand the dynamic range, but you also seem to be claiming this 3bit pin drop is true without dithering.

First: Bits per sample just describe how many discrete amplitude values (2^bits) are possible at each sample of a recording. The waveform is quantized to these values.

To understand quantization in the context of dynamic range, imagine how many bits per sample are needed to recreate a very quiet sound without loss, and then check how many bits you need to extend that to reach very loud sounds in the same recording file.

For example: How much precision would you need to accurately record the sound of a pin dropping (10db)? 4 bits? 8 bits? 10 bits? 12 bits?

Let’s be really absurd and say we can use 4 bits — just 16 discrete values — to represent a pin dropping sound (10db) cleanly and indistinguishable from the real thing. This is so obviously impossible, given how terribly quantized the waveform would be, but let’s be generous and assume it works.

Now, for the same audio file to reach all the way up to 110db (not uncommon for bass drum hits in an orchestra for example) is an extra 100db of dynamic range, which is 100,000x the amplitude, which is a little over 16 bits in addition to the original 4. So, rounding down, we’d need 20 bits to represent 10db sounds (with quantization down to only 16 discrete amplitudes) and 110db sounds in the same recording.

I think it’s extremely obvious that even 20 bits in this example is far from sufficient. In fact, even 24 bits would be insufficient if 8 bits per sample are not good enough to record a pin dropping at 10db!

https://qmro.qmul.ac.uk/xmlui/bitstream/handle/123456789/134...

Additionally, this is purely talking about loudness dynamic range, not even including resolution or JND (just noticeable difference). I will demonstrate to you below how even 20 bits per sample is insufficient in some cases.

Imagine for a moment that you could argue that the human hearing threshold of quantization error is only 4 bits (only 16 discrete values!) at the sound level of a pin dropping (10db). Now, I think we can all agree that’s absurd; we need a lot more than just 16 discrete amplitude values to represent the sound of a pin drop indistinguishable from reality to a human ear. But for the moment, let’s be really really generous to your point and assume it’s enough!

Now, let’s suppose we want to extend the recording so sounds at 110db appear later on (say, an intense bass explosion in an action movie after a quiet scene early on). To do this without clipping, what range of discrete values do we need? 110db-10db = 100db = 100,000x greater amplitude than the pin drop. This means we need to be able to represent peak amplitude values of 1,600,000.

This exceeds the ability of 16 bits to losslessly represent the quiet 10db pin drop and 110db explosions within the same movie’s audio track! You would need at least 21 bits in this example. And I’ve been generous with my assumptions here, making the extreme assumption that even 4bits per sample is enough to record a 10db pin drop, which is clearly not enough.

If you think 110db is unrealistic for brief periods, it’s not, even for music: bass frequencies in particular can reach extreme amplitudes that might surprise you. I recently played an extremely well recorded orchestral piece at reference volume on my equipment and was so impressed by the dynamic range, I later measured the decibel levels (C-weighted). The quietest moments are around 65-70db, increases to 80-90db at times, and peaks several times momentarily to 105db when the bass drum hits (you feel it like a punch of an air wave)! It turns out this is exactly how real bass drums measure. Yet, the drum hit doesn’t sound unbearable loud (as treble would be at that decibel level), so much as tactile, because much of that energy is subsonic.

If you do much research into perceptual psychology studies, you’ll see just how surprisingly difficult it can be to completely pin down the limits of human perception on average, let alone including outliers among the human population. In that sense, it’s entirely reasonable that a durable high fidelity recording format that holds up to time should be over-engineered, so there’s at least no worry that some study will prove it’s missing something later.

That said, I don’t really agree with the parent post that most DACs are horrible, but I can’t comment on CD player DACs since I don’t use physical media. Most phone DACs are quite good. Most PC DACs are horrible not because of the DAC but because buzzing noises from system clocks and other sources always appear on my speakers (it’s very loud and noticeable), so I’m forced to use a cheap $20 external DAC, which quite frankly is nearly as good as anything else you’ll get at any price.

https://www.audiosciencereview.com/forum/index.php?threads/m...

Now as far as speakers are concerned, yes, you’ll need to spend at least a few thousand for a stereo pair capable of doing justice to this level of precision and dynamic range.