ANC Support

[Ralim]

This is here to track our progress on enabling ANC in this open source firmware for the Pinebuds Pro.

Before I go into this; note I have no idea what I'm doing. This is all really guess and check.
Audio processing like this is new to me; so I'm coming really with no knowledge.

All work for this I'm tracking the anc-testing branch

I've been messing around this on and off and here is my notes so far:

• Set up the correct hardware channels to use correct mics (I hope)
• Hook up ANC button trigger on/off to long press on buds
• Allow enable/disable on any bud [Should work but doesn't, needs debug]
• Disable that damn Du-Du / Dun-Dun noise
• Get the ANC engine to activate
• Get reasonably usable results

Current status

Activating works on whatever bud is the primary for the TWS link; but it does sync the enable to the other bud correctly.
On activation you hear the Du-Du noise.
Then It does do something. I think it does like the worlds most mild ANC; but my testing is limited thus far.

Not certain what next steps are here; we may need to figure out tuning.

Tempted to start looking to pull apart binary dumps from existing bud backups but tracking here for ideas.

Please If you have ideas or do testing etc I'm keen to hear about it.

[lizz-34]

#25

[lizz-34]

#31

[sbot50]

Please don't disable the noise, atleast change it to something less annoying.
I would also like a noise for when you turn up/down the volume (and possibly when skipping or going to the previous song/video), it's hard to know if smth you did worked or not without audio ques, especially when something might only be a very minor change (anc and volume).

[gkaklas]

Hello, thank you for your work! Any updates on this?

I flashed the current anc-testing and it seems to work pretty well! Maybe this can be merged in main?

I think it does like the worlds most mild ANC

The current committed version definitely has an effect (at least for me), although indeed mild.

Of course it can always be tuned more, but is there an important issue preventing general users from using it? 🤔

I too tried to understand the audio processing parameters used, but had no luck yet (I don't know what I'm doing either :P). However I did set the FF gain at 550 and FB at 500 and I think the ANC effect seems pretty similar to the stock effect? 🤔

I also tested a few values for the gain, and I think FB should be a little lower than FF, otherwise I got the static-wind-noise-like effect the stock "Super ANC" had.

(P.S.: I think it would also be really helpful to be able to change parameters without building and reflashing; I know it's shooting a bit high but sending commands would be a generally useful feature for users as well: changing EQ, button actions, etc. Is there already a way that I've missed? I briefly looked at apps/cmd, app_rfcomm_mgr.cpp, etc, but didn't find an obvious way to do it, though I'm really not familiar with the codebase)

[shymega]

Hello, thank you for your work! Any updates on this?

I flashed the current anc-testing and it seems to work pretty well! Maybe this can be merged in main?

I think it does like the worlds most mild ANC

The current committed version definitely has an effect (at least for me), although indeed mild.

Of course it can always be tuned more, but is there an important issue preventing general users from using it? thinking

I too tried to understand the audio processing parameters used, but had no luck yet (I don't know what I'm doing either :P). However I did set the FF gain at 550 and FB at 500 and I think the ANC effect seems pretty similar to the stock effect? thinking

I also tested a few values for the gain, and I think FB should be a little lower than FF, otherwise I got the static-wind-noise-like effect the stock "Super ANC" had.

(P.S.: I think it would also be really helpful to be able to change parameters without building and reflashing; I know it's shooting a bit high but sending commands would be a generally useful feature for users as well: changing EQ, button actions, etc. Is there already a way that I've missed? I briefly looked at apps/cmd, app_rfcomm_mgr.cpp, etc, but didn't find an obvious way to do it, though I'm really not familiar with the codebase)

I'll address both points/questions below.

1. That branch is experimental, and I'd prefer it not to be merged just yet. I would rather wait for my CMake branch to be finished, then merge.

2. Regarding commands: this is on my personal roadmap. We could use BLE or RFCOMM to control the buds, but I really, really don't want to include different settings to be hardcoded in the sources. The buds have a limited write cycle, so it's not a viable option to hardcode in the firmware.

We're a long way off from BLE/RFCOMM control, we have a lot to fix and get working, especially with the license.

Thanks for your comment though, it's good to know that ANC works better with that branch - but I'm hesitant for it to be merged at this time.

[Ralim]

Hello, thank you for your work! Any updates on this?

So the simple answer here is: no
The slightly longer answer is: I've been too busy to get back to it, though my next planned steps were to look at pulling the config out of a user backup and putting it into this struct.

Of course it can always be tuned more, but is there an important issue preventing general users from using it? thinking

No, as far as I know its a "go for it" state, just suuper mild.

I too tried to understand the audio processing parameters used, but had no luck yet (I don't know what I'm doing either :P). However I did set the FF gain at 550 and FB at 500 and I think the ANC effect seems pretty similar to the stock effect? thinking

This is interesting, if you test further, let me know. If we can get even 70% of the way there that would be a big step and cause for a "merge and announce now" deal 🤣

I also tested a few values for the gain, and I think FB should be a little lower than FF, otherwise I got the static-wind-noise-like effect the stock "Super ANC" had.

This makes lots of sense

(P.S.: I think it would also be really helpful to be able to change parameters without building and reflashing; I know it's shooting a bit high but sending commands would be a generally useful feature for users as well: changing EQ, button actions, etc. Is there already a way that I've missed? I briefly looked at apps/cmd, app_rfcomm_mgr.cpp, etc, but didn't find an obvious way to do it, though I'm really not familiar with the codebase)

Nothing is supported that we know of sadly here.

One day BLE yes, but for now no.

[julianfairfax]

So, this issue is for recreating the closed source ANC code as open source code, right? Is it technically possible to extract the ANC support code from the stock firmware, and include it here? It's closed source, I know, but then you could at least "build the stock firmware", which would be cool.

[gamelaster]

@julianfairfax not sure what exactly you mean, but it seems that we can use also the closed-sourced ANC library. Now it is just matter of proper configuration of the ANC parameters.

[nmaggioni]

Is getting the "Ambient Mode" stock function just a matter of tweaking/swapping the ANC gains or is it a completely different implementation? If the latter, maybe it could be easier to hack together than proper ANC?

[Ralim]

@nmaggioni As far as I understand with suuper limited knowledge, yes its just a different set of filters. It could also be implemented by a different code path for debugability but unsure. Honestly havent touched it.

@julianfairfax
In both cases the code for doing the ANC is the binary blob bes provide.
We cant just (easily) reverse engineer the code from the production firmware as its stripped down.
So instead we are looking to figure out what calibration and settings was used by prod firmware to get OPB to have at the least a "working pass" of an ANC option. Often once you get a rough working pass going, others chime in and help more as well.

[Ralim]

@nmaggioni
Looking further, yes talk-through mode is just an entirely different set of filters

[gkaklas]

Thank you for taking the time to respond!

The buds have a limited write cycle

Just curious, is there a development board than can be used? No PineBuds dev kit like the pinetime :(

There would still probably be a need to wear them though to test audio features; I see that the builded firmware is 945KB, and the SRAM is 992KB? I don't have much experience with this, but would a slimmed-down version of the firmware be able to run from memory? (Although focusing on sending commands would probably be better, but just wanted to throw this out there; has this been discussed before?)

That branch is experimental

Maybe it could be merged but only enabled with a build option? Really unstable future commits of course should still be pushed to a wip branch, but as I understand, currently this branch isn't in a "it will randomly disconnect and brick your buds" state but more like "the quality needs more fine-tuning to be able to be advertised to the general public as a 100% stock replacement" state.

I think having it in a wip branch doesn't do justice to how well it works! And it was the main reason I haven't migrated to OPB these months, until I really needed to look more into it.

I would rather wait for my CMake branch to be finished, then merge.

Oh of course, I only wanted to provide feedback on the ANC quality.

If we can get even 70% of the way there

I've been using it these couple of days, and since it doesn't seem to e.g. brick my buds or crash them (right? 🤔 I don't see any dangerous changes), my experience is that it's pretty good (if not great) to be used at least by an early adopter/programmer who doesn't mind adding (and being warned for) a feature flag when building, especially when their alternatives are to either not use OPB, or to use OPB with no ANC at all (or to check out an experimental branch, carefully examine all the new commits, and then read the discussion here to see if someone reported any serious problems).

In any case, can anyone else chime in on the quality of the ANC for them? To see if it just happens to be good for my specific environment/ear size and shape etc. (Reminding that I use FF=550,FB=500 gain instead of the ~380..440 currently committed)

Edit: Wow it seems that yesterday Ralim made some new commits, including a tool to parse the struct from a firmware dump, this is great!

[Ralim]

Just curious, is there a development board than can be used? No PineBuds dev kit like the pinetime :(

Dev board wasnt made in production sadly.
Noting I'm a few hundred write cycles in with no issues at all. I think mostly this is to discourage trying to save audio to the flash.

There would still probably be a need to wear them though to test audio features; I see that the builded firmware is 945KB, and the SRAM is 992KB? I don't have much experience with this, but would a slimmed-down version of the firmware be able to run from memory? (Although focusing on sending commands would probably be better, but just wanted to throw this out there; has this been discussed before?)

Not really possible, ~500KB of ram is required for audio buffers and BT + a bunch is used as a flash cache i think.

Maybe it could be merged but only enabled with a build option? Really unstable future commits of course should still be pushed to a wip branch, but as I understand, currently this branch isn't in a "it will randomly disconnect and brick your buds" state but more like "the quality needs more fine-tuning to be able to be advertised to the general public as a 100% stock replacement" state.

I think having it in a wip branch doesn't do justice to how well it works! And it was the main reason I haven't migrated to OPB these months, until I really needed to look more into it.

I'm leaning towards this too, of just merging it as "may or may not work for you"

In any case, can anyone else chime in on the quality of the ANC for them? To see if it just happens to be good for my specific environment/ear size and shape etc. (Reminding that I use FF=550,FB=500 gain instead of the ~380..440 currently committed)

Similar vibe here. I did port the "tuning" from the firmware backups (Thanks to everyone who added them).
Would be curious if that makes much of a difference to you, it doesnt to me which makes me suspect I'm still missing a setting (working on finding it now)

Edit: Wow it seems that yesterday Ralim made some new commits, including a tool to parse the struct from a firmware dump, this is great!

yeah this was used for ^

[gkaklas]

Would be curious if that makes much of a difference to you

It might, but I'm not really sure, I think changing the gain was more noticeable (I also tested the new coefs with high gain). By noticeable I mean louder ANC, while the parameters probably would change the quality of the noise reduced? Which are both important but the latter could need a more tuned ear or experience to hear the difference (which unfortunately I don't have).

And since this is what you got from the data dumps, it's probably the best that we can do for now; in the future someone could figure out the numbers and tune it further from there (which I think would be another issue on how to reproducibly and objectively test the performance etc)

I did port the "tuning" from the firmware backups

I played with anc_decoder a bit; I diffd the outputs for all the files and I noticed the only thing different between devices is the gain, is that correct? So I thought we could get a rough idea on that:

• I chose to highlight values >550 and <320 because I thought that they all would be at around 400-500
• I directly compared the structs after parsing them in order to avoid duplicates (I also checked the skipped filenames and duplicates were from the same user, which makes sense)
• I'm curious about that 2^32 and the zeroes for the right channel 🤔
• It seems that, ffl for 41k, and fbl almost always, are 512, while the rest of the values are really specific; it seems like a default value, is that expected? Maybe the factory only tuned 44k?

I hope this helps a bit to maybe find an average to set by default (of course ideally it could be set by the user, but it could be a while before we can send commands). But maybe you did that already for the recent commit?

working on finding it now

Again, thanks for your work!

(Should I make a PR for anc_decoder? I think it would be better if I were to refactor the structs into a lib crate or a module first, then maybe use clap to generate a help message, parse cli options etc so I thought I should ask you before making a PR, if needed. Maybe the tool also belongs in a separate repository? (like bestool) It would makes sense especially if there was a need in the future to read more audio settings)

[Ralim]

My original plan was to drop anc_decoder in a squash before merging the branch in. As its really only useful it extracting the params once. And I didnt want to ship it around / support it long term. It was a hack job, I made it in one sitting and one cup of coffee.

I think if we want it to stick around we might want to make a new repo for BEStooling and port it over there?

working on finding it now

Havent gotten anywhere yet 🤣

I'm curious about that 2^32 and the zeroes for the right channel thinking

I believe each bud is setup to be mono, so each one only uses "its" left channel config.

It seems that, ffl for 41k, and fbl almost always, are 512, while the rest of the values are really specific; it seems like a default value, is that expected? Maybe the factory only tuned 44k

Quite possible.
We also have the 57k or whatever it is one that is used if you have resampling enabled, could be they only tuned one or the other.

Forgot to mention not to use my backup, its a different firmware so different offsets.

[Haxk20]

@Ralim The task of allow/disable on any bud can be marked as completed now :)

[shymega]

@Ralim The task of allow/disable on any bud can be marked as completed now :)

Done.