| 00:22.16 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 01:10.55 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 01:41.03 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 01:41.03 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 03:05.32 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:81d6:6cd3:a44:9972) |
| 04:28.27 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 05:58.25 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:05.56 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-tpuidrxvmuusphdo) |
| 06:44.33 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 06:52.50 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ppbqmadgnrbneykw) |
| 07:01.05 | *** join/#asterisk-dev GameGamer43 (sid5533@gateway/web/irccloud.com/x-czrobsfhdvixdgbi) |
| 07:04.15 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:05.41 | *** join/#asterisk-dev X-Rob (X-Rob@gateway/web/irccloud.com/x-tbimtnmsodrjgzpm) |
| 07:37.51 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:37.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:44.34 | jkroon | file, you are absolutely correct, sorry, had to run off last night. |
| 07:46.09 | snuff-work | file is correct a lot lately this could be bad for the rest of us =) |
| 07:47.15 | jkroon | lol, how so? |
| 07:50.46 | jkroon | https://gerrit.asterisk.org/#/c/2708/ - if someone could take a peek I'd very much appreciate that. |
| 08:09.26 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:34.17 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 10:08.28 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 10:19.57 | file | snuff-work, not so easy ^_^ |
| 10:23.28 | snuff-work | mm.. i realised i formatted my subject for gerrit wrong =( not very 'standard' of me |
| 11:24.59 | file | the sun is bright |
| 11:30.39 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-whdchourvosmdbgs) |
| 11:30.39 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:03.11 | *** join/#asterisk-dev acidfoo_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 12:17.59 | tzafrir | I'm trying to use DAHDI dynamic local spans on a KVM system. No luck. They keep getting into and out-of red alarm. |
| 12:19.00 | tzafrir | dahdi-base is supposed to provide timing, and dahdi-dynamic-loc explicitly won't pretend to provide timing |
| 12:19.42 | tzafrir | Any idea what to do with it? |
| 12:23.04 | jkroon | tzafrir, you're the guy i'd normally query about such things ... |
| 12:33.40 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:28.29 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:28.29 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:29.34 | file | hi cresl1n! |
| 13:30.58 | cresl1n | file! |
| 13:55.19 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zdytphsnlcrnblib) |
| 14:18.53 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-bqxjuzjmxjotfmzq) |
| 14:19.14 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-fiyckhqhtecysbqf) |
| 14:27.23 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 14:55.45 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 14:55.45 | *** mode/#asterisk-dev [+o ChanServ] by sendak.freenode.net |
| 14:58.31 | *** join/#asterisk-dev scouture (~scouture@c-50-189-76-173.hsd1.ma.comcast.net) |
| 14:58.44 | *** join/#asterisk-dev swimmercol (~lancelot@router.tor.ipnordic.dk) |
| 15:09.20 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 15:13.40 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 15:28.45 | jkroon | https://gerrit.asterisk.org/#/c/2708/ - may I safely assume that Matt is referring to a unit test of sorts? how do I go about that? |
| 15:36.06 | file | he's referring to a testsuite test |
| 15:37.12 | jkroon | file, ok, so unit testing. how do I go about writing such a test? |
| 15:37.15 | file | https://wiki.asterisk.org/wiki/display/AST/Pluggable+Component+Framework has an example of a pluggable one, but it's usually easiest to grab a similar test and start from there |
| 15:37.30 | file | unit testing is different - testsuite is functional testing |
| 15:43.46 | jkroon | thanks, looks intimidating... |
| 15:44.56 | file | it's not that bad if you find an existing test which you can use as a base |
| 15:53.29 | file | super useful though |
| 16:01.06 | jkroon | eesh, but screws up my package manager ... |
| 16:01.27 | jkroon | this is definitely a candidate for using a VM for ... |
| 16:11.36 | jkroon | ok, so basically create an extensions.conf and confbridge.conf, set up a UserEvent on priority 2 in the regcontext and verify that the event fires after dialing a Local/ into the bridge? |
| 16:12.30 | cresl1n | file: riddle me this, or tell me what I'm missing |
| 16:12.43 | file | jkroon, sounds about right |
| 16:13.00 | file | cresl1n, I don't like where this is going |
| 16:13.02 | cresl1n | or rmudgett |
| 16:13.04 | cresl1n | https://gerrit.asterisk.org/#/c/1820/9/main/translate.c |
| 16:13.51 | cresl1n | lines 635 to 650 |
| 16:14.13 | cresl1n | I'm trying to think of what case where current == inner |
| 16:14.19 | file | oh, down there |
| 16:14.50 | cresl1n | except for the first frame of course |
| 16:15.36 | cresl1n | so first run of the loop out becomes inner |
| 16:16.21 | cresl1n | because out is not set yet, and inner should be produced by the first run of the translation list |
| 16:16.45 | cresl1n | on a subsequent run the translation list produces another frame |
| 16:16.48 | cresl1n | so inner becomes set again |
| 16:16.59 | cresl1n | and out had previously been set at first iteration |
| 16:17.11 | cresl1n | so we trigger the block at line 635 |
| 16:17.35 | cresl1n | current becomes out |
| 16:18.03 | cresl1n | current shouldn't have inner in it, right? |
| 16:18.07 | cresl1n | it hasn't been added yet |
| 16:19.07 | jkroon | you trying to add PLC to translate? |
| 16:19.15 | cresl1n | someone is |
| 16:19.15 | jkroon | ie, just duplicate frames on loss? |
| 16:19.37 | cresl1n | Alexander Traud I think |
| 16:20.18 | cresl1n | what a confusing bit of logic |
| 16:20.28 | jkroon | ok, sorry, thought it was your code. if I look at that block he's basically pre-pending the frame if there is missing frames? Is that sane? Some codecs have PLC built in don't they? |
| 16:20.39 | cresl1n | yes |
| 16:20.42 | jkroon | so lines 596-624 is OK. |
| 16:20.46 | cresl1n | this is so the PLC works |
| 16:21.26 | cresl1n | jkroon: that's what I belive |
| 16:21.28 | cresl1n | those lines are ok for now |
| 16:21.37 | cresl1n | I think the rest is probably ok |
| 16:21.44 | cresl1n | but I'm trying to verify his logic |
| 16:22.02 | jkroon | i honestly don't even understand what the rest is trying to achieve and the memory management looks rather complex. |
| 16:22.21 | cresl1n | the rest is partly to make the translator work |
| 16:22.49 | cresl1n | and partly to handle the case where you have a framelist as an input now to the translator instead of just a frame |
| 16:22.58 | jkroon | ok, so lines 624 through to 650 should be the original code, for each frame. |
| 16:23.05 | cresl1n | it's now chaining together an output list as well |
| 16:23.12 | cresl1n | in case there are a few frames returned |
| 16:23.15 | jkroon | why not just replay the frame x number of times? why actually duplicate them? |
| 16:23.41 | cresl1n | so that the sequence numbers are right |
| 16:24.00 | file | it hurts my head |
| 16:24.03 | file | but all translation stuff does |
| 16:24.06 | cresl1n | awww man |
| 16:24.18 | jkroon | so you can save the sequence number, reduce it by the number of missing frames, and just loop incrementing the sequence number until such time as they are equal? |
| 16:24.41 | cresl1n | while this might be true, not sure I want to think about that quite yet :-) |
| 16:25.39 | jkroon | ok, so we duplicated the frame, looks like it's possible for the incoming frame to be chained already? ie, multiple actual voice frames? based on the existing code? |
| 16:25.50 | cresl1n | not sure |
| 16:26.00 | cresl1n | which incoming frame? |
| 16:26.11 | cresl1n | the one passed into ast_translate? |
| 16:26.16 | jkroon | good question. the one incoming for translation. |
| 16:26.18 | jkroon | yes. |
| 16:26.25 | jkroon | so f |
| 16:26.27 | cresl1n | Right now I'm assuming no |
| 16:26.36 | cresl1n | but good question regardless |
| 16:26.56 | cresl1n | goes to look where ast_translate is called |
| 16:27.32 | jkroon | various places. i patches res_fax as well to use it. |
| 16:27.57 | cresl1n | I'm guessing it could be possible at some point, but probably is not done right now |
| 16:28.04 | cresl1n | so, very relevant question |
| 16:28.13 | file | it is... possible... |
| 16:28.22 | file | doesn't have an example |
| 16:28.30 | file | but it's certainly not forbidden... I think... |
| 16:29.09 | cresl1n | ast_translate is written with a single frame assumption |
| 16:29.19 | cresl1n | I think it'll break in that case |
| 16:30.32 | jkroon | the reason i ask is if you look at the original code it already seems to iterate on something there... can a single incoming frame generate multiple outgoing? eg, ptime=20 on one side and ptime=30 on the other? |
| 16:30.49 | cresl1n | jkroon, I questioned that as well |
| 16:30.56 | cresl1n | translation doesn't do ptime handling |
| 16:31.00 | jkroon | what happens with the spare bits? are they stored in the ast_trans_pvt? |
| 16:31.04 | cresl1n | I think a smoother will take care of that at a later stage |
| 16:31.09 | jkroon | ok, so bitstream in, bitstream out ... |
| 16:31.11 | file | yeah, smoothers do that |
| 16:31.23 | cresl1n | jkroon: exactly |
| 16:31.33 | cresl1n | sort of :-) |
| 16:31.33 | file | so the question is: can a translator produce multiple frames? |
| 16:31.51 | cresl1n | file: was thinking about that - I'm guessing no right now |
| 16:32.09 | file | well there's a difference between an absolute no and a yes they try |
| 16:32.14 | cresl1n | :-) |
| 16:32.37 | jkroon | ok, so for codecs that consumes fixed blocks of say 10 bytes the incoming frame will just be a multiple of that and we hand back a single frame out again? so in this case, we decode the frame multipe times (some codecs eg g729 carries state), so we have to decode multiple times. |
| 16:32.50 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 16:32.55 | jkroon | file, i'm guessing no. |
| 16:33.27 | file | yeah, I'd say no |
| 16:33.29 | jkroon | single frame in, single frame out? does it matter if the incoming frame carries 20ms worth of audio and the outbound carries longer? |
| 16:33.44 | cresl1n | I don't think it cares |
| 16:33.47 | cresl1n | at this level |
| 16:33.47 | file | it doesn't |
| 16:33.55 | jkroon | isn't PLC normally handled by the final endpoint? |
| 16:34.09 | cresl1n | in this case, the translator is the final endpoint |
| 16:34.14 | cresl1n | if you translate, you have to do PLC there |
| 16:34.49 | jkroon | ok, so normally we try to not transcode/late... but for recording for example chances are good we have to. |
| 16:35.00 | cresl1n | yes |
| 16:35.08 | cresl1n | that's one possibility |
| 16:35.10 | jkroon | but how would a record of a channel that doesn't require translate incorporate PLC? |
| 16:35.47 | jkroon | in other words - is ast_translate the correct place to implement PLC? |
| 16:36.01 | file | that was pondered early on in this, and there's no real good place... |
| 16:36.13 | cresl1n | It's complicated |
| 16:36.27 | cresl1n | PLC should only be done in certain scenarios by asterisk |
| 16:36.32 | cresl1n | if it has to translate |
| 16:36.41 | jkroon | is there a function to concatenate two frames? |
| 16:36.46 | cresl1n | or if it has to terminate to a non-rtp transport |
| 16:37.25 | jkroon | ie, ast_translate_plc ... takes all the same parameters as ast_translate and wraps it, pass consume as false for all but the last frame? |
| 16:37.30 | cresl1n | and if it has to jitterbuffer |
| 16:37.58 | jkroon | chain them and return the list. |
| 16:38.12 | cresl1n | not sure, haven't looked at that code in a while |
| 16:38.49 | cresl1n | I don't have a clear thought as to how or if it should be broken up |
| 16:39.35 | file | nominates cresl1n as the translation core/PLC/Jitterbuffer guy |
| 16:39.38 | jkroon | i'd keep ast_translate separate and rather wrap it. |
| 16:39.44 | seanbright | may god have mercy on his soul |
| 16:40.21 | jkroon | so do the plc (frame duplication) outside of the actual translation and pass in the list linking the results. |
| 16:44.14 | jkroon | then _plc variant is known to return *multiple* "out" frames. and the function is better defined. and then you can stop banging your head: ast_translate_plc(...) { code from 539-566; stopseq = f->seqno; f->seqno -= frames_missing; for ( ; f->seqno <= stopseq; ++f->seqno) { ast_frame n = ast_translate(..., consume && f->seqno == stopseq); ... code to link n onto existing return set; } return list; } |
| 16:46.05 | jkroon | if this has to be transparent to existing callers I'd rename existing function to _single and use above (debugged) for ast_translate, but rather combine the resulting frames into a single frame. you'll just need to figure out the correct sequence numbers and stuff then for that "single frame" |
| 16:49.07 | cresl1n | I think my mind was generally thinking in that direction as well |
| 16:49.15 | jkroon | listen, what happens if we call framein() multiple times and then a single frameout()? |
| 16:49.35 | cresl1n | But I don't know if I'm gonna push for something like that in this patch |
| 16:49.43 | cresl1n | It might depend on the code |
| 16:49.49 | cresl1n | *codec |
| 16:49.53 | jkroon | translator specific? |
| 16:49.58 | cresl1n | I think generally you'll get a big frame back |
| 16:50.08 | jkroon | ok, so doesn't that solve the problem? |
| 16:50.21 | cresl1n | Solve which part? |
| 16:50.40 | jkroon | we push all the duplicated frames onto the first path element, and then get a single frameout() and just iterate that through the rest of the path? |
| 16:51.15 | tzafrir | I'm trying to understand how to use dahdi local dynamic span. |
| 16:51.29 | file | Perhaps the real answer here is to have a discussion on the Dev list about the real path forward and include Alexander |
| 16:51.40 | cresl1n | jkroon: if I understand you correctly, that's essentially what that patch does |
| 16:52.13 | jkroon | cresl1n, no, the patch goes through the whole path for every duplicated frame. let me paste an idea... |
| 16:53.28 | jkroon | eesh, memory leak in the patch. it leaks all the duplicated frames at the very least. |
| 16:53.31 | cresl1n | nevermind |
| 16:53.42 | cresl1n | But also, the translators themselves have limited buffering capacity |
| 16:53.57 | tzafrir | Should it allow me to have a loopback of two PRI (or CAS) spans using two local dynamic spans? |
| 16:54.17 | jkroon | cresl1n, ok, then there goes my idea. |
| 16:54.36 | jkroon | although, PLC for more than a handful of frames at a time is going to be bad anyway. |
| 16:55.25 | cresl1n | that's essentially my position on it |
| 16:56.42 | file | Very bad. |
| 16:57.50 | jkroon | am I correct in saying that (1) ast_free() won't free the whole list, and (2) the frame list is not actually getting freed again? |
| 16:58.38 | cresl1n | jkroon: how do you figure they're being leaked? |
| 16:58.57 | jkroon | cresl1n, there is no free() for them. |
| 16:59.27 | jkroon | ast_frfree is only called on the interim frames *if and only if* they're not coming from the list. |
| 17:00.35 | jkroon | btw, original ast_translate seems to accept multiple incoming frames, and call multiple framein() calls before frameout(). |
| 17:00.43 | cresl1n | yeah |
| 17:01.24 | jkroon | so do we need all the aditional complexity or isn't the original code good enough after pre-pending the missing frames? |
| 17:01.46 | cresl1n | that's what I'm scratching my head on |
| 17:01.50 | jkroon | some logic required to deal with consume == false case to free the newly created frames. |
| 17:02.41 | jkroon | ask the author? |
| 17:03.14 | cresl1n | probably |
| 17:03.53 | jkroon | oh, he's not duplicating frames at all ... he's prepending zero-sized frames! |
| 17:04.25 | cresl1n | yes |
| 17:04.27 | jkroon | datalen = 0 ... but samples = f->samples ... is that even sane? |
| 17:04.31 | file | yes |
| 17:04.53 | cresl1n | it's part of the magic to allow plc to happen |
| 17:04.59 | jkroon | can't one then pre-pend a single frame with datalen = 0 and samples = number_of_missing_samples? |
| 17:05.58 | cresl1n | good question |
| 17:06.12 | rmudgett | The code appending translated frames could be done better. He has to keep finding the last frame in the list. |
| 17:06.25 | jkroon | the new code also *drops* late frames. |
| 17:06.41 | rmudgett | He should just remember what that frame was from the last time through the translation loop. |
| 17:06.43 | jkroon | or "out of order" |
| 17:06.53 | cresl1n | out of order frames will be messed up in translation anyways |
| 17:07.04 | rmudgett | No jitter buffer to deal with late frames. |
| 17:07.09 | cresl1n | that's why you have to do jitterbuffer termination prior to translation |
| 17:07.15 | cresl1n | if you do it at all |
| 17:07.48 | cresl1n | jitterbuffering has to occur before any PLC or translation happen |
| 17:08.03 | cresl1n | okies, gtg run out for lunch |
| 17:08.05 | jkroon | and more importantly, if f is a list of frames (assuming it can be), and that list is not sorted ... |
| 17:08.22 | rmudgett | alaw -- ulaw translation doesn't care about jitter |
| 17:08.30 | cresl1n | yeah |
| 17:08.37 | cresl1n | that's one of the few ones that aren't predictive |
| 17:08.38 | jkroon | but that's about the only case that doesn't :) |
| 17:08.50 | rmudgett | Its the fancy codecs like opus that would care. |
| 17:08.51 | jkroon | slin probably too. |
| 17:09.08 | cresl1n | see you all later |
| 17:10.02 | jkroon | cresl1n, i'd comment on that patch but i'm not confident enough re my knowledge on that to make my comments with certainty. |
| 17:11.43 | *** join/#asterisk-dev swimmercol (~lancelot@87-54-146-198-dynamic.dk.customer.tdc.net) |
| 17:24.29 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 17:24.29 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:28.17 | *** join/#asterisk-dev acidfoo_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 17:44.58 | file | jkroon, thanks for responding! |
| 17:46.13 | jkroon | no problem. i just hope it's accurate. |
| 17:46.35 | file | fake it till you make it |
| 17:46.51 | jkroon | hahaha |
| 17:47.23 | jkroon | well, i'm going to require some help with the test suite thing... so i always reason the best way to get help is to help someone else. |
| 17:47.35 | file | or blackmail |
| 17:47.37 | file | did I say that? |
| 17:47.46 | jkroon | thanks, i'll use that :) |
| 17:59.09 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 17:59.10 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 18:03.21 | scouture | https://issues.asterisk.org/jira/browse/ASTERISK-25888 .. i assume this patch should also make it into the next release candidate for asterisk 11? target release is "13.9.0" and it was already included in 13.9.0-rc1, but no word on 11.x.. |
| 18:03.50 | file | it will |
| 18:04.27 | scouture | great! sorry for taking this here, i couldn't comment on jira as the issue was closed. :) |
| 18:04.37 | file | you can still comment on closed issues ^_^ |
| 18:04.47 | scouture | hrm.. |
| 18:05.27 | scouture | oh. that's embarassing. i wasn't logged in. |
| 18:05.31 | scouture | carry on! ;) |
| 18:06.12 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:06.12 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:19.57 | *** join/#asterisk-dev Deeewayne (~dwayne@c-68-32-120-188.hsd1.al.comcast.net) |
| 18:19.57 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:22.07 | *** join/#asterisk-dev swimmercol (~lancelot@87-54-146-198-dynamic.dk.customer.tdc.net) |
| 18:54.27 | jkroon | when trying to run the test suite I get "astdatadir = ast_config.directories["astdatadir"] or '/var/lib/asterisk'" resulting in KeyError: 'astdatadir' |
| 19:08.12 | jkroon | ok, i'm really strugling with the test suite. Currently just getting the dependencies going ... Dependency: app_confbridge - False |
| 19:08.16 | jkroon | how do I fix that? |
| 19:09.45 | file | Asterisk installed and all that? |
| 19:11.14 | jkroon | jip. |
| 19:11.24 | jkroon | sure i'm just missing something stupid. |
| 19:11.34 | file | and you can run it manually? |
| 19:12.02 | jkroon | yes, in fact, i've got a working installation... |
| 19:12.16 | file | Python 2? |
| 19:13.20 | jkroon | 2.7 to be specific yes. |
| 19:14.02 | jkroon | oh, i fixed the ast_config issue by explicitly adding a astdatadir to asterisk.conf ... it now givees that dependency error. |
| 19:14.18 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:14.19 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:14.43 | file | ponders |
| 19:14.49 | file | any ideas others? |
| 19:14.53 | file | what distro is this? |
| 19:15.48 | jkroon | running on gentoo on that specific machine. |
| 19:16.06 | jkroon | if i need something else I'll have to quickly action a VM but that's not impossible. |
| 19:16.25 | file | I know it works on Ubuntu 14.04 for sure, that's all |
| 19:16.48 | jkroon | ok, let me just find a VM ... then the package manegement is also not an issue. |
| 19:16.50 | file | I'm not sure why it wouldn't be finding the dependencies if they're there |
| 19:18.36 | jkroon | might be that asterisk is incorrectly compiled or something. |
| 19:18.47 | jkroon | anyway, dinner first. |
| 19:20.09 | file | there's no special compiling, it just means some stuff won't run because for example TEST_FRAMEWORK isn't enabled but it shouldn't stop modules from being detected |
| 19:53.05 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 19:53.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:13.28 | cresl1n | jkroon: thanks for the review on that code |
| 20:14.03 | cresl1n | I found out that the PLC code works on a per codec unit size per unit size |
| 20:14.16 | cresl1n | this is in codec_speex and codec_ilbc |
| 20:14.59 | cresl1n | So if he dumped a single frame with # of samples equal to number of frames lost * number of samples per frame, it would only PLC one frame |
| 20:15.10 | cresl1n | hence the reason behind having to string it out into multiple frames |
| 21:33.24 | *** join/#asterisk-dev lnxslck (~lnxslck@av3-84-90-162-98.netvisao.pt) |
| 22:41.16 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-zdytphsnlcrnblib) |
| 23:01.05 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:406e:97c1:317:2263) |