We're building hearing aids that work in noisy places (AudioFocus[1], YC S19). We use novel machine learning and microphone array design to help patients hear better in loud restaurants, weddings, & family gatherings better than any other AI hearing aid.
It's a big deal because untreated hearing loss is associated with social isolation & depression and while 37M people have hearing loss in the United States, only 8M use hearing aids. Hearing in noisy places is the biggest reason for lack of adoption.
We just got our behind-the-ear (BTE) hardware prototype running and already have several excited patients. Listen to an audio recording from it here[2]. We're currently working on a pilot study with a professor in San Francisco.
If you, or someone you know, is interested in participating in the pilot study let me know. And if you know interested investors, I'm happy to chat with them. I can be reached at [email protected]
Love this idea. I hoped that my AirPods with Live Listen would do the same but was disappointed that it sounded similar to your benchmark example or worse.
I wonder if you all can use another layer in your ML stack to "fill out" the voices once you've isolated them. Your example leaves voices sounding very thin/hollow and even a bit garbled.
AudioFocus | Oakland, CA | Hardware Design Co-Founder | Full-time
AudioFocus (YC S19) makes hearing aids that work in noisy places like bars. We use a combination of an in-house built auralization framework and deep learning models to accomplish this. Our prototype runs on the iPhone and we're looking for someone to built a hardware prototype and take it all the way to mass manufactured scale.
and are a lifelong learner, have interest in ML processors, and have worked at Apple AirPods, a hearing aid company, Bose, Doppler Labs, or something similar.
Founded by me (UC Berkeley, BS-EECS, 2011; UC Berkeley, PhD-ML, 2019). Contact: [email protected]
Thought this paragraph was particularly interesting:
“The notion that any risk assessment instrument can account for bias ignores the racial disparities in current and past policing practices.” There are abundant theoretical and empirical reasons to support this claim, since risk assessments are typically based on data of arrests, convictions, or incarcerations, all of which are poor proxies for individual behaviors or predispositions. The coalition continued, “Ultimately, risk-assessment tools create a feedback-loop of racial profiling, pre-trial detention and conviction. A person’s freedom should not be reduced to an algorithm.” By contrast, the Partnership’s statement focused on “minimum requirements for responsible deployment,” spanning such topics as “validity and data sampling bias, bias in statistical predictions; choice of the appropriate targets for prediction; human-computer interaction questions; user training; policy and governance; transparency and review; reproducibility, process, and recordkeeping; and post-deployment evaluation.”
Seem's like they're addressing superficially irresponsible AI deployment but ignoring some of the deeper, complex, ethical issues raised by technologies like facial recognition.
I see some people are feeling conflicted trying to balance 1) Making the web more accessible with 2) Increasing business/startup costs.
It's important to remember making websites more accessible often benefits everyone in some way. e.g. providing an alt text description for images on your website obviously benefits visually impaired users, but it also benefits people who can't afford high bandwidth or people who are moving through a remote area. In the Microsoft framework these three scenarios are called:
1) Permanent (Visually Impaired)
2) Temporary (Can't afford high bandwidth)
3) Situational (In a remote area)
There's good online resources for understanding these concepts [1,2,3].
Anyway, for companies as big as WinnDixie, with $10B in annual revenue, they should be designing their websites to be accessible by everyone. For small businesses it would be nice if website building providers like SquareSpace and Wix made this as easy as possible for their users.
As a blind person, I think that accessibility matters most in situations where there's little competition and/or high switching costs.
A startup building a new email client shouldn't be required to implement accessibility, certainly not from the start. There are enough accessible solutions in that space, and while accessibility would be nice, it would make the barriers of entry much higher.
On the other hand, Facebook, a company famous for prosecuting app developers for (mis)using their API, should absolutely be required to do so. If all your friends are on Facebook, you're not even allowed to build a more accessible Facebook client.
I also believe that we should legalize 3rd party apps if the original app is inaccessible, regardless of the TOS or presence of DRM.
FWIW, I'm very sure third-party apps are already legal (and have always been legal): the issue was never that you aren't legally allowed to make them, it is merely that, once you do, the company making the product goes out of their way to break your client or ban your accounts; so, what you'd really need to do is to make it actively illegal for a company to prevent you from making a third-party app... even by any such technical means that they will absolutely defend as some form of "spam prevention" or "security mitigation" or "content restriction".
What I mean is get rid of any way that the legal system can be used to prevent third-party apps. TOSs, CFAA, DMCA, contracts, etc. should all be null-and-void when used to prevent interoperable third-party apps.
Companies with large market share should also be actively required to facilitate interoperability, e.g. with APIs available on FRAND terms.
I am very confident the DMCA already doesn't apply even if this were a copyright issue (which I don't think it is) due to interop exemptions, terms of service generally aren't legal issues in the first place, and the CFAA doesn't apply as there is case law that this is not "access". I maintain: there already is nothing stopping you from making a third party client except 1) how people keep making the stupid mistake of violating trademark law in their third party client (which is trivially avoided) and 2) the legal right of the service to refuse service to anyone... you need to make that actively illegal, and then defend that that makes sense against the onslaught of arguments that they need to be able to ban people due to spam prevention, security mitigation, and content restriction (and the EFF coming out of nowhere with some kind of argument that this is going to undermine the right of free speech of the company due to similar arguments as to Section 230, etc).
You would also need to mandate that they supply a reason for banning you that you can argue against. As it is now you could just get banned with no recourse or reason for using a 3rd party app on many platforms.
Also, making webpages inaccessible usually takes work. Reasonable use of semantic HTML, styling, and alt tags for images are probably good enough. It's when you start doing ridiculous things with SPA frameworks (something no asked for or wants) that this gets hard.
The art of standard serverside generated HTML and progressive enhancement or a page composed of JavaScript apps/widgets for interactive elements seems lost today. In the age of React everything is a SPA first by design from observations.
Having previously worked and taking a great interest in the schematic web last decade, progressive enhancement, accessibility, page size, etc etc the modern web is disappointing when what should be a simple HTML website instead be a blank white screen while it downloads 2mb+ of assets then a SPA bootstrap to show something loading json blobs embedded in the page and leaking information with the insistence of doing everything client side.
I disagree. Even if an SPA framework (or more likely a library add-on) does a good job of reinventing the wheels of traditional HTML requests (e.g. announcing the name of the new "page" when it loads and setting focus), there are always going to be more details that will be at least a little harder to implement on each site.
I'm not fundamentally opposed to JavaScript frameworks, even when used to make SPAs. I think their downsides can be worth using them anyway and issues like accessibility can be overcome. They are a paradigm that are chosen too often without enough thought about the downsides and are a bad choice as default.
It appears that the exemption noted by others for businesses with fewer than 15 employees only relates to the obligation to accommodate employees, not customers. [1]
For example, one of the links provided elsewhere is to an EEOC website. The EEOC is the Equal Employment Opportunity Commission, which only relates to employment, not to accommodating customers.
Even if the ADA does have carve outs, if a small business wants to do business with any government/public entity they most likely will have to meet some level of accessibility. A VPAT[1] is commonly asked for in these cases.
Basic accessibility is nearly 'free' if someone uses modern web standards, and runs a tool to check during development. Things like alt tags, proper html tag usage, keyboard navigation (logical and without traps), and good contrast are good programming/design and good for every user.
I agree that following web standards gets you a lot in terms of accessibility and is a part of good programming and design.
There's a lot that automated checkers don't find. They can detect if an image lacks an alt attribute, they can't tell if an alt attribute's value is bad. Many are pretty good at at least flagging where there might be a color contrast problem for a human to double-check. They don't automatically find interactive components that aren't keyboard navigable or operable. They don't know when the DOM order of content doesn't make sense.
For me though, making sure keyboard navigation works properly early on speeds up the develop and test cycle. I also think that in many cases, perfect ends up the enemy of the good. It's a different conversation if a disabled person contacts someone about a site with a suggestion for improvement rather than it doesn't work at a all.
For the web, screen readers are easy, the only thing I find problematic are some of the color contrast requirements. There have been several instances where we've had to make designs definitively worse in order to accomodate those.
I somewhat question the need, as well—at some of the contrast levels we're talking about, if your vision is that bad, you should really consider enabling a magnifier, color filter, or even a screen reader.
What becomes really problematic, however, are PDFs, which are supposed to be a quick way to offer printed documents digitally, without too much extra work. Making those work with screen readers can take a long time, and there have been some cases where clients decided to just remove them from their websites. I'm not sure what to do about that, but I'm concerned we're creating barriers to sharing information, with anybody.
Totally. Especially if you design correctly from the start. Adding accessibility to a site/app/etc that was designed for years without it in mind is a pain in the ASS, but doing it from the start is simple.
The contrast issues sometimes make design a bit harder, but it's totally worth it I believe.
I don't think that's a solution; sure, making the site more accessible makes you reach more users even beyond the "disability" angle, but that doesn't make it a winning cost-benefit tradeoff immediately if ever.
EDIT: By analogy, it's very like software portability. If you make your software support Windows and MacOS and assorted Linux distros and the major BSDs and Haiku, you'll get more users. But if you only target Windows you'll get 80% of the market, and Windows+MacOS will get you 90%, and after that you really need to think about whether it's a good investment to target more platforms. By all means, be accessible because it's the right thing to do or legally required, but it's not obvious that it's a sound business move.
The reason the ADA exists is that it's almost never a profitable cost-benefit tradeoff to accommodate people with disabilities.
But I'd much rather work at a company that was 1% less profitable or live in a society that was 1% less wealthy and accommodated people with disabilities than one that left them in the gutter.
Well, it’s easy to comply with ADA cheaply if you do it right the first time but a pain in the ass to retrofit things later.
At least with webdev the problem is most people stumble into it and are not formally taught much about webdev specifically if at all. My undergrad never taught me a single thing about webdev practice. It’s not like, say, architecture, where you not complying with accessibility regulations will be taught formally, or later when you actually implement it some code compliance inspector is going to deny you a permit to build. It really is the wild west in webdev still.
I was specifically responding to a comment that said accessibility wasn't expensive because it lets you reach more people (or at least that was my reading of it). Yes, by all means be accessible because it's the right thing to do - I object only to the idea that we should do it because it makes sense from a pure money perspective. It's a good thing, that's just not the reason.
I agree it's still not going to win the cost-benefit tradeoff in most markets. OTOH - I imagine making your software support more OSs is much more expensive than designing your website to be more accessible, at most $1M/year. If you've got billions in annual revenue that's pennies in the bucket.
In my view, it's about trying to provide more 'equal opportunity' in this world where it's financially feasible. This seems like a case where it is more often that not. Again, for medium+ businesses.
Uber settled a case similar to this in 2016 [1,2] and agreed to "Require that drivers provide equal service to people with disabilities who travel with service animals." Seems like they haven't learned their lesson, and this minor new $1.1M fee is unlikely to change their behaviour. OTOH, from a Teacher of the Visually Impaired (TVI) I know: -
"It’s challenging. I think they need to make it really clear this is part of their job. It’s common for people not to allow dogs in their car, just in general. On top of that, they employ a lot of people who don’t speak english and people from several cultures who would never have a dog in the car."
There are a lot of challenges with putting this in a hearing aid: low latency inference (10ms), small power budget, consistent performance, fault tolerance, etc. Still a fair amount of R&D to be done, but change is coming.
Is it too difficult to ask for one that distributes the processes between phone/external device, rims of glasses and in the ear speaker. It will go a long way in addressing the issue of stigma and enabling more people to use it early.
A big hurdle for doing this is latency, every time you hop from one device to another you're adding at least ~10ms of latency if it's over anything like bluetooth. There might a clever way to do it, it's something I'm thinking about but it's too early to say.
For now it looks like it's going to be a behind-the-ear hearing aid. Maybe in 5-10 years it could fit in your ear canal.
How many microphones do you need to do this filtering? I wear hearing aids myself and if you can do it that that level on a real hearing aid that would be amazing.
In this demo there is only one microphone on the phone. But we're working on stereo (2) microphones now. That will help make it more reliable, lower latency, and give you spatial awareness (awareness of the direction of sound).
