Re: [Ekiga-list] PTLIB alsa plugin status

[Derek Smithies <derek indranet co nz>]

Hi,

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.

No.
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
  decode
  put raw audio to sound device (which delays for up to framesize of
                          packet)


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?


> > Answer:
> > 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.
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek indranet co nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/