fix composite: kmsenctreebin.c use max-size-time instead of max-size-buffers

[ruddell]

Fix Kurento/bugtracker#197

I'm not sure of the original use-case of #7 (related mailing-list post), so instead of reverting the queue restriction, I changed it from max-size-buffers to max-size-time (also used in agnosticbin). The composite works as expected again (no audio glitches).

@kc7bfi Does this still change still apply to your issue?

Follows: #7

[jenkinskurento]

Hi there. Thanks for your PR.

I'm waiting for a Kurento member to verify that this patch is reasonable to test. If it is, they should reply with check out please on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

[jenkinskurento]

There were no errors, go have a cup of coffee...

[j1elo]

If @kc7bfi doesn't comment against it, in the next days I'll merge this PR as we've tested that it actually solves the issue

[kylefoley]

Do you know when this will be in a new release of KMS Core?

[j1elo]

Our intention was to release the final 6.7.0 version in the first weeks of January, so we're already a bit late in our schedules. Some bug fixing in other areas have delayed the whole process.
I hope that we'll be able to publish the new version sometime in January

[kylefoley]

I'm able to replicate this issue with kms-core 6.7.0. Can anyone else confirm?

[wnyaonjr]

hello, we are able to replicate with kms-core 6.7.0 as well.
any update on target timeline when to release the fix for this problem in MCU?
Thank you.

[ruddell]

@wnyaonjr We discussed the issue occurring in 6.7.0 here: Kurento/bugtracker#228 We figured out that the "nightly" version in the repository is older than this commit and it is actually fixed. There are instructions at the bottom for installing the latest release which should be fixed.

If you can still reproduce and you are sure your version of kms-core has this commit, please open a bugtracker issue with all of the details.

[wnyaonjr]

thank you @ruddell, highly appreciate your swift response. we will re-test the latest version.

[j1elo]

Hi @ruddell the 600ms seems to be causing audio synchronization issues.
Did you choose that number exclusively based on the same value in agnosticbin? Or there was some additional testing that validated this value (further than simply checking that it works)?

[ruddell]

@j1elo Yes I chose it based on that value, I didn't do any technical tests other than making sure the elements still work (specifically WebRTC, Composite, RTPEndpoint, and PlayerEndpoint). I haven't noticed any issues running this but I'm running Kurento on a powerful server. If it causes issues, please revert but note that will break Composite element's audio (which was caused by #7).