The VideoLAN Forums

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

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!
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

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.

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.

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

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 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?