Re: [Opalvoip-devel] ALSA glithches
Brought to you by:
csoutheren,
rjongbloed
From: Robert J. <ro...@vo...> - 2014-05-18 23:35:51
|
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? > |