Support for Bose and Fairphone speakers/headphones/earbuds

[lizz-34]

Don't get me wrong, this time isn't yet. However, I would like to inquire if there would be a possibility and how we could bring support and install this firmware to headphones such as Bose 700 and Fairphone True Wireless Earbuds?

[lizz-34]

I'll just mention @Ralim @ThatcherC to focus on the base goals of the project.

I agree, right now we're just focusing on PineBuds Pro, but in the future I think we'll definitely try to make this a bit universal.

[Ralim]

Yeah @WebWire-NL is on the money here. This codebase is very very tightly coupled to the chip used.

I suspect that will be true for a very long time; and at this point trying to support other devices would be naïve. Trying to make the code too general purpose is how you end up with the current mess that we have.

I think sure we can support other bes earbuds that have flashing connections exposed but probably in 6-12onths when things are in a better place.

For devices that use Bluetooth OTA it would be even later than that.

Really this sort of firmware is 99% support libraries for the specific chip with a thin layer of customisation on top.

For things like the Bose, it would be better to start a new project for those and do similar to what we are doing here in getting a cleaned up and modernised codebase working first.

If a project like that existed, we could certainly look at working together though.

[lizz-34]

@WebWire-NL

It's all about the chipset used and the UART interface to program the devices if we are ever able to use the code for the mentioned or other earbuds.

Could we not flash these devices using their OTA update method? Then we don't need UART.

As far as i know they don't use the same chipset, BOSE is known for their proprietary chip's. And if i see the specs of both earbuds (couldn't find the chipset's) i can't imagine they are based on the same chipset. But of course i can be wrong

I know there are a lot of problems here. Some heaphones use propietary, in-house chip, some may have something like chain of trust and often it is not possible to do the flashing over wire using e.g. UART (which is more reliable than OTA); unless you disassemble the heaphones and program the chip directly. We can probably add (good) support only for devices like PineBuds Pro, but I'd still like to explore the possibility.

The code is heavily based on the chip itself, so i don't think it's possible to make it universal to anything else than devices using this hardware.

I know this is the case now. But this is not Assembly, this is C, which is universal. You can compile it for any CPU.
Let's make this modular. I'm sure that many parts (e.g. Bluetooth handling) can be used in many devices. Of course, some parts (drivers) are hardware specific, but we can make build parameters to select e.g. PineBuds Pro. Then it builds the universal parts combined with PineBuds Pro specific parts.

Just because this isn't universal yet doesn't mean it can't be. Yeah, we can't do something like Linux kernel in embedded devices, but we can definitely do a bit modular and universal.

It's basically a chip which offers a lot of features even NFC and as i read 8 microphones.

Yeah I know, what do you mean?

You should see the firmware/SDK just as a tool used to configure the chip. Nothing really reusable for other purposes.

No one has denied that it is currently completely hardware specific.

[lizz-34]

@Ralim

I suspect that will be true for a very long time; and at this point trying to support other devices would be naïve. Trying to make the code too general purpose is how you end up with the current mess that we have.

That's true, but my point is that maybe within a year or so we could support other devices using the same chip. And that some day in 2-4 years we could support completely different devices, such as Bose, JBL, Marshall, Sony or other headphones with a completely different chip. Assuming the device doesn't have insurmountable technical limitations (like chain of trust) preventing it. Do you think this is impossible?

I think sure we can support other bes earbuds that have flashing connections exposed but probably in 6-12onths when things are in a better place.

Great!

For devices that use Bluetooth OTA it would be even later than that.

Yep.

Really this sort of firmware is 99% support libraries for the specific chip with a thin layer of customisation on top.

?

For things like the Bose, it would be better to start a new project for those and do similar to what we are doing here in getting a cleaned up and modernised codebase working first.

We don't have codebase for Bose. It's propietary firmware.

[gamelaster]

@lizz-34 we will never support any other Earbuds, unless one of two conditions are fulfilled:

1. The earbud uses chip from which we have SDK for (but still, without schematics, it is useless, as probing such small PCB is huge pain and effort).
2. The vendor itself wants open source firmware

I think more realistic is that someday, ordinary PineBuds will release, with low price and less features but still good quality.

About the support libraries which @Ralim mentions, please, whole this firmware is tightly tied to BES Hardware Abstraction Layer, thus their drivers. It is not modular, so even when we have, for example, SDK for Sony Earbuds, it uses different chip, different SDK, and this project (yet) is not modular for such support. One day, it might be, but right now, no.

[lizz-34]

@gamelaster

The earbud uses chip from which we have SDK for (but still, without schematics, it is useless, as probing such small PCB is huge pain and effort).

I understand that without design documents (schematics, pinouts, etc.) developing software for the any device is really hell. I also know that there are no other earbuds/headphones/speakers than the PineBuds Pro whose desing documents is public. However, if (hypothetically) for example design documents for the Fairphone TWE (AFAIK uses a completely different SoC than PineBuds, no BES's chip at all) were released, would we be able support for it? Then we could make the modular, universal firmware I described that supports several different devices? Or am I wrong? There is no way to do that for audio devices?

Well, we all know that Bose, Sony, JBL, Marshall or others will not provide design documents for years, if ever. However, if we want support for a few devices (for example Bose and Sony flagships), is it possible to do reverse engineering? That has been done with many mobile device SoCs and elsewhere. Or is there something in the audio devices that prevents this?

About the support libraries which @Ralim mentions, please, whole this firmware is tightly tied to BES Hardware Abstraction Layer, thus their drivers. It is not modular, so even when we have, for example, SDK for Sony Earbuds, it uses different chip, different SDK, and this project (yet) is not modular for such support. One day, it might be, but right now, no.

I fully understand that now this firmware isn't modular or universal at all. AFAIK this is a slightly modified version of the SDK made specifically for the BES chip. I'm talking about the future here (which of course may sound stupid to you, because you understand better what kind of work the things I describe are. I'm only JS dev.).

[gamelaster]

Then we could make the modular, universal firmware I described that supports several different devices?

Of course, I guess this is plan, to make this modular, but it needs to be done step by step. First step is clear the code and get it to stable state, afterwards it can be made modular.

Reverse engineering of existing buds is possible, but very hard and not worth post of the times.

[erebion]

to headphones such as Bose 700

I just hope this would make switching between devices less painful.

I'm way too often searching for the 2nd device the headphones are connected to, just so that I can disconnected it and play something on the other device... xD