How to control playback start timing (RAOP)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux