You mean esd_get_latency() returns -1 and _get_delay() then returns huge delay values messing up everything else?

Does this commit fix it?

http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/ext/esd/esdsink.c?r1=1.64&r2=1.65

 2007-01-04  Tim-Philipp Müller  <tim at centricular dot net>

       * ext/esd/esdsink.c: (gst_esdsink_delay):
         Don't return bogus values when esd_get_delay() fails (#392189).

Created attachment 79424 [details] [review]
The esdsink which I modified

I'am sorry that this commit can not fix this bug.
The esd-server handle a requirement from the esd-client by several loop operations. When the esd-client want to play a sound stream, it will send a requirment to the esd-server. If this channel was authenticated by the esd-server, the esd-client began to send sound stream by writting it to a buffer and the esd-server read the stream from the buffer.
  When the state of esdsink was set from GST_STATE_PLAYING to GST_STATE_PAUSED, the esd-client will stop to write sound stream into the buffer. But the esd-server still want to get data from the buffer and if can't, it will be blocked here. When you set the state of esdsink from GST_STATE_PAUSED back to GST_STATE_PLAYING, the esdsink must get the latency from the server and then start to write the buffer. But, unfortunately, the esd-client can't get the latency because the esd-server was blocked. So the esd-client didn't write stream into the buffer. The esd-server  was also blocked because it can't read data from the buffer. This situation is similar to Dead-Lock.
  I modified esdsink to bypass this bug. But it was not so good:)
 

Jay,

I don't understand how your modifications to esdsink would fix the problem you describe. Can you explain the thinking behind it?

 

Jay: ping? Any chance you could answer Jan's questions?

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!