| 00:15.57 | *** part/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 00:16.17 | *** part/#asterisk-dev Jamuel (~Adium@207.86.77.166) |
| 00:31.04 | *** join/#asterisk-dev joshaidan_ (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 00:38.32 | seanbright | russellb: something like that :-) |
| 01:25.36 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:25.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:09.53 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.82.197) |
| 02:09.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:11.05 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-104-242-22.ph.ph.cox.net) |
| 03:32.19 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-104-242-22.ph.ph.cox.net) |
| 04:06.48 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:06.48 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:12.02 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 04:12.02 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 04:18.04 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-vkvscmvksptbxpet) |
| 04:19.42 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-galkxunhwasoahlf) |
| 06:18.16 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 06:59.56 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 06:59.56 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 07:09.48 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 07:18.46 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:18.48 | schmidts | good morning |
| 07:27.08 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 09:11.23 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:11.24 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:14.00 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:bc60:a471:1792:14d) |
| 11:22.16 | schmidts | damn my patch that asterisk will build the right contact even on a provisional response has broke some stuff |
| 11:23.04 | schmidts | i also have this problem with a customer behind a proxy which uses 1.8.9.1 and i can see in the sip debug that asterisk puts the contact header from the 183 into the request uri for the ACK |
| 11:23.22 | schmidts | the record route is used which is received from the 200 ok but the request uri is wrong |
| 11:55.17 | wdoekes2 | schmidts: ASTERISK-19358 part 2? |
| 11:55.57 | wdoekes2 | I was looking into that, but I'm somehow unable to disable NAT here.. |
| 11:56.25 | schmidts | wdoekes2 yes exactly |
| 11:56.27 | wdoekes2 | set_destination: Parsing <sip:1.2.3.4:5;transport=UDP> for address/port to send to |
| 11:56.30 | wdoekes2 | set_destination: set destination to 1.2.3.4:5 |
| 11:56.32 | wdoekes2 | Transmitting (NAT) to 192.168.1.69:5062: |
| 11:57.08 | wdoekes2 | but the problem is apparent anyway.. it sets the R-URI of phone A, while it should use phone B |
| 11:58.13 | wdoekes2 | schmidts: http://fpaste.org/4Grj/ sipp example that should trigger it, and should fail (if I can lose the nat) until it's fixed |
| 12:00.35 | schmidts | i will take a look at it |
| 12:00.39 | schmidts | does it have to be behind nat? |
| 12:02.16 | wdoekes2 | no.. my problem is with asterisk insisting on nat, which makes the test succeed while it shouldn't.. but I'm probably using a bad config option somewhere |
| 12:02.28 | schmidts | ah ok i see |
| 12:03.49 | wdoekes2 | ok.. better.. |
| 12:04.04 | wdoekes2 | nat=never doesn't work in 1.8 anymore |
| 12:04.14 | wdoekes2 | no was the right choice |
| 12:04.57 | wdoekes2 | I'll go see if I can make a test suite test for this |
| 12:12.30 | schmidts | the question is how to fix it |
| 12:13.35 | schmidts | cause this patch is only one solution for a cancel but not for the problem i can see |
| 12:15.01 | wdoekes2 | the cancel problem is unrelated |
| 12:18.51 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 12:19.33 | schmidts | why you mean its not related? its basically the same problem |
| 12:23.04 | *** join/#asterisk-dev irroot (~gregory@41.53.250.117) |
| 12:23.36 | *** part/#asterisk-dev irroot (~gregory@41.53.250.117) |
| 12:24.40 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:24.40 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:26.31 | wdoekes2 | schmidts: the CANCEL is about updating a transaction which hasn't established a dialog yet (send to original address) |
| 12:26.33 | schmidts | wdoekes2 how do you use this sipp scenario? just dial where your sipp script is running? |
| 12:27.29 | schmidts | wdoekes2 yes i know but both of them depend on the behavior how provisional responses are handled |
| 12:27.35 | wdoekes2 | the ACK is about which Contact we should use for a new (end-to-end) transaction |
| 12:28.13 | wdoekes2 | in the CANCEL case, *no* response should be used |
| 12:28.20 | wdoekes2 | in the ACK case the *200* response should be used |
| 12:28.36 | schmidts | yes |
| 12:29.36 | wdoekes2 | usage: sipp -m 1 -sf example.xml -p 5062 |
| 12:30.04 | wdoekes2 | CLI> channel originate SIP/test@127.0.0.1:5062 application Wait 1 |
| 12:30.11 | schmidts | ah ok i see |
| 12:30.16 | wdoekes2 | after you ensure that nat=no |
| 12:33.03 | schmidts | ok maybe thats why its working with my tests :( |
| 12:33.29 | schmidts | btw i cant use the scenario from the pastebin, i get a "no scenario section in xml scenario file" error from sipp |
| 12:36.26 | schmidts | ok found the problem but my sipp version complains about the "timewait" at the end but with replacing this with a pause it works and i was also able to reproduce this bug |
| 12:37.13 | wdoekes2 | yea.. sipp is broken, you need to insert an enter on line 2 |
| 12:37.19 | schmidts | yeah ;) |
| 12:37.40 | wdoekes2 | sorry.. I patched my sipp so I don't have to ;) |
| 12:39.08 | schmidts | ok what i can see in handle_response_invite is that parse_ok_contact will be called and also the build_route but it looks like it uses the wrong values |
| 12:39.58 | wdoekes2 | gotta run, bbl |
| 12:40.11 | schmidts | ok |
| 12:56.23 | schmidts | but there is something else going wrong i think |
| 12:56.55 | *** join/#asterisk-dev irroot (~gregory@41.53.250.117) |
| 12:57.15 | *** part/#asterisk-dev irroot (~gregory@41.53.250.117) |
| 12:57.25 | schmidts | i can see that the fullcontact and okcontact is parsed right from the second ringing and also from the 200 ok |
| 12:59.31 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.153.86) |
| 13:18.15 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:18.15 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:21.11 | schmidts | ok the problem is about the build_route not the parse_contact |
| 13:38.11 | *** join/#asterisk-dev irroot (~gregory@41.53.250.117) |
| 13:38.45 | *** part/#asterisk-dev irroot (~gregory@41.53.250.117) |
| 14:05.48 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-rivltyyhwxgoxgof) |
| 14:07.16 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ocunmlebngdsenuk) |
| 14:07.30 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:12.38 | schmidts | wdoekes2 i have written a patch for this problem and put it on reviewboard: https://reviewboard.asterisk.org/r/1749/ maybe you can take a look at it |
| 14:19.08 | kpfleming | schmidts: wdoekes2: if you guys have a sipp scenario for testing that regression, it should get added to the testsuite |
| 14:20.09 | schmidts | kpfleming wdoekes allready said he will write a testsuite for it |
| 14:31.53 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-wewwslifyvnebhjg) |
| 14:34.05 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-njlatgbroaiijjfs) |
| 14:59.59 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:59.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:09.04 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-htkcwryqzqicimhb) |
| 15:26.34 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:29.45 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:29.45 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:07.48 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:07.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:11.24 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:11.24 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:12.05 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:12.05 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:17.18 | *** join/#asterisk-dev ccesario_ (~ccesario@187.17.166.162) |
| 16:25.49 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:25.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:44.03 | file | kpfleming, do you want to join the realtime taskforce? |
| 16:44.08 | file | ^_^ |
| 16:44.12 | kpfleming | no |
| 16:44.15 | Qwell | We need more taskforces. |
| 16:44.25 | Qwell | I'll lead the taskforce taskforce. |
| 16:44.56 | file | I shall be part of the committee to organize committees for creation of taskforces |
| 16:45.13 | Qwell | Is there a cupcake subcommittee? |
| 16:45.13 | pabelanger | Qwell: a taskforce for sweet tea! |
| 16:45.33 | Qwell | pabelanger: turns out that was an april fools joke by some senator |
| 16:46.32 | kpfleming | turns out most senators are april fools jokes |
| 16:47.53 | pabelanger | burn |
| 16:59.04 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-104-242-22.ph.ph.cox.net) |
| 17:05.31 | russellb | aw, i can't find the old "DTMF task force" pic ... |
| 17:06.17 | file | leifmadsen has a copy |
| 17:06.28 | leifmadsen | no I don't :( |
| 17:06.49 | file | *gasp* |
| 17:07.08 | russellb | it may be lost in time. |
| 17:07.13 | leifmadsen | I tried to find it, but couldn't |
| 17:07.31 | leifmadsen | it's possible damin has a copy somewhere... |
| 17:07.32 | file | leifmadsen, was it on neutrino before the migration? |
| 17:08.09 | leifmadsen | file: hmmm, possible... I don't know if I hosted it there or not |
| 17:08.26 | leifmadsen | neutrino may not have existed or been used during that period of time |
| 17:09.52 | russellb | heh that server is where i thought i had it |
| 17:09.55 | russellb | it's not there though |
| 17:10.14 | russellb | conspiracy to delete all copies probably |
| 17:10.25 | leifmadsen | it was a self destructing image |
| 17:11.17 | file | yeah gone |
| 17:11.21 | file | kpfleming, I blame you |
| 17:11.31 | leifmadsen | should have checked it into a branch somewhere |
| 17:12.40 | file | got it |
| 17:12.44 | file | http://www.flickr.com/photos/26461607@N02/2482119372/ |
| 17:13.01 | leifmadsen | WOAH |
| 17:13.11 | leifmadsen | nice moves file |
| 17:13.31 | leifmadsen | I have no idae who CCFL_Mang is |
| 17:13.52 | leifmadsen | that picture was taken at San Jose 2008 I think... |
| 17:13.57 | file | 2006 |
| 17:13.58 | leifmadsen | 2008? 2006... ? |
| 17:14.24 | kpfleming | 1994 |
| 17:15.03 | russellb | good times |
| 17:15.31 | russellb | oh vldtmf ... |
| 17:16.41 | russellb | why must people use their nick to indicate status :( drives me crazy |
| 17:17.12 | leifmadsen | that ^^ |
| 17:17.32 | leifmadsen | my client tells me if you're marked away with an indicator |
| 17:17.59 | leifmadsen | file: picture put back into my photo stream so we don't lose it again |
| 17:18.51 | leifmadsen | http://farm8.staticflickr.com/7066/6887097487_93159517cf_z.jpg fyi |
| 17:18.54 | leifmadsen | and now I lunch |
| 17:20.51 | serafie | omg... |
| 17:20.57 | serafie | haha |
| 17:21.24 | acidfoo | lol |
| 17:21.48 | russellb | it's a classic piece of asterisk history |
| 17:22.06 | Qwell | it inspired a generation |
| 17:25.44 | serafie | How old is this? I cannot believe I haven't seen this. You guys have been remiss. |
| 17:26.01 | file | 6 years, we think? |
| 17:26.10 | file | no, 5 |
| 17:30.00 | seanbright | sruffell: morning, sir. |
| 17:30.15 | sruffell | oh no |
| 17:30.20 | seanbright | heh |
| 17:30.52 | seanbright | i'll make this quick - i will try my best to actually submit a jira issue, but i make no promises... |
| 17:31.16 | seanbright | i don't think this is a dahdi issue, i think it's an asterisk issue. but i wanted to bring it to your attention regardless. |
| 17:31.58 | seanbright | i have the following setup in a lab environment: |
| 17:33.47 | seanbright | Polycom <-> SIP/RTP g729 <-> [Box A - Asterisk 1.8 svn / DAHDI 2.6.0] <-> IAX2 trunking g729 <-> [Box B - Asterisk 1.8 svn / DAHDI 2.6.0] <-> SIP/RTP g729 <-> Polycom |
| 17:34.10 | seanbright | wctc400p in Box A |
| 17:34.40 | seanbright | the IAX2 trunk is going over a secondary NIC in each machine with a crossover cable (virtually no latency) |
| 17:35.06 | seanbright | that works... for the most part. occasional complaints about audio quality, but nothing earth shattering. |
| 17:35.53 | kpfleming | wait... if it's all G.729, why does the transcoder card get involved? |
| 17:36.02 | seanbright | i'm getting there |
| 17:36.12 | file | get there faster! |
| 17:36.13 | seanbright | it's a journey, not a destination, kpfleming |
| 17:36.24 | kpfleming | i'm smellin' the roses! |
| 17:36.25 | file | you sound like an airline |
| 17:36.46 | kpfleming | russellb: ha! |
| 17:37.03 | seanbright | this is where things get wonky - you make a call (tech doesn't matter) to Box A and chanspy on the IAX2 channel |
| 17:37.07 | russellb | :-D |
| 17:37.09 | seanbright | audio coming from Box B sounds awful |
| 17:37.31 | sruffell | only when you chanspy it? |
| 17:37.45 | seanbright | and in some cases (this is anecdotal) affects what the people on either end of the spied on channel hear |
| 17:38.00 | seanbright | i believe that meetme is also affected, but i have yet to test |
| 17:38.04 | seanbright | NOW... |
| 17:38.17 | seanbright | turn off IAX2 trunking? problem goes away |
| 17:38.35 | seanbright | that's not an option for me... so |
| 17:39.01 | seanbright | i took wctc4xxp/base.c in 2.6.0 and reverted all of the changes from r9034 |
| 17:39.18 | seanbright | the "Allow read to return more than one packet of data." |
| 17:39.25 | seanbright | problem goes away |
| 17:39.38 | kpfleming | interesting |
| 17:40.30 | seanbright | my problem is this... i don't know if the problem is audio hooks, or iax2 trunking where the trunk frames have media frames of differing size samples, or codec_dahdi |
| 17:40.42 | kpfleming | i assume you have confirmed that the polycom endpoints are *not* sending G.729 SID or RTP CN frames |
| 17:41.04 | seanbright | kpfleming: i have not confirmed that. |
| 17:41.10 | kpfleming | seanbright: do you have a licenses for the software g.729 codec to use to compare results? |
| 17:41.28 | seanbright | kpfleming: i do |
| 17:41.47 | seanbright | let me do that for you |
| 17:41.51 | seanbright | or for me... i guess |
| 17:41.55 | kpfleming | that would be a useful data point as well |
| 17:42.10 | kpfleming | i am about to head to lunch but will be back in the next couple of hours |
| 17:44.05 | seanbright | i don't think it is a problem with the card, only because disabling trunking makes the symptoms disappear |
| 17:44.06 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 17:44.09 | seanbright | but i'm willing to test |
| 17:44.13 | kpfleming | right |
| 17:44.36 | kpfleming | but it *could* be, in some bizarre combination where the problem is only exposed if trunking is also used |
| 17:44.54 | kpfleming | what timing module are you using on those systems? |
| 17:45.30 | *** join/#asterisk-dev Jamuel (~Adium@c-67-180-156-186.hsd1.ca.comcast.net) |
| 17:46.33 | seanbright | res_timing_dahdi |
| 17:46.54 | seanbright | in my test environment there is only a card in Box A |
| 17:46.57 | kpfleming | and then DAHDI core timing.. ok |
| 17:46.59 | seanbright | right |
| 17:47.19 | kpfleming | any virtualization stuff in the picture here? |
| 17:48.03 | seanbright | none |
| 17:48.08 | seanbright | both physical machines |
| 17:48.13 | kpfleming | ok, just making sure |
| 17:48.26 | seanbright | oh - jitterbuffer also makes the problem go away |
| 17:48.33 | seanbright | well... for the most part |
| 17:48.37 | seanbright | 95% improvement |
| 17:48.58 | seanbright | but again, there is no significant latency variation |
| 17:49.44 | seanbright | separate bug report: benchg279 - the first generic g729 test always seems to take a long time compared to the next 4 |
| 17:50.25 | seanbright | 350, 280, 270, 270, 270 |
| 17:50.40 | seanbright | it's like there isn't an adequate warm-up period |
| 17:50.42 | seanbright | but i digress |
| 17:55.07 | seanbright | kpfleming: things seem peachy using the software codec |
| 17:56.13 | seanbright | it's not really an apples to apples comparison though, since dahdi r9034 introduces the possibility of asterisk getting back more than a single 20ms sample |
| 17:56.46 | seanbright | i haven't tested (and i obviously can't see to the code to see), but i would guess that codec_g729a only ever feeds back 20ms frames to asterisk |
| 17:56.53 | sruffell | hmm. |
| 17:57.27 | seanbright | so it's a perfect storm of the transcoder card, dahdi linux > 2.3.0.1, iax2 trunking, and audiohooks |
| 17:57.31 | seanbright | very easy to debug |
| 17:57.32 | seanbright | :-) |
| 17:58.35 | sruffell | kpfleming: How hard do you think it would be to have codec_dahdi return a list of frames? Do you think that would be pretty easy for me….or something that could take some time? |
| 18:02.02 | seanbright | that almost seems like a band aid to me |
| 18:02.13 | seanbright | i mean... it shouldn't matter how big the frames are, right? |
| 18:02.30 | sruffell | well..at least it would make sure all the packets coming out of codec_dahdi are the same size….without falling behind. |
| 18:02.38 | sruffell | that's my understanding...true... |
| 18:03.09 | seanbright | like i said, rolling back the change to the driver makes things better for me, without really hurting anything |
| 18:03.15 | sruffell | but if all you did was prevent that from happening by removing 9034… |
| 18:03.16 | sruffell | http://svnview.digium.com/svn/dahdi?view=revision&revision=9034 |
| 18:03.41 | seanbright | that too was a band aid |
| 18:03.42 | sruffell | so now..I bet over long calls…a delay will grow.... |
| 18:04.30 | seanbright | your commit message indicated that it would affect g723 -> g729 |
| 18:04.34 | seanbright | do you think it would affect g729 -> slin and back as well? |
| 18:04.59 | sruffell | yes..because those are different size packets…but if you're getting some of these "multiple packets" then your delay will grow too…..everytime there is more than one packet to read…and it's not being returned….. |
| 18:05.22 | seanbright | but the card is what is generating the "multiple packets" |
| 18:05.28 | seanbright | the driver, rather. |
| 18:05.42 | seanbright | let me rephrase |
| 18:05.44 | sruffell | yes…but it could be because asterisk isn't checking quick enough… |
| 18:06.21 | seanbright | in my testing - without r9304 - i only ever see 20ms (20 byte) g729 frames |
| 18:06.32 | sruffell | so the driver is just queing them up in a buffer as they come in from the interrupt handler. If asterisk sends three packets to be transcoded…goes off in lalla land for 100ms…then next time it reads, there will be 60ms of audio to consume. |
| 18:07.00 | seanbright | well then the bug is in asterisk |
| 18:07.12 | seanbright | be it codec_dahdi or elsewhere |
| 18:07.12 | sruffell | right…I bet over a long period of time…the delay from the speaker to the listener will keep getting bumped up by 20ms everytime there were multiple packets to read that weren't read. |
| 18:07.41 | sruffell | do you know why the audio is bad? missing audio? Just the other end doesn't like the packet sizes shifting, or ...? |
| 18:08.01 | seanbright | from my testing, i've only heard the spier hearing bad audio |
| 18:08.19 | seanbright | the parties being spied on don't appear to be affected |
| 18:08.41 | sruffell | is the spier getting more of these 40ms packets? |
| 18:08.42 | seanbright | which is why i reluctantly point the finger at audiohooks (and file, by extension) |
| 18:09.24 | seanbright | i haven't captured those packets... will do so now. but i need to roll back to vanilla 2.6.0 to do that... give me a few. |
| 18:10.03 | seanbright | sruffell: should i include the "res * 8" change in codec_dahdi for my tests? |
| 18:10.09 | seanbright | or just use 2.6.0 proper |
| 18:10.15 | seanbright | or SVN for that matter |
| 18:12.41 | seanbright | i feel like the res * 8 change was the right change, so i'll test with that |
| 18:14.17 | sruffell | yes..I still need to open an issue for that (or if you want to). I asked mjordan, and I can't change the reporter on those issues….so it would be better if you could open one. (but I'll see if I can get that permission in the future since you did all the legwork, the least I can do is open the issue for you). |
| 18:15.05 | seanbright | no, the least i can do for you is open the bug report... you've got enough on your plate |
| 18:15.10 | seanbright | quick question about that change though |
| 18:15.22 | seanbright | that change went into dahdi_encoder_frameout |
| 18:15.33 | seanbright | should a symetrical change go into dahdi_decoder_frameout? |
| 18:18.05 | sruffell | decoder frameout already sets samples to the value of res now. |
| 18:18.14 | sruffell | so….should already be covered. |
| 18:18.26 | seanbright | but the res * 8 change was for datalen |
| 18:19.05 | sruffell | it should have been for f.samples |
| 18:19.06 | sruffell | ? |
| 18:19.26 | sruffell | "pvt->f.samples = dahdip->required_samples;" -> "pvt->f.samples = res * 8" |
| 18:19.29 | sruffell | (for G729 only) |
| 18:19.43 | seanbright | oh, duh, you're right |
| 18:19.55 | seanbright | this is what i have: |
| 18:19.56 | seanbright | http://pastebin.com/raw.php?i=0pLtL2k1 |
| 18:20.21 | sruffell | yes…that's what I was expecting |
| 18:21.18 | seanbright | so we're clear - i just misspoke here, i had tested with the change to pvt->f.samples |
| 18:21.43 | seanbright | ok, so i'm going to test with that change to asterisk 1.8 svn and with 2.6.0 vanilla |
| 18:21.54 | sruffell | kk |
| 18:24.03 | seanbright | what is a good file drop site? |
| 18:24.22 | seanbright | i want to post a sample of the audio for the spier |
| 18:29.04 | seanbright | sruffell: http://seanbright.com/bad-audio-sample.wav |
| 18:30.07 | seanbright | "outbound" is playing on Box A, the shitty sounding audio is playing on Box B |
| 18:31.14 | seanbright | working on a packet capture now |
| 18:37.46 | seanbright | sruffell: all of the packets going to the spier have the same payload size |
| 18:38.05 | seanbright | oh... wait... i might be lying |
| 18:39.57 | seanbright | well, the payload size is the same for each rtp packet, but my first test was with ulaw, generating it again with the spier using g729 (although that is irrelevant i believe because audiohooks have to transcode to slin first anyway) |
| 18:45.47 | seanbright | sruffell: spier is getting 20 bytes per packet - the rtp timestamp appears to be 160 higher each time, although i don't know the units for that |
| 18:46.55 | sruffell | that looks right |
| 18:46.55 | seanbright | but the packets are consistently 20 bytes, no variation that i am seeing |
| 18:47.01 | sruffell | hmm.. |
| 18:47.09 | sruffell | so then what does the spier hear bad audio... |
| 18:47.18 | sruffell | s/what/why/ |
| 18:47.53 | seanbright | because asterisk is not doing something right when it mixes the audio |
| 18:47.59 | seanbright | or audiohooks are taking too long |
| 18:48.04 | seanbright | or something |
| 18:48.53 | seanbright | so to spy: the frames on both sides of the channel have to be transcoded to slinear, then mixed, and then transcoded back to g729 to be sent to the spier |
| 18:49.31 | seanbright | and since my first test (accidentally) used g711 and shows the same issue, it's not an issue of transcoding back into g729 |
| 18:49.50 | seanbright | so decoding the g729 packets from the iax2 trunk and mixing them is the problem - i just don't know how to fix it |
| 18:49.54 | seanbright | as usual :-) |
| 18:54.09 | seanbright | so a mixmonitor instead of a chanspy should show the same artifacts |
| 18:59.30 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 19:00.24 | seanbright | although - since iax without trunking doesn't appear to have the same problem - maybe the code that pulls frames from the trunk packets in chan_iax2 is the issue |
| 19:00.40 | seanbright | let me try with RTP between the 2 boxes |
| 19:04.51 | kpfleming | sruffell: changing codec_dahdi to be able to return a list of frames would be fairly straightforward on the Asterisk API side. i have no idea what would be necessary on the DAHDI API side. |
| 19:05.25 | kpfleming | seanbright: you can have keep in mind that IAX2 trunking imposes some very, very strict requirements on the timing of the audio streams |
| 19:06.06 | kpfleming | an IAX2 trunk configured with a 20ms 'trunk time' transmits exactly one frame every 20ms. if the incoming audio for one of the trunked calls did not arrive in time, it will not be included in the frame, and will be delayed into the next one. |
| 19:06.23 | sruffell | I don't think we would need any change on the DAHDI api side…just do the read like we are…and instead of returning on packet that can be different sizes depending on how much data returned…codec_dahdi could just break it up into multiple frames? But…maybe that's not really the solution..? |
| 19:07.18 | kpfleming | i'd really like to know if switching to the software g.729 codec changes the symptoms |
| 19:07.48 | sruffell | he said it resolved the problem I believe. |
| 19:07.55 | kpfleming | interesting |
| 19:08.50 | seanbright | correct |
| 19:09.14 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 19:09.14 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 19:09.19 | seanbright | i've seen some interesting things with iax2 packet traces |
| 19:09.53 | seanbright | in some cases, a single trunk frame carries multiple media mini frames for the same call |
| 19:10.17 | seanbright | and in some of those cases, 1 of them is 20ms while the other is 40ms |
| 19:10.20 | kpfleming | ahh.. i had forgotten about that |
| 19:10.44 | kpfleming | so the media doesn't get 'behind', but multiple frames arrive at once |
| 19:10.51 | seanbright | right |
| 19:11.33 | seanbright | so i just switched to SIP instead of IAX between the two boxes and the issue does not present itself |
| 19:11.56 | seanbright | so the finger should be pointing squarely at trunking at this point? |
| 19:12.04 | kpfleming | right, for the same reason that turning off IAX2 trunking fixes it |
| 19:12.16 | kpfleming | but the trunking is not the cause |
| 19:12.36 | kpfleming | trunking just has a behavior which, while perfectly acceptable, causes other parts of the process to break |
| 19:13.08 | seanbright | so this is not fixable? |
| 19:13.23 | kpfleming | i wouldn't say that |
| 19:13.38 | kpfleming | it's just not trivial |
| 19:13.55 | file | seanbright, get to work. |
| 19:14.00 | seanbright | file: yeah... god damnit |
| 19:14.19 | kpfleming | if a bunch of us got together in a room for a day with a test setup i'm sure we could resolve it |
| 19:14.40 | seanbright | but... :-) |
| 19:14.41 | seanbright | ok |
| 19:14.55 | file | preferably somewhere nice |
| 19:15.06 | kpfleming | iceland |
| 19:15.40 | seanbright | would buying commercial support expedite this? |
| 19:16.03 | seanbright | and could i demand that file be the one supplying said support? |
| 19:16.15 | kpfleming | no |
| 19:16.15 | file | you don't want me. |
| 19:16.20 | seanbright | damn |
| 19:16.21 | sruffell | kpfleming: so even if codec_dahdi returned a bunch of packets…trunking still wouldn't like getting that much data in one shot? |
| 19:16.32 | kpfleming | well, not quite |
| 19:16.35 | seanbright | kpfleming: which question was that 'no' to? |
| 19:16.44 | kpfleming | seanbright: both |
| 19:16.51 | seanbright | alrighty |
| 19:17.08 | kpfleming | sruffell: the output of codec_dahdi is not heading into iax2 trunking in his situation |
| 19:17.15 | kpfleming | the input of codec_dahdi is *coming* from iax2 trunk |
| 19:17.27 | sruffell | hmm |
| 19:17.55 | kpfleming | so codec_dahdi is receiving variably-sized frames of g729, turning them into slinear |
| 19:19.02 | kpfleming | when these variably sized frames are just passed across the bridge in asterisk and sent back out as RTP, they get repacketized into 20ms frames i suspect |
| 19:19.38 | kpfleming | but audiohooks don't do anything like that... chanspy attempts to 'balance' the incoming audio from the two legs it is spying on |
| 19:21.22 | seanbright | but audiohooks doesn't care about trunking, and the packets are varying size regardless |
| 19:21.32 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 19:21.48 | kpfleming | that's correct |
| 19:21.58 | kpfleming | audiohooks aren't actually the problem here either, i suspect |
| 19:22.35 | seanbright | it's how the mini frames are being unwrapped passed into the core |
| 19:22.45 | kpfleming | seanbright: can you see what chan_iax2 does when it receives two mini frames for the same call in one trunk frame? |
| 19:22.46 | seanbright | and the timing of that process |
| 19:23.38 | file | it's all about timing, just like in music |
| 19:23.50 | seanbright | kpfleming: in code you mean? |
| 19:24.43 | kpfleming | yep |
| 19:25.03 | seanbright | sure |
| 19:25.22 | kpfleming | i bet it just calls ast_queue_frame() for each one |
| 19:30.47 | seanbright | that is correct |
| 19:31.10 | seanbright | although it appears to collect and pass around the timestamp, but i don't see where it actually delays any delivery |
| 19:31.35 | kpfleming | ok |
| 19:31.45 | kpfleming | yes, it does attempt to preserve timestamps |
| 19:31.59 | kpfleming | so this is why when the packets are sent back out unmolested, they can be handled by a downstream jitter buffer |
| 19:33.46 | kpfleming | so ast_read() is going to get called twice on that channel in rapid succession, and each time a frame will be processed through the audiohook on that channel |
| 19:34.07 | kpfleming | the resulting slinear frames will be 'queued' somewhere for chanspy to mix them together |
| 19:34.16 | kpfleming | oh wait... unless this is using the 'mixing' style audiohook |
| 19:34.25 | kpfleming | it probably is |
| 19:35.35 | seanbright | i believe that it is, yes. |
| 19:36.11 | kpfleming | ok, so the audiohook gets a second frame of slinear for this channel long before it gets the second frame from the SIP/RTP channel... it's supposed to hold onto it until that other frame arrives. |
| 19:37.03 | kpfleming | i bet if you change your configuration to use SIP/RTP between the Asterisk servers, and force 40ms packetization on that leg, you'll have a very similar problem |
| 19:37.16 | seanbright | so i should change trunkfreq to 10ms, i'm good to go |
| 19:37.19 | seanbright | heh |
| 19:37.30 | kpfleming | you could, at some cost, of course |
| 19:37.33 | seanbright | sure |
| 19:37.47 | kpfleming | or if you changed it to 40ms, you would probably make the problem much worse |
| 19:38.33 | seanbright | can one change the packetization without changing rest_rtp_asterisk? |
| 19:39.37 | kpfleming | yes, allow=g729:40 |
| 19:40.35 | seanbright | and just on the inter-asterisk leg? |
| 19:40.50 | kpfleming | yep |
| 19:41.00 | kpfleming | so the two asterisks will be re-packetizing the audio |
| 19:42.10 | seanbright | no issue |
| 19:42.40 | kpfleming | odd |
| 19:43.35 | seanbright | if there were a way to send some 20ms and some 40ms, it would probably occur again |
| 19:43.59 | kpfleming | well, it should have been a problem there, as the audiohook is receiving 20ms from one side and 40ms from the other |
| 19:46.38 | seanbright | http://seanbright.com/rtp-40ms.wav |
| 19:46.45 | seanbright | that's what the spier heard |
| 19:47.26 | seanbright | i'm hearing a couple pops when i play it back, but i didn't hear it on the live call (and the soft phone did the recording) |
| 19:49.11 | kpfleming | so it's probably not the 40ms frames causing the problem, but two 20ms frames in rapid succession |
| 19:49.31 | seanbright | kpfleming: so is something broken in your opinion? and if so, what? |
| 19:49.41 | seanbright | what should i be trying to 'fix' |
| 19:49.42 | kpfleming | well, it's really hard to say. |
| 19:50.02 | kpfleming | you are using a softphone for spying? |
| 19:50.12 | seanbright | in my test environment, yes. |
| 19:50.14 | seanbright | bria |
| 19:50.20 | kpfleming | does it support slin8 for audio? |
| 19:51.11 | kpfleming | if so, i'd do a test of the failing configuration, but using slin8 for the spying channel, just to rule out any encoding processes on the spying channel being involved |
| 19:51.18 | kpfleming | the more we can simplify, the better |
| 19:51.33 | seanbright | the best i can do is ulaw |
| 19:51.41 | kpfleming | blargh |
| 19:52.19 | seanbright | i could do a mixmonitor |
| 19:52.26 | seanbright | save as slin |
| 19:52.36 | seanbright | should see the same issue, since it uses the same hooks |
| 19:52.39 | seanbright | i think |
| 19:54.10 | kpfleming | it does |
| 19:55.59 | kpfleming | off to a meeting... bbiab |
| 19:56.18 | seanbright | kpfleming: same issue |
| 19:58.28 | seanbright | so no transcoding after the mix, still choppy. i can post the recording somewhere if you lie. |
| 19:58.31 | seanbright | like* |
| 20:11.35 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 20:23.14 | *** join/#asterisk-dev Jamuel (~Adium@adsl-99-118-123-118.dsl.pltn13.sbcglobal.net) |
| 20:33.11 | kpfleming | seanbright: no, but that's a useful data point, thanks |
| 20:41.24 | seanbright | sure |
| 20:41.39 | seanbright | i'm testing trunkfreq=10 right now |
| 20:42.41 | seanbright | sucks less, but still sucks |
| 20:56.13 | seanbright | kpfleming: so short of asking you to fix it for me, do you have any pointers as to where i should start? |
| 20:56.33 | kpfleming | not at the moment, but i'm also deep in another project |
| 20:56.42 | seanbright | fair enough |
| 20:57.09 | kpfleming | but personally i would start by adding log messages to track all the frames entering and exiting the audiohook, and even when they are pulled from the queues in the audiohook to be mixed |
| 20:57.24 | kpfleming | that will generate a ton of messages, but would also provide a lot of clues |
| 20:58.04 | leifmadsen | it will also provide a lot of alot's |
| 20:58.24 | seanbright | sounds good to me, thanks for your help with this |
| 20:59.55 | *** join/#asterisk-dev Jamuel (~Adium@adsl-99-118-123-118.dsl.pltn13.sbcglobal.net) |
| 21:14.11 | *** join/#asterisk-dev elguero_ (41d63835@gateway/web/freenode/ip.65.214.56.53) |
| 21:27.37 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:27.38 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 21:28.58 | pabelanger | Heh, app_rpt.c |
| 21:29.01 | pabelanger | needs some love |
| 21:30.37 | leifmadsen | pabelanger: has for a while |
| 21:30.56 | Qwell | s/ while/lways/ |
| 21:31.01 | leifmadsen | pabelanger: I'm not even sure it compiles |
| 21:31.02 | pabelanger | yar, it doesn't even compile under trunk |
| 21:31.11 | leifmadsen | ya, hasn't done that for a few years |
| 21:31.18 | pabelanger | so, why do we still have it? |
| 21:31.27 | leifmadsen | politics? |
| 21:31.32 | leifmadsen | not sure to be honest |
| 21:54.50 | pabelanger | leifmadsen: well, fixed the compile issue :) |
| 21:56.04 | kpfleming | we changed our policy to say that we don't remove stuff any longer... so we haven't removed it. |
| 21:56.15 | kpfleming | it doesn't build by default, so it doesn't affect anyone unless they enable it. |
| 21:58.15 | pabelanger | which I did to test some packaging stuff :) |
| 21:58.22 | pabelanger | no worries, easy fix |
| 22:00.59 | pabelanger | channel opaquification FTW |
| 22:03.18 | seanbright | ok, so i've done some more tweaking... every g729 sample getting sent across my trunk is 20bytes |
| 22:03.25 | citywok | does anybody use t38/fax? how well does it work for you? |
| 22:03.34 | seanbright | no more magic 40 byte payloads |
| 22:03.39 | seanbright | and the issue persists |
| 22:03.46 | citywok | bah wrong channel haha |
| 22:03.47 | kpfleming | that's no fun |
| 22:04.34 | seanbright | but there are still multiple mini frames for the same call |
| 22:04.51 | seanbright | so that is ultimately the problem i guess |
| 22:05.00 | kpfleming | sounds that way |
| 22:05.06 | seanbright | or problematic, i should say |
| 22:05.09 | seanbright | ok |
| 22:05.17 | kpfleming | right, it exposes some problem in the audiohooks code |
| 22:05.24 | seanbright | indeed. |
| 22:05.44 | seanbright | http://pastebin.com/raw.php?i=iHSR0dth |
| 22:05.49 | seanbright | the logging begins :-) |
| 22:06.09 | kpfleming | yep... been there, done that, when debugging audiohooks problems a long, long time ago |
| 22:06.50 | seanbright | i have an incredible amount of respect for you that understand this sthi |
| 22:06.56 | seanbright | that was a fortunate typo |
| 22:07.06 | kpfleming | lol |
| 22:07.23 | kpfleming | hey, when you work on it 50+ hours per week, you tend to learn how it works |
| 22:07.30 | kpfleming | although it's been a couple of years since i worked on audiohooks stuff |
| 22:07.41 | kpfleming | but since none of the other asterisk team developers are jumping in here... |
| 22:08.17 | kpfleming | plus it helps to relieve my boredom of auditing software licenses |
| 22:08.43 | seanbright | heh |
| 22:09.43 | seanbright | i wonder if a hacky way to resolve this would be to keep track of which calls have media queued up ready to be trunked and just defer extra ones until the next go around |
| 22:10.02 | kpfleming | well, if you do that, you'll end up delaying the audio of the call |
| 22:10.24 | seanbright | i wish that made sense to me |
| 22:10.48 | seanbright | audio is packetized in 20ms chunks |
| 22:10.57 | seanbright | iax2 trunks the media in 20ms chunks |
| 22:10.57 | kpfleming | i'll try to explain: let's say you have two calls up. at time interval one, both calls have a single frame waiting. that's easy... send them both. |
| 22:11.21 | kpfleming | at time interval two, you've got media for the first call, but not the second one. you send a trunk frame with audio for call #1. |
| 22:11.23 | kpfleming | with me so far? |
| 22:11.36 | seanbright | how it's even possible to have more than 1 (even 3 sometimes) 20ms sample in a packet sent every 20ms... bah |
| 22:11.39 | seanbright | let me read |
| 22:11.54 | seanbright | ok, caught up, go ahead |
| 22:12.31 | kpfleming | at time interval three, you've got media for the first call again, but now you have *two* media frames for the second call, because the middle frame arrived just a bit late, and the third frame arrived on time. |
| 22:12.53 | kpfleming | if you send a trunk frame with only packet #2 for call #2, and delay packet #3 by 20ms, then packet #3 will arrive at least 20ms late. |
| 22:13.09 | seanbright | and the effect cascades |
| 22:13.13 | kpfleming | now granted. packet #2 for call #2 is already going to arrive nearly 20ms late. |
| 22:13.18 | seanbright | unless you drop packets |
| 22:13.20 | kpfleming | but yes.. increasing delay. |
| 22:13.21 | kpfleming | right |
| 22:13.39 | kpfleming | eventually, all these packets are supposed to arrive at a decent jitter buffer, which will sort out the problems. |
| 22:13.49 | kpfleming | but in the case of an audiohook, there is no true jitter buffer. |
| 22:14.13 | seanbright | which is what i have never understood, because if it takes you longer than 20ms to collect audio from a microphone and package it in an rtp frame as g729, you will forever be behind |
| 22:14.30 | kpfleming | it's not the collection... it's transmission across the network. |
| 22:15.12 | kpfleming | CPU schedulers starting processes late, interrupts taking too long to process... lots of things can cause packets to be sent late (even though they were prepared on time), or to be picked up late from receiving sockets. |
| 22:15.24 | kpfleming | and of course network delays can be variable, if there are routers in the path. |
| 22:15.26 | seanbright | well enabling the iax jb mitigates most of the problems, itnerestingly enough |
| 22:15.49 | kpfleming | right... putting a jitter buffer in the path prior to the audio getting to the audiohook will help a lot. |
| 22:16.00 | seanbright | but that feels like a hack |
| 22:16.21 | seanbright | since the delay variation between packets is virtually nil |
| 22:16.23 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 22:16.43 | kpfleming | this is an area in asterisk that still needs work. all *consumers* of media frames need to be able to dejitter/reorder/etc. before they consume the media. |
| 22:19.42 | seanbright | because when the channels are bridged it's up to the endpoints to handle all of that |
| 22:19.45 | seanbright | ? |
| 22:19.51 | kpfleming | yep |
| 22:20.03 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 22:20.24 | kpfleming | this is why dvossel adding func_jitterbuffer in Asterisk 10 was so useful... you can put a jb in front of an application that is going to consume the media |
| 22:20.53 | seanbright | upgrades to asterisk 10 |
| 22:23.07 | russellb | would be easy to backport to 1.8 i think |
| 22:23.22 | kpfleming | yep |
| 22:23.31 | kpfleming | it may just drop in |
| 22:23.38 | seanbright | well turning on jitterbuffer in iax2 is easy too |
| 22:23.47 | seanbright | of course then it will be on for the duration of the call |
| 22:24.25 | russellb | assuming the iax2 jb still works properly :-/ |
| 22:24.35 | seanbright | some hack wrote that |
| 22:24.41 | seanbright | :P |
| 22:24.46 | russellb | looks around |
| 22:24.47 | russellb | it wasn't me .. |
| 22:25.04 | russellb | stevek IIRC |
| 22:25.30 | kpfleming | yep |
| 22:25.34 | seanbright | i thought you wrote the jb... my mistake |
| 22:26.14 | russellb | i'm sure i've made changes, but i didn't write it |
| 22:26.14 | seanbright | gotcha |
| 22:26.22 | seanbright | who wrote the adaptive jb? |
| 22:26.31 | kpfleming | stevek |
| 22:26.35 | seanbright | ah |
| 22:26.54 | russellb | you may want to try the fixed jb if you have trouble with that one |
| 22:27.10 | russellb | i've heard reports of weirdness with adaptive |
| 22:28.02 | seanbright | so basically... to 'fix' this particular issue... throw a jb at it, or make audiohooks kinda-sorta do the same thing? |
| 22:28.08 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-104-242-22.ph.ph.cox.net) |
| 22:28.48 | kpfleming | ideally? audiohooks should internally have jitter buffers on their read paths from the channels they are attached to |
| 22:29.12 | seanbright | got it |
| 22:30.46 | russellb | chanspy? |
| 22:30.54 | kpfleming | que? |
| 22:31.19 | russellb | what's the audiohook user in use that triggered this conversation |
| 22:31.25 | kpfleming | yes, chanspy |
| 22:31.26 | seanbright | chanspy |
| 22:31.32 | seanbright | although mixmonitor is also affected |
| 22:31.34 | russellb | k, just curious. |
| 22:31.49 | russellb | well, mixmonitor shouldn't be affected by jitter as much ... |
| 22:32.03 | seanbright | why's that? |
| 22:32.05 | russellb | should just write out to disk whenever stuff arrives |
| 22:32.08 | kpfleming | yes, it's the mixing of the two audio streams |
| 22:32.25 | russellb | it's not as real-time sensitive |
| 22:32.38 | kpfleming | true |
| 22:32.48 | kpfleming | the *file* does not need audio every 20ms :-) |
| 22:32.55 | russellb | stuff could get help up for a second, but you wouldn't notice that in the recording |
| 22:32.58 | russellb | right |
| 22:33.26 | seanbright | i have a mixmonitor recording that sucks if you would like to hear it :-) |
| 22:33.32 | russellb | heh |
| 22:33.35 | russellb | well then |
| 22:33.49 | seanbright | i didn't notice a difference between the audio from the chanspy and the audio from the mixmonitor |
| 22:33.52 | mjordan | russellb: nice update of the wiki |
| 22:33.53 | russellb | i may be missing a key aspect of how mixmonitor works, perhaps |
| 22:33.56 | russellb | mjordan: shh! |
| 22:34.18 | russellb | maybe it writes out silence if it doesn't have a frame in time? *shrugs* |
| 22:34.55 | seanbright | man i don't know |
| 22:35.00 | seanbright | i'm all turned around in circles |
| 22:35.23 | russellb | offers seanbright a beer |
| 22:35.27 | seanbright | meh |
| 22:35.33 | seanbright | coffee would be great though |
| 22:37.01 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 22:37.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:44.31 | seanbright | audiohooks by their design hold up the audio going to and from a channel |
| 22:45.08 | seanbright | so if you have a slow audio hook, then that could affect the quality of the audio on the channel, even if you're just passively monitoring the audio |
| 22:45.21 | seanbright | does that sound right? |
| 22:45.34 | kpfleming | to some extent, yes |
| 22:45.59 | kpfleming | because in many cases they are used to manipulate the audio |
| 22:48.57 | seanbright | so if i just need to siphon audio off and not manipulate it, i could delegate most of that to a worker thread |
| 22:49.10 | kpfleming | correct |
| 22:49.16 | seanbright | interesting. |
| 22:49.40 | russellb | MOAR THREADS! |
| 22:51.32 | seanbright | well thanks for all of the feedback and advice today |
| 22:51.45 | *** join/#asterisk-dev Jamuel (~Adium@c-67-180-156-186.hsd1.ca.comcast.net) |
| 22:52.45 | sruffell | seanbright: so I see you're still here…besides getting the samples right on large packets, was there anything else I need to do? |
| 22:52.58 | sruffell | didn't read all I missed |
| 22:53.16 | seanbright | sruffell: honestly... i'm not sure |
| 22:53.16 | seanbright | heh |
| 22:53.30 | seanbright | i don't think so |
| 22:53.34 | sruffell | ok…then I'll just do that….and not worry about anything else until you ping me again. |
| 22:53.43 | seanbright | i think i need to just be using a jitterbuffer |
| 22:53.49 | seanbright | or fixing audiohooks |
| 22:54.03 | seanbright | or ... OH... MY... |
| 22:54.06 | seanbright | 's head explodes |
| 22:54.28 | kpfleming | he must have seen the large floating black object in the sky |
| 22:54.54 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 22:54.54 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 22:55.50 | seanbright | sruffell: cool |
| 22:56.15 | seanbright | i'll try not to ping you again! and this time i mean it |
| 22:56.35 | sruffell | no worries…you've never pinged me needlessly that I recall…. |
| 22:57.15 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 22:57.15 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 23:08.36 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ocunmlebngdsenuk) |
| 23:14.16 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
