Feature request: Generate bsinc tables at runtime on startup

[asvitkine]

Feature request: Generate bsinc tables at runtime on startup.

Currently, the embedded bsinc tables take up a large proportion of the library's disk footprint. This could be minimized with a an option to instead generate these at start up, using the same code as bsincgen.

This could be added as a build option for use cases where minimizing the library size is desirable.

[kcat]

It does that since 1.21.0. Starting with commit 8853519d896f11b678873f0afacac16b3cdebc27 (there's been additional commits since then that fix problems that came to light afterward), the tables are calculated when the library is initialized.

[asvitkine]

Oh, nice!

However, compared to 1.18.2, the compiled size is still larger with 1.21. :\

On my M1 Mac w/ MINSIZEREL:

1.18.2: 513747 1.19.1: 795267 1.20.1: 1134771 1.21.1: 695795

So 1.21.1 is much better than the previous two versions, but still not as small as 1.18.2.

I'm not sure exactly what all the growth is. For my case, maybe it's worth backporting the change to 1.18.2 since 1.18.2 works fine and could benefit from bsinc being generated at runtime.

(I'm sure you can point to lots of improvements since 1.18.2, though.)

[kcat]

1.19 embeds the HRTF data by default (ALSOFT_EMBED_HRTF_DATA), which slightly increases the library size but doesn't require extra .mhr files to support HRTF at runtime, and adds a higher quality bsinc filter. 1.20 increased the bsinc table size to improve its quality. 1.21 then changed to runtime generation of bsinc tables.

I can't audit where exactly all the bytes are coming from on an M1 Mac build, but new features and functionality gets added over time which will increase the library size, separate from the bsinc tables. New effect processors, rendering post-process handlers, new extensions that need support code, etc. It's natural for the library size to get bigger with time since it's rare for features to get removed, unless it causes maintenance problems and too few people use said features.

[asvitkine]

Thanks for the extra info.

Turning off ALSOFT_EMBED_HRTF_DATA in 1.21.1 brought the size down to: 611635 (down by 84k)

So still larger than 1.18.2. Also, smaller delta than 1.18.2 -> 1.19.1. I guess the 1.19.1 growth is not just due to ALSOFT_EMBED_HRTF_DATA? Let's check...

1.19.1 without ALSOFT_EMBED_HRTF_DATA is: 630051 (down by 65k than w/ and up by 116k over 1.18.2).

1. Is it expected that ALSOFT_EMBED_HRTF_DATA is a larger in 1.21.1 than 1.19.1? Did the HRTF data increase in size?
2. Do we know where the other 116k of binary size increase in 1.19.1 came from that's not caused by HRTF?

[asvitkine]

Adding -dead_strip to LINKER_FLAGS brought the size down from 611635 to 607683 for 1.21.1 w/ out HRTF. So this can potentially be upstreamed.

[kcat]

Is it expected that ALSOFT_EMBED_HRTF_DATA is a larger in 1.21.1 than 1.19.1? Did the HRTF data increase in size?

No, the HRTF data should actually be less with 1.21 compared to 1.19. If 1.19.1 with the embedded data is 795,267 bytes, and 630,051 without, that's a difference of 165,216 bytes. Which makes sense, nearly double the 84k it removes with 1.21. With 1.19, there were two default/built-in HRTF datasets, one for 44.1khz playback and one for 48khz. With 1.20.1, the library gained the ability to resample HRTF datasets when loading them, so one of the datasets was removed which would cut its size in half. 1.20 also increased the size of the bsinc tables.

I don't know what tools are available on Mac, but nm --size-sort lets you see what size the various symbols in the library are (anything tagged with b is in the bss section, which takes no disk space; it's initially-blank memory that gets allocated and initialized at loadtime).

Do we know where the other 116k of binary size increase in 1.19.1 came from that's not caused by HRTF?

The bsinc table sizes were increased in 1.19, to help improve their quality. I don't know if that would fully account for it, but it would definitely be a significant contributor.

[asvitkine]

Thanks! You're right, I used the wrong number when checking the 1.19.1 size - I accidentally compared to 1.21.1.

OK that makes sense. Should -dead_strip be added to the linker flags?

[kcat]

There doesn't seem to be much readily-available information on what -dead_strip does. It seems to be Darwin-specific. MinSizeRel builds should already link with -s to strip unused symbols/code, so I'm not sure what else -dead_strip would do to know if it could be a problem.