[pulseaudio-discuss] Loopback patch 3 (patch 9 in previous series)

[Georg Chini]

On 03.02.2017 11:03, Georg Chini wrote:
> On 23.01.2017 08:38, Tanu Kaskinen wrote:
>> On Sun, 2017-01-22 at 12:14 +0100, Georg Chini wrote:
>> One more question: May I send a synchronous message from input
>>> to output context or vice versa? I tried it for getting the source
>>> latency in estimate_combined_latency() and it worked, but I am not
>>> sure if this is a safe thing to do.
>> Ok, so let's assume that we're sending a synchronous message from the
>> sink thread to the source thread (I don't know why you would want to do
>> that in the other direction). The problem with that it's very messy if
>> the source output moves to another source before processing the
>> message. I don't know if that causes bad breakage or not, but I'd
>> prefer not having to think about that case.
>>
>> The possibility of a deadlock needs to be considered too, but as long
>> as the source thread never waits for the sink thread to do something,
>> there should be no risk of deadlocks.
>>
> Hi Tanu,
>
> I finally arrived at some working code for patch 9. Unfortunately I see
> no other possibility to get a meaningful value for the source latency
> within the pop_cb() than to send a synchronous message from the
> output thread to the input thread from the pop_cb().
>
> In the code, it looks like this:
>
>         /* If the source is valid, get the latency. Else we can safely 
> set pop_source_latency
>          * to zero, it does not matter since the final adjustment will 
> be done when the source
>          * becomes valid */
>         if (u->source_output->source)
> pa_asyncmsgq_send(u->source_output->source->asyncmsgq, 
> PA_MSGOBJECT(u->source_output), SOURCE_OUTPUT_MESSAGE_GET_LATENCY, 
> NULL, 0, NULL);
>         else
>             u->source_snapshot.pop_source_latency = 0;
>
> Do you think this is acceptable? Since I am sending a synchronous 
> message, the
> source cannot move away (or can it?) and if it is moving, 
> source_output->source
> will be NULL and the final latency adjustment will be done when the 
> source becomes
> valid.
>
> Regards
>              Georg
>
Uh, it looks like this is not acceptable ... sorry for the noise this 
weekend. I finally hit a case
where it does not work. When the source is already at my bluetooth 
headset and then I
move the sink also to the headset, pulseaudio stalls. I don't understand 
where the deadlock
comes from, it happens only in that special situation. Maybe in the HSP 
case there is only
one thread for input and output.

So the patches I sent are still wrong. (I also noticed that I replaced 
one bug by another, I'm
now using pa_asyncmsgq_post where I should use pa_asyncmsgq_send in
get_effective_source_latency() ... spent too much time programming this 
weekend).

I just tested - using pa_source_get_latency_within_thread() directly 
works fine. Can't I use it
and add a comment that I'm using it because there seems to be no other 
way? Or do you
have any idea how I could estimate the source latency from some 
previously saved value?
Since we assume that source and sink each take an unknown time to start 
up, I cannot see
how I could calculate backwards and I also see no other place than the 
pop_cb() where I could
do the adjustment. Ignoring the source latency does not seem to be an 
option. In the case
of USB, it can grow up to 2 seconds. For the same reason, postponing the 
adjustment to the
next push does not look like a good idea either. Any suggestions?

Regards
              Georg