Re: [Ekiga-list] PTLIB alsa plugin status

[Alec Leamas <leamas alec gmail com>]

Derek Smithies wrote:
> [ cut, replied earlier today...]
>
>
> > > 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...
First of all: an overview.

You state that the the hw buffering should be two periods, each period 
30 or possibly 20 ms. You havn't mentioned sample rate(?), I assume for 
the moment that we agree on 8 kHz. This would be the interface between 
the codcc and the sound_alsa stuff.  The 20/30 ms  is a requirement from 
the codecs, implemented by the alsa read/write methods.

Andrea has debug printouts from the settings when doing a voice call, 
see the thread "A comparisom ALSA-PULSE" a few days ago. Basically, this 
boils down to 8Khz, period size 160 frames == 20ms, hw buffer size = 800 
frames = 5 periods == 100 ms. This is the sound_alsa /pulse emulated 
alsa interface settings. The buffer is way to large.

And when I take a new look today by making a cat of the /proc/asound 
files I find rate: 44100,  period_size: 8192  == 18.5 ms buffer_size: 
16384 == 37 ms. This is the real stuff, the way pulse handles the alsa 
device.

Bottom up: I'm not worried about the 44.1 kHz. Pulse is designed to 
convert our 8kHz stream to a 44.1 kHz one without any problems. But we 
should be aware of that what we see in /proc/asound is what pulse sets 
up against the hw; our settings vs pulse is another issue. I missed that.

sound_alsa.cxx/pulse:  I really need to look into the code here.... Here 
are a lot of hardcoded values, no symbolic constants... seems that the 
buffer is initially 4 periods (storedPeriods is initiated to 4). The 
setBuffer calls changes storedPeriods and thus buffer size - at a glance 
the code looks OK. So: a simple PTRACE in SetBuffers should reveal how 
the buffers are set. For the moment, I presume that this is how the 
codec's requirement on a specific sample rate is implemented.

I need a whisky. Later on, I'll try refine the documentation for 
PsoundChannel.

> > > 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 ?
No idea. Anyone, out here?

But we seem to have is a 100 ms alsa hw buffer, which will be added to 
any other buffers involved, including the echo cancellation buffer.
> > > 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?
Havn't any, and I havn't had any luck using sound in my VirtualBox VM:s 
either :-(
> Derek.
--a