Speaker Diarization Task: Clustering stage crashes(Process killed) for long audio files using CPU
Hello,

I've been testing the NeMo diarization example, using clustering inference on many different datasets and inputs using CPU only. On files up to 90 minutes in length, the diarizer reached around 25Gb RAM consumed in the clusterization stage. When I tried to diarize a 4 hour file that has 2 speakers using CPU only, the process was killed in the clusterization stage, no matter the configuration file used.

The configuration I used:
- clustering_diarizer/offline_diar_infer
- vad_multilingual_marblenet
- embeddings extraction: titanet_l
- configurations: either meeting or general ( both crashed)

The way I solved the process crashing problem was by splitting the 4 hour audio in 4 parts, and then merge the predicted rttms at the end by taking in consideration the offset between parts and checking if the speaker labels match. The issue is that the cluster labels on each file may differ from the other files, even if it is the same original audio split into 4. With only 2 speakers, it may be easy to check and switch the speakers labels so they match between all corresponding parts, but when there are more than 2 speakers, it's impossible.

My questions are: is there a way to avoid the process being killed when using long audio files(above 2 hours for example) on CPU(I can't used GPU)? If there isn't, is there a way to match the speakers from each split from the original audio? (example: speaker 1 in part 1 may be corresponding to speaker 4 in part 2) I was thinking about extracting an mean affinity matrix for each speaker in each part and then calculating the cosine distance between all speakers. 

Any solution, idea or feature that is already implemented would be greatly appreciated! 