On Thu, 2013-10-17 at 22:54 -0500, Hajime Fujita wrote: > Hi Tanu, > > Thank you for the message. > > Tanu Kaskinen wrote: > > On Wed, 2013-10-16 at 22:04 -0500, Hajime Fujita wrote: > >> Hi, > >> > >> I've been working on raop2 support for the raop module. > >> > >> Currently when starting playback through RAOP, there is a huge delay in > >> sound. 2-3 sec after starting music from a player software, actual sound > >> starts being heard from the speaker. > >> And as a result, there is a gap between a screen and sound. For example, > >> progress counter of a player software shows "00:03" when the actual > >> music begins. This would be a serious issue when playing movie. > >> > >> I'm wondering how I can solve this issue. I think most of the delay is > >> due to protocol initialization and impossible to reduce. So the feasible > >> approach might be to tell the application that playback is not yet ready. > >> > >> Is there any document or existing module from which I can learn some > >> idea to address this issue? > > > > If you want lip-sync with movies, you "only" need to provide accurate > > latency information in your sink implementation. The latency reporting > > is done by handling the PA_SINK_MESSAGE_GET_LATENCY message. It seems > > that module-raop-sink.c (the version in upstream) already tries pretty > > hard to estimate the latency accurately. I think the logic depends on > > TCP's flow control, though, and if I recall correctly, you were working > > on UDP support. Does the RAOP protocol have any latency reporting > > functionality? If not, then you can only guess what the real latency is. > > That's right. RAOP2 is using UDP and the current technique in upstream > does not seem to work. I'm not sure if there is an explicit latency > notification in RAOP2 protocol[1], but I think I can somehow estimate > the timing using several timing packets and so on. > > Before figuring out how to estimate the accurate latency, I tried to > return a large (~2-3 sec) latency upon PA_SINK_MESSAGE_GET_LATENCY > message to see what happens. > (BTW, the handler is supposed to return microseconds, right?) > > It seems that timing gap between pictures and sound gets better in > general, but I experienced a few issues. > > 1. I got several "Implicit underrun" once in about every 15s. > > ( 78.834| 1.289) D: [raop-sink] protocol-native.c: Implicit underrun > of 'audio stream' > ( 78.835| 0.001) D: [raop-sink] protocol-native.c: Requesting rewind > due to rewrite. > ( 78.835| 0.000) D: [raop-sink] sink-input.c: Requesting rewind due > to corking > ( 78.836| 0.000) D: [raop-sink] module-raop-sink.c: RAOP: IDLE > > The last line "RAOP: IDLE" means that the sink module got PA_SINK_IDLE > message. > When I get this message, there's an interruption in sound. Do you get also "RAOP: IDLE" message every 15 seconds? It looks like the application that plays to the RAOP sink corks (pauses) itself every 15 seconds. Perhaps as a reaction to the underrun? This is pretty unusual behavior from the client. > > 2. There's still a huge timing gap right after starting playback. Once I > get an interruption which I mentioned above, the gap seems to be reduced. > > Any ideas, or suggestions? Nothing off the top of my head. -- Tanu
