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.
which verifies Andreas' logs i. e., this is what causes the oversized alsa
hw buffer. I made a quick search, there are no references to SetBuffers in
the plugin code. So these calls comes from the upper layers. For the moment
I'll stick to the alsa plugin and will not investigate this any further.
_______________________________________________
ekiga-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/ekiga-list
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: [email protected]
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
_______________________________________________
ekiga-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/ekiga-list
