FS metrics without random IO benchmark are near meaningless, sequential read is best case for basically every file system and it's essentially "how fast you can get things from S3" in this case

Yup. IIRC low queue depth random Reads are king for desktop usage

I have feeling it will only hurt PJRC in the end for trusting sparkfun to sell and manage the teensy "brand"

Can't say I blame them though. Paul and Robin are two people. Sparkfun (and Adafruit) are massive by comparison and have big stores that sell the same sort of stuff in much higher volume. The Teensys are popular. Sparkfun does (or at least used to do) board assembly in-house. It seems like a perfect match on paper.

given that they didn't even present actual violation in the blog it is very suspicious

UK has fallen

my prediction is that they might switch once AI craze will simmer down to some more reasonable level

> To me, this deal is about the bill of materials for intelligence. Apple admitted that the cost of training SOTA models is a capex heavy-lift they don't want to own. Seems like they are pivoting to becoming the premium "last mile" delivery network for someone else's intelligence. Am I missing the elephant in the room?

Probably not missing the elephant. They certainly have the money to invest and they do like vertical integration but putting massive investment in bubble that can pop or flatline at any point seems pointless if they can just pay to use current best and in future they can just switch to something cheaper or buy some of the smaller AI companies that survive the purge.

Given how much AI capable their hardware is they might just move most of it locally too

yeah but you can record it in 96kHz, then resample it perfectly to 44.1 (hell, even just 40) in digital domain, then resample it back to 48kHz before sending to DAC

True.

If you have such a source sampled at a frequency high enough above the audio range, then through a combination of digital filtering and resampling you can obtain pretty much any desired output sampling frequency.

the point is that when down sampling from 48 to 44.1 you can for "free" do the filtering since the down sampling is being done digitally with an fft anyway

technically we could use 40kHz and just upsample, the extra frequency over 40kHz is basically leeway to make analog part possible/cheap, but it is not technically needed in the signal

the first CD player didn't had compute power to upsample perfectly but modern devices certainly do.

AFAIU, 40kHz exactly wouldn't really work, if your goal is to represent 0Hz-20kHz: in order to avoid aliasing, you need a low pass filter to remove all frequency content above half your sample rate, and no filter is infinitely hard (and you generally want to give the filter a decent range of frequencies to work with). If you want to start your low pass filter at 20kHz, you want it to end (i.e reach practically -∞dB) at a few kHz above 20kHz. If you used a sample rate of exactly 40kHz, you would need your low pass filter to reach -∞dB at 20kHz, meaning it'd have to start somewhere in the audible region.

Though this is just my understanding. Maybe I'm wrong.

It is and it is done but you might not have control over process.

In PulseAudio you can choose resample method you want to use for the whole mixing daemon but I don't think that's option in windows/macos

> I wonder if this problem could be "solved" by having some kind of "dual mode" DACs that can accept two streams of audio at different sample rates, likely 44.1khz and 48khz, which are converted to analog in parallel and then mixed back together at the analog output.

You'd just resample both at 192kHz and run it into 192kHz DAC. The "headroom" means you don't need to use the very CPU intensive "perfect" resample.