xipix
xipix on Hacker News
The article seems to evaluate Wasm as it were a framework upon which apps are built. It's not that, it's an orthogonal technology allowing CPU optimisations and reuse of native code in the browser. Against that expectation, it has been a huge success despite not yet reaching bare-metal levels of performance and energy efficiency.
One such example: audio time stretch in the browser based upon a C++ library [1]. There is no way that if this were implemented in JS that it could deliver (a) similar performance or (b) source code portability to native apps.
[1] https://bungee.parabolaresearch.com/change-audio-speed-pitch
Driving is prohibited until a certain age. Parents don't get to discuss this with their child and decide when they're old enough.
"Can I learn to drive?"
"No, you're not old enough"
"But my friend is already driving and he's 12"
"OK, when you turn 12 you can too."
We absolutely do need regulation of this harm by the law. It's how we stand together as a society, otherwise one child's rules will seem draconian against their friend's lax parents. There's plenty of precedent in other threshold ages at which children can start indulging in other potentially harmful vices.
The vulnerable elder population is more difficult to define by a simple age threshold. We all decline at different ages and different rates.
You can't use spaces to align because you can't assume a monospaced font will always be used. You can't use tabs either for that matter. If you need structure, use the language's punctuation and line breaks.
That's no excuse for YouTube because (a) audio processing can be done in JS/WASM and (b) they have the influence to improve browser playbackRate implementations to something better [1].
Besides, their Android and iOS apps do slow music as bad if not worse than on web.
[1] https://bungee.parabolaresearch.com/compare-audio-stretch-te...
If you're learning guitar, drums, piano, trumpet, etc, you'll want to start playing along at about 75% speed then work up until you can play 110% faster than you need to. YouTube's built in audio time stretch makes this a painful exercise.
Nice analysis, for 1x playback speed. If you're playing back at a different speed, for example, for music practice, YouTube audio is awful.
Why doesn't this huge AV platform use a better audio time stretch algorithm?
> Fun fact: Unlicensed stations began streaming jungle music from onboard ships off the coast of Britain, hence the expression "pirate radios."
Didn't pirate radio broadcast from boats predate Jungle by about 20 years?
Two thoughts.
Suppose I deem it safe and useful for my 6yo to drive for a while, using his Xbox controller from the passenger seat.
It is illegal in many countries for a device (or anything else) to obscure any part of the driver's forward view (area swept by wipers). So even without actually controlling the car, we have an unlawful vehicle.
Has that been tested in court? In my jurisdiction?
I'd be even more gleeful if I was in car insurance. "Openpilot's not covered, your insurance is invalidated."
Neat, love it.
Now try synchronising the music to the game.
You could use our Bungee library for the audio processing.
Bungee is our audio stretching library. It can change music tempo and pitch effortlessly in real time on all common devices and browsers.
Bungee is unique in its quality, performance and controllability. Every media player, DAW, video editor should use something like Bungee for smooth scrubbing and audio slomo.
Try it with one click: https://bungee.parabolaresearch.com/bungee-web-demo
So far we have several licensees of the Pro edition with more on the way.
The biggest challenge here isn't the tech/standards problem.
It's what this signals for the future of the planet's climate.
The correct solution to this optimization problem is to write the integers raw, not as ASCII.
Absolutely you can. With WebAsm SIMD you have near-native DSP performance. Downsides from my experience [1]:
- You are at the mercy of the browser. If browser engineers mess up the audio thread or garbage collection, even the most resilient web audio app breaks. It happens.
- Security mitigations prevent or restrict use of some useful APIs. For example, SharedArrayBuffer and high resolution clocks.
[1] https://bungee.parabolaresearch.com/bungee-web-demo
Intel, AMD and others also have chips for training that perform close to or sometimes better than Nvidia's. These are already in the market. Two problems: the CUDA moat, and, "noone gets fired for buying green".
Getting negative vibes from the name. Cadmium's a nasty substance. I mean, you wouldn't call an augmented reality app ARsenic, would you? Constructive, I hope, criticism.
A proportional font really helps ergonomics too.
#1 will lead to #2
#2 will solve #3
How is local more private? Whether AI runs on my phone or in a data center I still have to trust third parties to respect my data. That leaves only latency and connectivity as possible reasons to wish for endpoint AI.
Mathematically it's aliasing. And it's fixed by antialiasing. I'll bet everything on the screen you're looking at right now is antialiased. Would be nice if audio waveform visualisations were too.
Agreed, there is aliasing of the audio. But also aliasing in the way that the waveform is rendered.
Consider: would you draw a line, or a circle using only a foreground and a background pixel colour?
The min/max solution doesn't prevent aliasing.
Consider that if you do manage to avoid aliasing, you'll be rendering something visually akin to a downscaled version of a fully-detailed, high-resolution plot of the waveform.
My point is that everyone seems to draw waveforms using only two colours. Inevitably, this results in aliasing.
In the extreme we have the "Spotify" visualisations of vertical bars with gaps in between. I believe this is popular because it looks slightly better than a solid waveform lump with an aliased edge.
To avoid aliasing you need to use more than two pixel colours.
Thanks. I picked a fixed number of horizontal pixels per second for an internally cached image. I think it was 30 pixels/second so that scrolling at 1x playback rate would be smooth on 60/90/120Hz screens. So it can't zoom into the waveform like yours, but I don't need it to zoom.
There are two parts: first the C++/wasm that analyses the audio and generates a bitmap that has width 30*duration and not very high. It effectively draws a line from each audio sample to the next, with alpha, but this can be optimised like crazy to a point where the time it takes is unnoticeable.
The second part is the WebGL that the bitmap (aka texture) and renders to the canvas. In principle this could be rotated, spun in 3d, mapped to a sphere or any other crazy GPU manipulations. WebGL isn't too painful and works everywhere I tried including the Android webview in my Bungee Timewarp app.