-
Notifications
You must be signed in to change notification settings - Fork 211
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
Asynchronous support for ctc/hlg decoding #923
Conversation
The running logs for number streams equals to 2 : Click to see the log
|
k2/csrc/intersect_dense_pruned.cu
Outdated
final_t = | ||
is_final ? final_t + b_chunk_size : final_t + b_chunk_size - 1; | ||
final_t_data[i] = final_t; | ||
final_t_data[i] = his_t + b_chunk_size - 1; |
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.
perhaps you mean this_t?
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.
I mean history_t, this_t may be a better name, or start_t
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.
oh, history_t is fine.
google style guide prefers using whole words, not shortened ones.
See #1091 |
Asynchronous decoding means that the sequences of consecutive chunks can come from different sources, for the production scenarios, not all the waves would come at the same time. With asynchronous decoding we can randomly combine the received chunks into batches.