Re: [Ekiga-list] PTLIB alsa plugin status

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.

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 :-(


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