Closed gavv closed 1 year ago
Hi @gavv . This issue seems interesting.
However, do you have any recommendation of docs/videos/etc to familiarize myself with this repo? (e.g. basic concepts, common glossary, api/code structure, etc)
Thanks.
@rafiramadhana Hi!
Since roc-go provides bindings for roc-toolkit, I guess the best place to start is docs for roc-toolkit itself: https://roc-streaming.org/toolkit/docs/
In particular, the following pages may be useful:
Also, information from this issue may help: https://github.com/roc-streaming/rt-tests/issues/1
Feel free to ask question here on in chat.
Let me know if you would like to be assigned.
@gavv I'm going to spent time for reading first.
I will let you know when I'm ready.
Thanks!
Given it another though, I decided this is actually too big for one task. I've created separate issue for each enhancement and provided more details:
@rafiramadhana Feel free to leave a comment in those issues if you would like to pick up one.
Currently we have one simple test (
sender_receiver_test.go
added in #24), which runs sender in receiver in two goroutines and waits until receiver will get a few non-zero samples.It would be nice to add a few more sophisticated tests. We don't need to test all possible combinations in bindings, since we assume that the underlying library is already tested; however covering a few important features and checking that everything works as expected would be helpful.
Things to cover:
Tests with and without FEC. The checks can be same, we just need to ensure that both configuration work.
Tests with and without resampler. When resampler is enabled, it's hard to compare streams, and we should just check that we receive some amount of non-zero samples. When resampler is disabled, on the other hand, the receiver wont modify the stream, and the only difference between input and output streams are possibles losses (when FEC can't recover packets) and shifts. In this case we can perform a more strict check and ensure that we receive the expected stream, except possible losses and shifts.
Test for external and internal clock sources. See documentation for details; internal clock source means clocking by CPU timer inside sender or receiver, and external clock source means clocking by user, i.e. requires calling read and write at appropriate time.
Tests for multiple contexts, senders, and receivers. Possible combination are: one receiver or sender per context, or multiple receivers and sender sharing same context; one sender connected to receiver, or multiple senders connected to a single receiver.
For background, see the following links: