Hacker Newsnew | past | comments | ask | show | jobs | submit | dgrcode's commentslogin

It's a shame that modern browsers don't optimize SVG to be processed in the GPU. It has plenty of potential, not only feTurbulence, but many other effects as well. And being able to use SVG masks on standard HTML elements would also open a bunch of creative opportunities.

Unfortunately, as you say, it's very easy to freeze a GPU if you start doing more complex SVGs.


My wife recently got her O1 visa approved and I'll be getting an O3 as dependent. I currently have an app that I'm actively developing that generates $50-$100 per month. I might be able to stop development, but at the very least would need to support the customers. I also have some product ideas I'd like to build and potentially monetize.

What are my options?


Probably the O-1 for you as well but also look at the E-2 investor visa.


> Gumroad is infamous for underpaying and using cheap labor where possible.

What? Where do you get this from? It's quite the opposite.


So the only argument is that the token window is a disadvantage for languages that use more tokens for an equivalent program. But token windows are only getting bigger, and there's also no need to fit the entire codebase in a single prompt.

If anything, it sounds like ruby on rails should've been _the past_ of AI. But it clearly wasn't.


Was going to mention this site. One nice thing it has that could be useful for this app is to have the ability to save a preset and load it in the future. I found it quite useful in mynoise.net


This is in development at the moment and very close to being launched - watch this space


From my research to write the post, it looks like: - the HFP standard was developed mainly for taking calls in a car. It seems like taking calls is still the main use case up to the latest version 1.9,

- macOS switches to HFP whenever the bluetooth headset is in use for both input and output. Interestingly, using the bluetooth mic and macbook speaker doesn't activate the HFP,

- bluetooth in general (not just HFP) seems to be designed to work under the constraint of tech from 20 years ago. Small bandwidths, small batteries, and small computational power,

- there are very nice codecs like Opus that are not used even though they've been working for over a decade.

From there I think the main problem is: - macOS should not assume you're in a call just because you're using the mic. There are a few scenarios where that's not the case and you might not care about low latency,

- better existing codecs should be used, but aren't for some reason,

- bluetooth specs should update the constraint they have to work under.


I'm always surprised with the very low standard for "nice" people have, so I'll vote for that one, even if both possibilities are correct


I tried this as well and didn't work for me. Maybe it works for other people?

When I connect my headphones and switch to the microphone, the same crappy sound comes up. I had tried before with the checkbox in the bluetooth explorer to disable HFP, but also didn't work.


I'm using mSBC, but the quality difference compared with AAC when not using the microphone is wild.


Nice! I didn't know about this. I'll update the post with ToothFairy. Thanks for sharing :)


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: