Re: [Ekiga-list] PTLIB alsa plugin status


On Fri, 27 Feb 2009, Alec Leamas wrote:

Hm... a write operation could be guaranteed to return in finite time (using non-blocking io + snd_pcm_wait). So couldn't the close method just mark the chanell as closing, leaving the dirty work to the "writer" thread and thus avoiding the locks? (Which, otoh, really isn't a big issue in this scenario). If required, opening could be handled in the same way, I guess. This would also create the advantage that the thread could process the jitter buffer data in parallel with the alsa output, without the need to wait for the IO to complete. Wouldn't this give a more accurate timing? Also, avoiding blocking io is a Good Thing IMHO.

It must be a blocking write. The architecture of opal demands this.

The play thread (using play as an example) repeatedly does the following
  read rtp packet from jitter buffer
  put raw audio to sound device (which delays for up to framesize of

There was a time when pwlib and openh323 (the old names of ptlib and opal)
used non blocking writes to the sound card plus software timers. the software timers were found to not be reliable enough to delay the write thread. Sometimes the delay was hundreds of milliseconds. So openh323 and pwlib were changed to use blocking writes, which gave much better audio performance.

to change the operation of the write to be non blocking would have major architectural implications to opal. Let me help you. This won't happen.

I don't think this aspect of the the Opal design is a problem. The problem we are are trying to address is the reason for the buffering - why is there a 100ms delay???
Yes. I  *think* I've seen  five periods hardcoded somewhere...
Can you find the hardcoded bit? And report it?

There are two entities that I have seen which can "store" audio to give you a delay.
The jitter buffer, which can store seconds of audio.
There are status variables in the jitter buffer which indicate how long it is buffering audio for.
As I suspected. Thanks also for this. So basically we have network latency, jitter/echo cancellation buffer and the device/alsa buffer, all in total preferably in the 150 - 200 ms range. If there is no echo cancellation, the alsa buffer (if larger) could also be jitter buffer. But not if fancy things like echo cancellation should be performed (?).
You may have the answer here.
 How much delay does the speex echo cancellor introduce ?

it is defaulted to..
The thing is that when looking at the alsa device from the operating system level (in the /proc filesystem) it's clear that the buffer is 5 periods * 20 ms = 100 ms (details in the thread initiated by Andrea). So something is not as expected... Is the simple truth that the alsa period size doesn't match the codec chunk size? But even if so, should it matter? "suspicious"

Alsa probably introduces a delay/buffering of its own when you do alsa<-->pulse conversions.

Can you repeat the above test on an older distro where the machine does not have pulse?

Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek indranet co nz
ph +64 3 365 6485

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