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
_______________________________________________
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list