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
