Also, when starting playback, protocol-native.c does not recognize this large latency. Should this also reflect the large latency? ( 22.962| 0.000) I: [lt-pulseaudio] protocol-native.c: Requested tlength=40.00 ms, minreq=13.33 ms ( 22.962| 0.000) D: [lt-pulseaudio] protocol-native.c: Traditional mode enabled, modifying sink usec only for compat with minreq. ( 22.962| 0.000) D: [lt-pulseaudio] protocol-native.c: Requested latency=13.33 ms, Received latency=250.00 ms ( 22.962| 0.000) D: [lt-pulseaudio] memblockq.c: memblockq requested: maxlength=4194304, tlength=97608, base=8, prebuf=0, minreq=4704 maxrewind=0 ( 22.962| 0.000) D: [lt-pulseaudio] memblockq.c: memblockq sanitized: maxlength=4194304, tlength=97608, base=8, prebuf=0, minreq=4704 maxrewind=0 ( 22.962| 0.000) I: [lt-pulseaudio] protocol-native.c: Final latency 526.67 ms = 250.00 ms + 2*13.33 ms + 250.00 ms Thanks, Hajime 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. > > 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? > > > [1]: There's a header named "Audio-Latency" in some response, but > apparently it's not working or at least we don't know how to interpret > the number correctly. > > > Thanks, > Hajime > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >
