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

Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

wescottdesign.com

Post reply on HN
Print view View original

21–30 of 79 posts

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#21

Post by bigbillheck »

anonymous-panda wrote: post #12
rcxdude wrote: post #8

Earlier quoted context omitted.

I'm not sure what you mean here, but I would say that sampling profilers are a good example of Nyquist applied correctly for the most part: your signal (the distribution of where your software is spending its time) is likely to have an extremely low bandwidth (as in, it's basically static), so why try to sample super rapidly? It's much more of a question of whether you get enough samples to represent that distributio…

You’re talking about profiling a normal running program. If you’re profiling a benchmark that’s always executing the hot path, where exactly the hot path contribution lies becomes less clear. This is because you run into aliasing with the samples being collected at unhelpful points. Maybe if you run long enough you start to see a picture but at 1khz you’re going to have to run for a very long time. The other way alia…

> a simple bounds check may not show up even if it’s responsible for a 20% slowdown because the probability of your sampler hitting it is small when that bounds check takes nanoseconds to execute vs your ms profiler sample rate.

Surely for this to happen you'd have to be putting a lot of effort into getting a perfect 1ms sampling rate, and even a little bit of variation in that would be more than enough to handle aliasing issues.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#22

Post by shin_lao »

nofu7ur3 wrote: post #15

> ...there is no point to distributing music in 24-bit/192kHz format. Its playback fidelity is slightly inferior to 16/44.1 or 16/48.... from "24/192 Music Downloads ...and why they make no sense" (2012) [1] [1] https://people.xiph.org/~xiphmont/demo/neil-young.html

High sample rate isn't useful for playback, but 24-bit is great for nuance in low intensity sound.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#23

Post by [deleted] »

f5ve wrote: post #3

If you're thinking "The highest rate I need my signal to be able to replicate is X, so I should set my sampling rate to 2X," then you're wrong and this article gives several reasons why. As far as I can tell, though, it doesn't mention what may be the most important reason (especially to the folks here at hackernews): resampling and processing. This is why professional grade audio processing operates at a sample rate…

[deleted]

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#24

Post by hamstergene »

hunter2_ wrote: post #16
shampto3 wrote: post #9

Earlier quoted context omitted.

You’re right, but I fear this idea has become prevalent in audiophile communities where they only want to listen to files that are 96kHz or higher. In my opinion, having a high sample rate only really matters during the production phase and does not have a noticeable effect on the final form factor. If the producer uses high sample rate during the creation process, I see no reason why the listener would care if the f…

The same could be said about bit depth: 24 bits offers far less quantization artifacts than 16 bits, and those artifacts can readily show up during production processes such as dynamic range compression, but they are extremely well hidden by dithering with noise shaping which gets applied during mastering so ultimately listeners are fine either way. However, any type of subsequent processing in the digital domain, ev…

I detect some fallacy here.

The real benefit is not using 6x network bandwidth, storage, memory, processing power and more battery of the mobile device. That benefit is not going anywhere, no matter what.

Post-processing is applied to the signal which is physically impossible to distinguish from the source. It is true that it often needs higher resolution, and DSPs will upsample internally and then back and operate on floats. But to claim without evidence, that post-processing may give human listener back the ability to tell apart whether 192/24 medium was used instead of 48/16, would be to reintroduce the same quality-loss paranoia, just with an extra step. If one couldn't hear the difference before an effect was applied...they won't hear it after.

As for DJs, they do use high-res assets when producing mixes. That's still mastering stage, technically.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#25

Post by flyinghamster »

f5ve wrote: post #3

If you're thinking "The highest rate I need my signal to be able to replicate is X, so I should set my sampling rate to 2X," then you're wrong and this article gives several reasons why. As far as I can tell, though, it doesn't mention what may be the most important reason (especially to the folks here at hackernews): resampling and processing. This is why professional grade audio processing operates at a sample rate…

Also, when the sampling rates get extreme (software-defined radio), it is well worth moving to complex samples. Doing so allows you to use a sampling rate equal to your theoretical maximum bandwidth, instead of 2x. That's not such a big deal at audio bandwidth, but when your Airspy is slinging a 6 MHz chunk of spectrum, it becomes a huge deal.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#26

Post by greesil »

I ran into this problem with a codec chip. We had to run the output at 48 khz, and the input and output clock had to be the same. Well we didn't have enough CPU to process the input at 48 khz, we only cared about 8 khz bandwidth for human speech. Boxcar averaging then decimating produced way too much aliasing, so much that the ML classifiers wouldn't work. The solution was putting a honking large FIR anti aliasing filter on the codec, like 100 taps, because -that- chip had oodles of CPU to spare as it turned out.

Why FIR? It had a super sharp cutoff and of course linear phase. If I'd known about Bessel filters at the time I'd have tried those out. Live and learn and ship it.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#27

Post by gct »

rcxdude wrote: post #8
anonymous-panda wrote: post #5

It’s interesting to me how frequently people will talk about sampling performance profilers and not know about Nyquist. Given a CPU runs at many GHz but SW sampling profilers run at ~1 or even maximum 10khz, it’s really hard to write software if you’re targeting processing at MHz rates.

I'm not sure what you mean here, but I would say that sampling profilers are a good example of Nyquist applied correctly for the most part: your signal (the distribution of where your software is spending its time) is likely to have an extremely low bandwidth (as in, it's basically static), so why try to sample super rapidly? It's much more of a question of whether you get enough samples to represent that distributio…

Fun fact static is very broadband

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#28

Post by iamcreasy »

So, we first need to find the highest motion frequency a sensor might experience in the experiment, and then make sure the sampling rate it at least twice that to avoid aliasing?

Meaning, if an IMU sensor is mounted on a very slow moving, such as 2cm/s, RC vehicle then the sampling rate can be very slow. But if the sensor is on a fast moving drone, we need to estimate the highest frequency of the motion and make sure our sampling rate is at least double that?

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#29

Post by anonymous-panda »

bigbillheck wrote: post #21
anonymous-panda wrote: post #12

Earlier quoted context omitted.

You’re talking about profiling a normal running program. If you’re profiling a benchmark that’s always executing the hot path, where exactly the hot path contribution lies becomes less clear. This is because you run into aliasing with the samples being collected at unhelpful points. Maybe if you run long enough you start to see a picture but at 1khz you’re going to have to run for a very long time. The other way alia…

> a simple bounds check may not show up even if it’s responsible for a 20% slowdown because the probability of your sampler hitting it is small when that bounds check takes nanoseconds to execute vs your ms profiler sample rate. Surely for this to happen you'd have to be putting a lot of effort into getting a perfect 1ms sampling rate, and even a little bit of variation in that would be more than enough to handle ali…

It’s been a few years but if I recall correctly the fact that there’s variation in the sampling itself makes the aliasing worse not better. At the very least should be no different.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#30

Post by KeplerBoy »

iamcreasy wrote: post #28

So, we first need to find the highest motion frequency a sensor might experience in the experiment, and then make sure the sampling rate it at least twice that to avoid aliasing? Meaning, if an IMU sensor is mounted on a very slow moving, such as 2cm/s, RC vehicle then the sampling rate can be very slow. But if the sensor is on a fast moving drone, we need to estimate the highest frequency of the motion and make sure…

Yes, pretty much, but it depends. Your 2 cm/s RC vehicle might still experience high-frequency vibrations (in the range of the motor rpm) and you might want to sample that.
Post reply on HN