[pulseaudio-discuss] Loopback patches

[Georg Chini]

Hi Tanu,

finally I am finding the time and motivation to continue on the loopback 
patches.
Sorry for the long delay, I hope you still remember some of it. I have a few
questions regarding the thread separation. You write (20.7.2016):

"I'd be happy if you could somehow clearly divide the variables in
userdata based on from which context they're supposed to be accessed.
For example, pa_sink has field "thread_info", which is an embedded
struct that holds the sink's IO thread variables, and there are other
similar uses of a "thread_info" struct elsewhere. You could add
"sink_thread_info" and "source_thread_info" to the userdata struct."

On the other hand, looking through your comments you only complain
about variables belonging to the main thread which are (wrongly) accessed
from an IO thread:

1) source_sink_changed -> only set in main thread and detach() callback, 
so OK,
no change needed.

2) iteration_counter -> only set in main thread, in detach() callback 
and in conjunction
with the two calls of update_minimum_latency(). Will be corrected with 
the changes
necessary for update_minimum_latency()

3) latency_error -> like source_sink_changed

4) extra_latency -> like iteration_counter

5) underrun_counter -> like iteration_counter plus one additional 
asynchronous message
in sink_input_process_msg_cb(). An asynchronous update is OK, so no need 
to have a
underrun_counter_in_thread variable.

6) underrun_occurred -> This flag is used as a message between the 
threads, the
output thread sets it when an underrun occurs and it is reset by the 
main thread.
So I think the usage is OK in this case.

6) minimum_latency -> will be corrected with the changes for 
update_minimum_latency()

There are also two functions, which are currently accessed from multiple 
threads:

1) memblockq_adjust() which should only be used from the output thread. 
No problem,
can be corrected by using a synchronous message.

2) update_minimum_latency() which should only be used from the main 
thread. Will be
corrected by sending asynchronous messages to the main thread. The use of a
minimum_latency_in_thread variable is not necessary I think, because it 
does not hurt
if the IO threads gets the information only after the message has been 
processed by
the main thread.

Is my assessment correct and does the division you are asking for really 
make sense
under these circumstances?

Regards
              Georg