[pulseaudio-discuss] How to control playback start timing (RAOP)

[Hajime Fujita]

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
>