Skip to content
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

ResNet backbone vs. mask pooling #1634

Open
hbredin opened this issue Jan 31, 2024 · 2 comments
Open

ResNet backbone vs. mask pooling #1634

hbredin opened this issue Jan 31, 2024 · 2 comments

Comments

@hbredin
Copy link
Member

hbredin commented Jan 31, 2024

It has been noticed that the 3.1 pipeline efficiency suffers from speaker embedding inference. With the default config, every 10s chunk has to undergo inference 3 times by the embedding model. It proves effective by separating the whole embedding model pipeline into the resnet backbone and the mask pooling. With this modification, every chunk only needs to be inferred one time through the backbone, bringing almost 3x speedup in my experiment. Furthermore, cache inference strategy helps a lot as well, given the default overlapped ratio of 90%.

Originally posted by @mengjie-du in #1621 (comment)

Hey @mengjie-du, that's a nice idea. Would you contribute this to the pyannote.audio codebase? I tried to send you an email at the address mentioned in this paper but received an error message in return -- so I am taking my chance here.

@mengjie-du
Copy link

Sorry for late response.
My experiment code is built upon a unwarpped version of 3.1 pipeline only for cpu, which includes two mentioned separated onnx model (ResNet backbone and the final FC). The musk pooling is implemented using Numpy. Thus, the code can't be embedded into the pipeline directly. I plan to test a version compatible with the pipeline soon.
I think the key point is the line 322 in pipelines/speaker_diarization.py, where the same wave data is yielded three times. It would be more effient to yield used_mask with a shape like (spk, 1, num_frames). This adjustment would allow the model to infer all of these together without some big modifications to the control flow..

@hbredin
Copy link
Member Author

hbredin commented Feb 12, 2024

Thanks. Will also look into this myself.

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

No branches or pull requests

2 participants