Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

3K, 60fps, 130ms: achieving it with Rust

blog.tonari.no

Post reply on HN
Print view View original

101–110 of 211 posts

Re: 3K, 60fps, 130ms: achieving it with Rust

#101

Post by andrewzah »

SomeoneFromCA wrote: post #68
masklinn wrote: post #59

Earlier quoted context omitted.

> 16-bit sounds really harsh to my ears, and 24-bits is the only widely used standard, better than 16-bit. That really doesn't make any sense. The bit depth provides for a dynamic range , meaning the difference between the loudest and quietest sounds which can be encoded. 16 bits is enough to go from "mosquito in the room" to "jackhammer right in your ear". Congratulation, 24 bits let you go up to "head in the output…

What I said actually does make sense. First of all, if you are digitally lowering loudness of audio (say 4 times), you actually are losing precision, and if you later amplify again - you will never return these bits back. This is what is called headroom. So your typical multiply-by-a-floating-point volume control actually kills dynamic range of the sound. I for example never run my OS volume control and players volum…

> but I tried with many people, and all of them noted the difference.

Unless this was a double-blind study and the audio levels were exactly the same between runs, this is useless data. Even a 0.1dbSPL difference between runs is noticeable (people gravitate to louder sounds as better).

> every time I switch sound cards to 24 bits

This may be related to the sound card. I use an external DAC, not a soundcard, as most soundcards that come with computers are not up to par.

Changing 16 bits to 24 bits should not change the audio in a way that is discernible to the human ear.

Re: 3K, 60fps, 130ms: achieving it with Rust

#102

Post by OJFord »

ninkendo wrote: post #89
lc5G wrote: post #52

for crate in $(ls */Cargo.toml | xargs dirname); do cargo build Why do this instead of cargo --workspace build Is it so you can time the individual crates?

Yeah it looks like they wanted to know how long each crate took to build individually. But as long as we're nitpicking, nobody should just pipe `ls` into `xargs` like this, since it fails if anything has spaces in it. Instead, do: for cargo_toml in */Cargo.toml; do crate="$(dirname "${cargo_toml}")" pushd $crate # ... done Don't be that person who writes a script which won't tolerate spaces in filenames!

Alternatively: Don't be that person who clones the repo at a path with spaces in!

Re: 3K, 60fps, 130ms: achieving it with Rust

#103

Post by swsieber »

This is welcome news.

I have been itching to convert a small headshot videostream (thing under 100x100px) to audio, stream it over mumble and then convert it back to video, just to see what the latency is like. It would obviously be a big undertaking, but not as big as this methinks.

Re: 3K, 60fps, 130ms: achieving it with Rust

#104

Post by ekimekim »

phoboslab wrote: post #90
bob1029 wrote: post #39

Earlier quoted context omitted.

The biggest problem is that of the video codecs which ultimately boils down to using interframe compression. This technique requires that a certain # of video frames be received and buffered before a final image can be produced. This requirement imposes a baseline amount of latency that can never be overcome by any means. It is a hard trade-off in information theory. Something to consider is that there are alternativ…

Interframes are not a problem, as long as they only reference previous frames, not future ones. I was able to get latency down to 50ms, streaming to a browser using MPEG1[1]. The latency is mostly the result of 1 frame (16ms) delay for a screen capture on the sender + 2-3 frames of latency to get through the OS stack to the screen at the receiving end. En- and decoding was about ~5ms. Plus of course the network laten…

Wouldn't you then hit issues where a single dropped packet can cause noticable problems? In an intraframe solution if you lose a (part of a) frame, you just skip the frame and use the next one instead. But if you need that frame in order to render the next one, you either have to lag or display a corrupted image until your next keyframe.

I guess as long as keyframes are common and packet loss is low it'd work well enough.

Re: 3K, 60fps, 130ms: achieving it with Rust

#105

Post by SomeoneFromCA »

andrewzah wrote: post #101
SomeoneFromCA wrote: post #68

Earlier quoted context omitted.

What I said actually does make sense. First of all, if you are digitally lowering loudness of audio (say 4 times), you actually are losing precision, and if you later amplify again - you will never return these bits back. This is what is called headroom. So your typical multiply-by-a-floating-point volume control actually kills dynamic range of the sound. I for example never run my OS volume control and players volum…

> but I tried with many people, and all of them noted the difference. Unless this was a double-blind study and the audio levels were exactly the same between runs, this is useless data. Even a 0.1dbSPL difference between runs is noticeable (people gravitate to louder sounds as better). > every time I switch sound cards to 24 bits This may be related to the sound card. I use an external DAC, not a soundcard, as most s…

I have actually never seen any proof double-blind study is the best way to do the audio comparison. I mean, yeah placebo effect does exist, but knowing what to look for in certain type equipment makes it a lot easier to find the phenomenon. Double-blind study, IMO has to be applied only after extensive amount of non-blind tests, Yes the final verdict has to be produced after the blind test, but people need to know what to look for. In any case, I was referring to long term listening fatigue, which has very little relation to loudness, and I'd argue the louder sounds should make you tired quicker.

> This may be related to the sound card. I use an external DAC, not a soundcard, as most soundcards that come with computers are not up to par.

For simplicity, I did not talk about them separately, BTW, following your logic there is no point in bying DAC, unless there was a double-blind study, comparing these DACs to cheaper sound-cards. Both are 16-bit/48000, are not they?

> Changing 16 bits to 24 bits should not change the audio in a way that is discernible to the human ear.

This a bold statement, which begs a proof itself.

Re: 3K, 60fps, 130ms: achieving it with Rust

#106

Post by SomeoneFromCA »

sneak wrote: post #97
SomeoneFromCA wrote: post #57

Earlier quoted context omitted.

I disagree, I do not own trash equipment. Every time I install Linux, i switch Pulseaudio settings from 16-bit to 24-bit; the difference is immediate, although subtle. Everyone I know who tried to do this, noted that listening fatigue is a lot lower with the new settings.

In my direct experience, everyone who claims this to me, so far, is unable to distinguish 16 bit and 24 bit recordings in an ABX. The audiophile world would do well to adopt the concept of double-blind study.

I am talking about listening fatigue, first of all, which is a long-term effect. Second, I think double-blind test are worthless, if they are done in isolation; first, you need to run non-blind tests, let people play with audio equipment as much as they want, in any combination, completely open; only after that, when people have figured out what to look for, run the double blind test. Forcing unprepared people to go through very subtle test surely won't give useful results.

Re: 3K, 60fps, 130ms: achieving it with Rust

#107

Post by Shared404 »

kingosticks wrote: post #99
jonnypotty wrote: post #27

I wish I read more things like this on hn. "We wanted to know and understand every line of code being run on our hardware, and it should be designed for the exact hardware we wanted"

But that statement seems at odds with a dependency on the enormous WebRTC AudioProcessing C++ module. But then they also say they don't use WebRTC so maybe I misunderstand what's going on.

My understanding is that the quoted statement was explaining why they moved away from WebRTC.

Re: 3K, 60fps, 130ms: achieving it with Rust

#108

Post by masklinn »

SomeoneFromCA wrote: post #68
masklinn wrote: post #59

Earlier quoted context omitted.

> 16-bit sounds really harsh to my ears, and 24-bits is the only widely used standard, better than 16-bit. That really doesn't make any sense. The bit depth provides for a dynamic range , meaning the difference between the loudest and quietest sounds which can be encoded. 16 bits is enough to go from "mosquito in the room" to "jackhammer right in your ear". Congratulation, 24 bits let you go up to "head in the output…

What I said actually does make sense. First of all, if you are digitally lowering loudness of audio (say 4 times), you actually are losing precision, and if you later amplify again - you will never return these bits back. This is what is called headroom. So your typical multiply-by-a-floating-point volume control actually kills dynamic range of the sound. I for example never run my OS volume control and players volum…

So what you're saying "actually does make sense" so long as it's a completely different subject than what one would normally assume in context, without you having mentioned such.

When people talk about 24 bits (and >48kHz) in the context of "audiophilia", it's generally about the data at rest and "HD audio" (aka 24 bit music files and downloads). Not about the bit depth of the processing pipeline for which it's generally acknowledged that yes, >16 bit depth does make sense for the audio processing pipeline (as well as the original recording).

Re: 3K, 60fps, 130ms: achieving it with Rust

#109

Post by izacus »

Filligree wrote: post #96
izacus wrote: post #85

Earlier quoted context omitted.

Well, all the effort is regularly defeated by poor hardware - you can have 40ms latecy in the video call stack, but when people attach Bluetooth headphones which buffer everything for 300ms there's nothing really to be done. (Be gentle on your coworkers and use cabled headphones.)

Okay, but I want to wear wireless headphones. Why can't I have both? Wifi doesn't seem to have this latency problem.

How do you know? :)

The latency doesn't come from bluetooth radio part itself (there ARE low latency BT headphones after all).

It comes from the fact that all audio is encoded (usually into SBC or AAC or AptX), transmitted and then decoded in the headphones. And each of those steps has buffers. And those buffers are configured by the manufacturer.

The bigger the buffer, the more stable the audio connection - there's less stuttering, less dropouts. But every buffer in the chain adds latency.

So why can't you have both? You sure can. You just need to somehow find headphones and a PC that doesn't add latency to bluetooth. Sadly that's not something that's usually documented in technical specs.

Re: 3K, 60fps, 130ms: achieving it with Rust

#110

Post by KallDrexx »

Filligree wrote: post #96
izacus wrote: post #85

Earlier quoted context omitted.

Well, all the effort is regularly defeated by poor hardware - you can have 40ms latecy in the video call stack, but when people attach Bluetooth headphones which buffer everything for 300ms there's nothing really to be done. (Be gentle on your coworkers and use cabled headphones.)

Okay, but I want to wear wireless headphones. Why can't I have both? Wifi doesn't seem to have this latency problem.

I believe RF based wireless headphones (like my Arctis 7 headphones) don't have this latency in them due to not being Bluetooth based.

There is some patented codec I think that does allow low latency bluetooth streaming (forgot the name) but that's not heavily implemented in my experience.

Post reply on HN