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

Embeddings takes 3x the length of the audio length #1687

Open
cdreetz opened this issue Apr 14, 2024 · 7 comments
Open

Embeddings takes 3x the length of the audio length #1687

cdreetz opened this issue Apr 14, 2024 · 7 comments

Comments

@cdreetz
Copy link

cdreetz commented Apr 14, 2024

Tested versions

  • pyannote-audio 3.1.1

System information

windows 10 - pyannote.3.1.1 - rtx 3070

Issue description

Diarization taking much longer than it should, using the progress hook see that getting embeddings is the slow part. The audio file I am using is a minute long, but the embeddings step alone is taking 3:14. Also when running it is using the majority of my vram, like upwards of 6.5GB. I can't find anything online that shows what the actual size of speaker-diarization-3.1 is but I didn't think it was suppose to be that big.

Also when I upload the wav file to Google Colab and run the same exact code it runs almost instant. So can't think of what locally is causing the embeddings to run so slowly.

ProgressHook output when ran locally:
segmentation 100% 0:00:00
speaker_counting 100% 0:00:00
embeddings 100% 0:03:14
discrete_diarization 100% 0:00:00

NVIDIA GeForce RTX 3070

Minimal reproduction example (MRE)

https://colab.research.google.com/github/pyannote/pyannote-audio/blob/develop/tutorials/MRE_template.ipynb

@cdreetz
Copy link
Author

cdreetz commented Apr 14, 2024

Update: I just uninstalled pyannote.audio 3.1.1 and installed 3.1.0 instead and it fixed it. Running the same exact code with 3.1.0 took 3.06 seconds, but with 3.1.1 it took 3 minutes and 14 seconds

@hbredin
Copy link
Member

hbredin commented Apr 18, 2024

That's strange.

Looking at the diff between 3.1.1 and 3.1.0, I see no reason why this would happen:
3.1.0...3.1.1

@JuergenFleiss
Copy link

Also found very long runtime for embeddings in 3.1.1 on both Ryzen and Apple M1 CPU. Around 27 and 20 minutes for a 22 minute audio file.

@cdreetz
Copy link
Author

cdreetz commented Apr 24, 2024

@hbredin yeah I tried to look at the diffs between the versions and couldn't find anything that would cause the issue. I almost didn't even try the older version because there didn't appear to be much code difference, yet it still resulted in huge change in processing time

@cdreetz
Copy link
Author

cdreetz commented Apr 24, 2024

@JuergenFleiss did you try the same processing with 3.1.0?

@JuergenFleiss
Copy link

tried it, did not change; worked fine with 3.0.0; we will try to revert back to that

@JuergenFleiss
Copy link

After reading further, I think I am actually experiencing issue #1621

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

3 participants