Re: [Opalvoip-devel] ALSA glithches

[Robert J. <ro...@vo...>]

Your assumption is not correct.

Between the audio socket and the sound card there is a jitter buffer, 
and the operation of the jitter buffer is critically dependent on the 
operation of the sound device. The jitter buffer "smooths" the erratic 
arrival of packets over the wire, which over a long haul internet can be 
100ms or more of variation, and plays them to the sound card in the 
extremely regular period required by the real time nature of the sound card.

Now, as we are not running on a real time operating system, that regular 
play out cannot be done with simple timer, they are too erratic. Just 
becuase you go "sleep(10)" does not mean the sleep is for 10 
milliseconds, it can by much, much more. To avoid this, OPAL utilises 
the fact that most operating systems are quite good at scheduling 
threads when I/O is available. So the "output" side of the jitter buffer 
writes to sound device until it blocks, and every time the operating 
system has availability it unblocks and OPAL writes more audio to the 
sound device.

So, the critical bit, that means that the sound device must block, and 
be able to block on relatively small amount of data. The 
PSoundChannel::SetBuffers() function sets these limits. For example, 4 
buffers of 320 bytes at 8kHz would result in 80ms of data being played 
and every 20ms, the PSoundChannel::Write() unblocks and another 320 
bytes will be taken from the jitter buffer and written. If the 
underlying driver cannot do this, then the sound will usually work, but 
will not be very good with clicks and drop outs etc.

And if that wasn't complex enough, I have not even got into mismatched 
sample rates, bad RTP data and adaptive jitter buffers!


Bottom line, the ALSA code has been around quite some time. Ekiga uses 
it, and a lot of people use Ekiga. Never any certainty, but chances are 
your problem is with the hardware or device driver and not the PTLib 
code. Though, you might be able to compensate in the PTLib code. It is 
still an enormous pain, and I do not envy you if you have to fix it, and 
can't just avoid it.

*Robert Jongbloed*
/OPAL/OpenH323/PTLib Architect and Co-founder./
Commercial support at http://www.voxlucida.com.au

On 17/05/2014 8:06 PM, Alexander Sbitnev wrote:
>   Ok thanks. I suppose practical tests will show how many problems can 
> this buffering produce.
> Can you shed some light on bunch reads and writes from sound device? 
> Those bunches initiated on higher levels of opal and ALSA code is just 
> on the bottom of callstack.
> I can assume it have something to do with processing of networking 
> frames which most likely contain some timeframe.
> When sound RTP frames arrive it just being decoded and written to 
> sound plugin immediately? Is my assumption correct?
>