A goal for me has been to be able to run Opus at 24 bit, 96Khz, with 2.7ms sampling latency. Actually getting 8 channels of that through a loaded box would be mahvelous. On Mon, Nov 20, 2017 at 1:14 PM, Dave Taht wrote: > > > On Mon, Nov 20, 2017 at 5:21 AM, Toke Høiland-Jørgensen < > notifications@github.com> wrote: > >> Pete Heist writes: >> >> >> On Nov 20, 2017, at 1:11 PM, Toke Høiland-Jørgensen < >> notifications@github.com> wrote: >> >> >> >> Pete Heist writes: >> >> >> >> > G.711 can be simulated today with `-i 20ms -l 172 -fill rand >> >> > -fillall`. I do this test pretty often, and I think it would be a >> good >> >> > default voip test. >> >> >> >> The problem with this is that it also changes the sampling rate. I >> don't >> >> necessarily want to plot the latency every 20ms, so I'd have to >> >> compensate for that in the Flent plotter somehow. Also, a better way to >> >> deal with loss would be needed. >> > >> > >> > I wondered if/when this would come up… Why not plot the latency every >> > 20ms, too dense? >> >> For the current plot type (where data points are connected by lines), >> certainly. It would probably be possible to plot denser data sets by a >> point cloud type plot, but that would make denser data series harder to >> read. > > > Winstein plot of latency variance? It doesn't get denser, it gets darker. > > Packet loss vs throughput? > > >> > I guess even if not, eventually at a low enough interval the round >> > trip and plotting intervals would need to be decoupled, no matter what >> > plot type is used. >> >> Yeah, exactly. >> >> > If we want to minimize flent changes, irtt could optionally produce a >> > `round_trip_snapshots` (name TBD) array in the json with elements >> > created at a specified interval (`-si duration` or similar) that would >> > summarize the data from multiple round trips. For each snapshot, there >> > would be no timestamps, but the start and end seqnos would be there >> > (if needed), mean delays and ipdv, counts (or percentages?) of lost, >> > lost_up or lost_down, etc. I’d need to spec this out, but would >> > something like this help? >> >> Hmm, seeing as we probably want to keep all the data points in the Flent >> data file anyway, I think we might as well do the sub-sampling in Flent. >> Just thinning the plots is a few lines of numpy code; just need to >> figure out a good place to apply it. >> >> Handling loss is another matter, but one that I need to deal with >> anyway. Right now I'm just throwing away lost data points entirely, >> which loses the lost_{up,down} information. Will fix that and also >> figure out the right way to indicate losses. >> > > Groovy. > > >> -Toke >> >> — >> You are receiving this because you commented. >> Reply to this email directly, view it on GitHub >> , or mute >> the thread >> >> . >> >> _______________________________________________ >> Flent-users mailing list >> Flent-users@flent.org >> http://flent.org/mailman/listinfo/flent-users_flent.org >> >> > > > -- > > Dave Täht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 <(669)%20226-2619> > -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619