Damien Sandras wrote:
Le dimanche 01 mars 2009 à 17:53 +0100, Alec Leamas a écrit :
Derek Smithies wrote:
On Sat, 28 Feb 2009, Alec Leamas wrote:
Derek Smithies wrote:
Hi,
On Fri, 27 Feb 2009, Alec Leamas wrote:
I need a whisky.
Coffee is much better. Don't add any impurities though (milk, sugar
etc)
I'm was actually using both whisky AND coffe w milk. Sorry, no
offense... :-)
After some serious fights w the build system, I've been able to add a
simple PTRACE to the SetBuffers method in sound_alsa.cxx. Trimmed
output:
13:45:49.348 ALSA Setting buffers, size: 3840, count: 5
13:45:49.402 ALSA Device default Opened
13:45:49.438 ALSA Setting buffers, size: 320, count: 5
It is set in opal in
OpalAudioMediaStream::OpalAudioMediaStream(
where soundChannelBuffers is set to the supplied parameter value.
This comes out of the pcssendpoint class, which
which ends up coming from: a method of the pcss endpoint which gets
the user defined buffer depth...
soundChannelBuffers = pcss endpoint.GetSoundChannelBufferDepth()
so you know what ?
I think this is a bug from outside of ptlib&opal. The default values
for codec sizes in ptlib&opal are for a count of 2 buffers (unix) and
3 buffers(windows).
Derek.
Indeed. I have submitted a temporary patch to
http://bugzilla.gnome.org/show_bug.cgi?id=572953. Not tested, but
should be better than today. If it not makes other problems
visible...Many thanks for your help with his, I wouldn't really have a
chance without it.
This patch will break with some hardware, even on Linux.
With the standard 8 kHz codecs, there is not more than 2-3 errors on 1
Mbyte of data using a two periods hw buffer and a 150 ms jitter buffer
from Sweden to the echo server. I've added logging code to the alsa
driver to show this. I have not been able to get any usable results
using the 16 kHz codecs against [email protected] (no sound at all...). If
the jitter buffer is decreased to 50 ms there are more errors, but then
the sound is so bad anyway that it's not a valid usecase.
Thinking about it, I can't really see why two or three periods should be
a problem unless the jitter buffer is to small (or the system
overloaded). And it's the user who sets the jitter buffer. I really
think the defaut value should be smaller 2 (or 3) on Linux. Question is
how to adjust this value if needed. Yet another "hidden" gconf variable?
Is it needed, can this be handled by the jitter buffer?
Anyway, this is a way to get rid of 40-60 ms of latency on Linux, more
on windows. I think it deserves to be thought of, it is a substantial
gain. BUt bot until the release is out :-)
--a
PS: I can now accept calls with the gtk message box. This used to crash. DS
--a
_______________________________________________
ekiga-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/ekiga-list
