On 22.03.2016 12:09, Tanu Kaskinen wrote:
On Mon, 2016-03-21 at 19:39 +0100, Georg Chini wrote:
Yes, I know. Your patch ignores the cork state for new streams, which
is good, but I tried to suggest that maybe it would be even if we
ignored the cork state also for existing streams.
OK, got you. But that would mean, that the application has to keep track
of multiple cork requests. I am thinking about some stream that is corked
manually. If we send an uncork request to that stream, there are three
possible results:
1) Nothing happens, because the client ignores cork/uncork requests from
the server
2) The client removes one "corking reason" but still keeps the stream corked
3) The stream is uncorked (which is unwanted because it was corked manually)
There is probably no application out there that keeps track of the cork
requests, and to avoid 3) I think we should keep the current logic.
You're right. I was expecting there to be more problems, because the
current logic prevents application from having information that it
might in theory need to manage the cork state correctly, but when
manual corking is the only other "competing" source, I couldn't think
of any use case where the current logic would fail.
If the application does any kind of automatic corking, then incorrect
uncorking may happen. I don't know any real-world use cases, but I can
imagine some application that produces sound while some condition holds
and other times stays silent (corked). For example, maybe I want to
play music every morning from 9 to 10, and I make a program that is
always running, but keeps the stream corked most of the time. Let's say
that at 8:50 a phone call comes in, and it lasts more than 10 minutes.
Since my application didn't get a cork request, because it was corked
when the phone call started, it doesn't know that it should keep the
stream corked, so music starts to play at 9 o'clock.
I'll apply the patch as is.
I think we could work around the problem if the stream had two flags,
"corked_by_server" and "corked_by_client".
When a client corks a stream we set "corked_by_client" and when the
server sends a cork request, we set "corked_by_server".
When an uncorking request arrives from client or server, the corresponding
flag is reset but the stream is only uncorked if both flags are unset.
This would however be another patch series.
So would we send a cork request if a phone call starts while the stream
is corked? If yes, then manual uncorking in Rhythmbox during the phone
call wouldn't work any more. If not, then there's no difference to the
current behaviour.
--
Tanu
Yes, that would be the drawback. As long as the stream is corked
from the server side, manual uncorking would be impossible. So
neither the current situation nor the proposal above cover all
possible cases. Let's keep it like it is ...
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
