On Sun, 2016-06-05 at 21:05 +0200, Georg Chini wrote: > @@ -561,10 +559,10 @@ static int sink_input_process_msg_cb(pa_msgobject *obj, int code, void *data, in > Â Â Â Â Â Â Â Â Â Â Â Â Â length = pa_memblockq_get_length(u->sink_input->thread_info.render_memblockq); > Â > Â Â Â Â Â Â Â Â Â Â Â Â Â u->latency_snapshot.recv_counter = u->recv_counter; > -Â Â Â Â Â Â Â Â Â Â Â Â u->latency_snapshot.sink_input_buffer = > -Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â pa_memblockq_get_length(u->memblockq) + > -Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (u->sink_input->thread_info.resampler ? pa_resampler_request(u->sink_input->thread_info.resampler, length) : length); > -Â Â Â Â Â Â Â Â Â Â Â Â u->latency_snapshot.sink_latency = pa_sink_get_latency_within_thread(u->sink_input->sink); > +Â Â Â Â Â Â Â Â Â Â Â Â u->latency_snapshot.sink_input_buffer = pa_memblockq_get_length(u->memblockq); I would suggest renaming the sink_input_buffer variable, if it's not going to include the render_memblockq buffer. "Sink input buffer" typically means the render_memblockq, so this use of terms is potentially confusing. I propose "loopback_buffer" or "memblockq_buffer". "loopback_buffer" is a bit problematic, since the reader's intuition may be to understand it to contain the whole end-to- end buffering, and "memblockq_buffer" on the other hand is a bit vague (there are many memblockqs, how to make it obvious that it's referring to u->memblockq?). Despite these problems, in my opinion both of these suggestions are better than "sink_input_buffer". Better ideas are welcome. Otherwise looks good. --Â Tanu
