-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split data blob functionality out of component code and add single data blob mode #5509
Conversation
24889dd
to
e6efe61
Compare
I dropped the extraneous example and testing commits, but they are still available here: https://github.com/jsarha/sof/tree/single-data-blob-test |
e6efe61
to
aca9e0d
Compare
Fixed exotic component and zephyr builds. |
aca9e0d
to
70e85a4
Compare
Fix cmocka builds. |
70e85a4
to
4d05644
Compare
Fix couple of typos. |
The data blob handler functionality is quite independent from the rest of the generic component code. The component.c and component.h are already too big so it is better to split the data blob handler functionality out before adding more features to it. Signed-off-by: Jyri Sarha <[email protected]>
231268d
to
ed7df93
Compare
@@ -22,17 +22,40 @@ struct comp_data_blob_handler { | |||
uint32_t data_pos; /**< indicates a data position in data | |||
* sending/receiving process | |||
*/ | |||
uint32_t single_blob:1; /**< Allocate only one blob. Module can not | |||
* be active while reconfguring. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
im curious, why can it not be active?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole feature is for components with very big configurations. In those cases we can not afford to have two copies of the configuration blob in the DSP memory. This also means that when we receive a new configuration - in multiple IPC fragments - we must release the old configuration first (or reuse the old buffer). This means that we do not have a valid configuration during the update so the audio pipeline must be inactive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, can we get that clarified in either comments or some docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already something in comp_data_blob_handler_new_ext() doxygen documentation, but the motivation for the feature is missing. I'll add one more sentence about saving DSP memory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MingJenTai FYI, so you don't need to do it in your own blob. This is also safer as we can fuzz this
I recommend you stress test your code on a chromebook with this script #4769 (comment) |
2e286b5
to
69ddca2
Compare
The single blob mode keeps only one configuration blob available at one time and saves the memory otherwise consumed by the second blob. The down side of this behaviour is that the audio pipeline must be stopped for the configuration to be updated. Signed-off-by: Jyri Sarha <[email protected]>
@juimonen is there an easy way for me to get my hands on a chromebook? |
You may need to get @sathya-nujella or @sathyap-chrome to generate a build for you with the hotword library in it |
@jsarha there is a quite easy physical way that we drive with our cars the the office and I'll give you one laptop :) |
Actually this PR does not do much in itself since it defaults to the old behaviour. Can you tell me which component I should modify to take the single blob feature into use for it to affect the referred case? google-hotword-detect? |
I have no clue if CRAS would abide by the requirements. That being said, RTNR is trying to add something that this could use. |
@cujomalainey fwiw - we may have also reproduced the CRAS blob loading issue on testbench and valgrind. We do a lot of blob loading and then we get an inconsistent state and then a freed memory deref..... https://github.com/thesofproject/sof/runs/5664281753?check_suite_focus=true
|
That is great to hear, but do we have an understanding of the root cause yet? |
Not yet - looks like above was my misunderstanding of the log, i.e. the log was only showing a check for blob and not processing it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsarha I assume by default we use the existing mode i.e. no existing topology needs updated ?
@mwasko good for you now ? |
Yes, no changes to current behavior until some component uses comp_data_blob_handler_new_ext() and its extended parameters. |
The motive behind this PR is to provide means to save DSP memory with components that require very large configurations.
Bit surprising - when using single blob mode - that even if a set_cmd() is rejected because state == active, the configuration is sent again right after the component is stopped and started again. I guess this is the Linux side drivers doing. Otherwise the code appears to work based on my brief tests.
If the two first commits look Ok, I'll drop the others out and change this from draft to a real PR.
In the end this was much simpler that I anticipated.