Audio codec for low-latency radio over RTP

[dashesy]

Hi,

Is there any information on what is the best audio codec for low-latency audio over network? suppose everything is just localhost
I tried L16 (both as RFC 2586 and RFC 3190), but the problem with fixed sample-rate seems to be that no matter how much I try the presentation time (PTS) seems to be affected by inaccuracy of my audio source sample interval.
I am reading from file and form RTP packets, but basically I cannot rely on let's say Windows timing to provide a constant intra-packet interval time, thus VLC client audio is either starving or I get the dreaded "PTS is out of range" message and buffers are dropped.

Please anyone, do you think a codec that has PTS as part of the RTP data payload can solve the issue?
Also when I look at the "scope" audio visualizer it is only about a third of the full width, does that mean something (corrupted data)?
please refer me to any document, thanks.

Thanks and happy new year
dashesy

[dashesy]

To answer some of my questions here
and hopefully get an answer for one remaining question

1- It seems resampling could not recover from the clock drift. I figured out that relying on "HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0" for CPU speed was not a good idea, I changed it to QueryPerformanceFrequency and now "PTS is out of range" messages are *almost* gone. The first two buffers are always dropped though!

Code: Select all

main debug: End of audio preroll main debug: Buffering 73% main debug: Buffering 80% main debug: Buffering 86% main debug: Buffering 93% main debug: Buffering 100% main debug: Stream buffering done (320 ms in 312 ms) main debug: Decoder buffering done in 0 ms main warning: PTS is out of range (-10000), dropping buffer main warning: PTS is out of range (-30000), dropping buffer

2- The scope visualizer length is determined by packet time, for 20ms it is about a third of the screen.
If I increase ptime scope length will change to, so it seems in my case it does not scale to the screen, wish there was an option for that.

I already reduced UDP caching and RTP de-jitter buffer lengths but it seems there is a 0.5 second delay I cannot get rid off.
Now the original question, is there any idea on the best low-latency audio codec/strategy with VLC?

Thanks for any hints

[dashesy]

Does this bug ticket 3794 mean there is no way to go under 320ms when reading SDP from the filesystem?
I have RTP/UDP multicast so it is rtp caching in my case.

[dashesy]

Interesting, to my surprise I changed file caching (access module) and now stream buffering is down to 20ms! Had changed RTP before but it was not affecting 320ms.
On the other hand PTS delay is not affected, maybe because of the decoder buffering.

[Rémi Denis-Courmont]

That bug was fixed in VLC 1.2 over a year ago.

[dashesy]

thanks, is there anyway I can try 1.2 on Windows?

While I have you attention:
by sending elapsed time in RTCP SR (using QueryPerformanceCounter instead of gettimeofday) I get fewer

Code: Select all

PTS is out of range (-X), dropping buffer

messages but after some time the time-lag piles up and it is no longer low latency.
If I do not send any RTCP SR it remains low-latency but after some time buffers are dropped and again low-latency is gone.
I am connecting to the localhost so packets are not dropped and it is a very fast machine.
So my question is this: what timer should I use to make sure VLC can tune to it?