Re: [Ekiga-list] PTLIB alsa plugin status

On Sat, 28 Feb 2009, Alec Leamas wrote:

Derek Smithies wrote:

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

 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).


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
ekiga-list gnome org

Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek indranet co nz
ph +64 3 365 6485

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