Skip to content

Conversation

@serhiy-katsyuba-intel
Copy link
Contributor

*** Do not merge ***
TEST

{ 4096, 11},
{ 8192, 10},
{ 65536, 3},
{ 32768, 8},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, this is not just an increase in size but also a different configuration of memory blocks. Is this the optimal split?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, new extra 0.5 MB are used to introduce new 32 kB and add more 64 kB blocks. Before this change practical maximum buffer size was 8 kB, as we could only allocate max 5 buffers larger then 8 kB. That number of buffer is usually not enough even for simple topology.

Is this the optimal split?

That's actually the problem with our current implementation: we have to define blocks configuration at compile time and as we have to support formats from 8 kHz to 192 kHz, 1 to 8 channels, 1 ms buffers to 100 ms buffers, there could be a problem to define optimal split. Now half of the memory is sort of "reserved" for KPB buffer -- that seems quite un-optimal.

Maybe the proper solution would be to re-implement virtual heap allocator to eliminate the need to define any blocks at compile time. Similarly like this is currently done for Zephyr heap. But that's not a quick fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants