| 00:35.05 | d3wayne | O.O |
| 01:36.05 | blitzrage | o.O! |
| 04:02.17 | *** join/#asterisk-dev mog (n=mog@c-68-62-216-5.hsd1.al.comcast.net) |
| 04:02.17 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:26.04 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 04:27.58 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582896.dsl.bell.ca) |
| 04:30.36 | tzanger | hmm |
| 04:30.43 | tzanger | zaptel read size is 160 bytes |
| 04:30.48 | tzanger | where does this value come from? |
| 04:30.59 | tzanger | ZT_CHINKSIZE is 8 |
| 04:31.08 | tzanger | which is 8 ulaw frames, is it not? |
| 04:32.02 | tzanger | 160 would be 20ms |
| 04:32.19 | Corydon76-dig | Correct, 1ms of audio |
| 04:32.37 | Corydon76-dig | which corresponds directly to the interrupt frequency |
| 04:32.37 | tzanger | so the zaptel driver queues up 20ms at a time? |
| 04:32.44 | tzanger | right |
| 04:32.51 | tzanger | ZT_CHUNKSIZE is 1ms of audio |
| 04:32.58 | tzanger | but zt_read/write works on 20ms of it at a time |
| 04:33.06 | tzanger | so the driver keeps 20ms minimum around |
| 04:33.19 | Corydon76-dig | Right, because audio frequently arrives in that chunk size |
| 04:33.33 | tzanger | yes, sip/iax2 both use that |
| 04:33.43 | tzanger | now I know that rtp can have different packetization rates |
| 04:33.47 | tzanger | hmm |
| 04:33.47 | Corydon76-dig | Well, for some codecs |
| 04:34.00 | Corydon76-dig | iLBC is a notable exception, with 30ms frames |
| 04:34.03 | tzanger | yes |
| 04:34.06 | tzanger | now in ast_frame |
| 04:34.08 | tzanger | fr.samples |
| 04:34.16 | Corydon76-dig | but we use the smoother to resample to 20ms frames |
| 04:34.18 | tzanger | that's not in bytes, that in frames |
| 04:34.46 | tzanger | because there's a datalen too |
| 04:35.21 | Corydon76-dig | There's nothing magical about 20ms, we could just as easily make it 50ms, but much of that buffer would be wasted most of the time |
| 04:35.33 | tzanger | ah there it is |
| 04:35.56 | tzanger | hmm |
| 04:36.02 | Corydon76-dig | plus there's the possibility of audio lag, the larger the buffer |
| 04:36.05 | tzanger | right |
| 04:36.17 | tzanger | what on earth is ast_frame's offset for? |
| 04:36.23 | Corydon76-dig | headers |
| 04:36.27 | tzanger | it's usually inialized to AST_FRIENDLY_OFFSET |
| 04:36.59 | Corydon76-dig | Correct, it's the maximum size of all frame headers |
| 04:37.40 | Corydon76-dig | Different types have different sets of headers, so we ensure that we reserve space for the maximum amount |
| 04:37.54 | tzanger | doesn't that mean I should be writing AST_FRIENDLY_OFFSET bytes into the buffer pointed to by the frame->data? |
| 04:38.20 | Corydon76-dig | Not necessarily |
| 04:38.23 | tzanger | hmm |
| 04:38.39 | Corydon76-dig | The headers are typically added AFTER the data |
| 04:38.57 | tzanger | does the smoother get automatically set up? i.e. if my chan_read and chan_write uses 8 frames (1ms) will it fill up some internal buffer before sending 20ms audio on tis way? it doesn't seem to |
| 04:39.06 | Corydon76-dig | so you reserve space for the headers prior to adding the data, then add in the headers according to the data type |
| 04:39.09 | tzanger | Corydon76-dig: doxygen makes a note of **BEFORE** |
| 04:39.39 | Corydon76-dig | No, the smoother isn't set up generally, I don't think |
| 04:39.49 | tzanger | yuck, ok |
| 04:39.53 | Corydon76-dig | Only if we want frames of a particular length |
| 04:40.10 | Corydon76-dig | (like a particular app needs 15ms frames) |
| 04:40.13 | tzanger | so I best just make it work on 160 bytes of ulaw :-) |
| 04:40.34 | Corydon76-dig | You're welcome to request whatever size you want or handle anything |
| 04:40.39 | tzanger | ? |
| 04:40.51 | tzanger | my channel is being bridged to my working * box via iax2 |
| 04:41.00 | tzanger | my iax2 voice frames are only 12 bytes |
| 04:41.10 | tzanger | which is telling me it's definitely not packing them |
| 04:41.25 | Corydon76-dig | Wow, that's... tiny... |
| 04:41.41 | Corydon76-dig | Is the 12 bytes including headers, or is that just data? |
| 04:42.38 | tzanger | 23:28:41.432703 IP 192.168.77.15.4569 > 192.168.77.1.4569: UDP, length 12 |
| 04:42.39 | Corydon76-dig | In fact, at 12 bytes, I think you're doing more bytes of headers than data, which is fairly wasteful |
| 04:42.42 | tzanger | that woudl be the entire thing |
| 04:42.46 | tzanger | yes it is :-) |
| 04:43.02 | tzanger | I thought asterisk would have gathered up enough for a normal iax2 20ms frame and sent them on its way then |
| 04:43.04 | Corydon76-dig | Might want to up that a bit... |
| 04:43.05 | tzanger | but that's not the case |
| 04:43.10 | tzanger | well yes :-) |
| 04:43.23 | tzanger | I'm just trying to get audio at this point |
| 04:45.02 | tzanger | I HAVE AUDIO |
| 04:45.04 | tzanger | holy shiwt |
| 04:45.05 | tzanger | er shit |
| 04:45.08 | tzanger | it's not clean |
| 04:45.12 | tzanger | but it's audio |
| 04:45.38 | tzanger | not sure why it's not clean just yet |
| 04:45.44 | tzanger | but that was definitely a milliwatt tone |
| 04:46.09 | tzanger | and when I told the driver to stop replacing the audio with milliwatt data I got a very soft ticking which is good..ish |
| 04:46.12 | Corydon76-dig | Aha, your 12 byte frames are 1ms audio frames |
| 04:46.36 | Corydon76-dig | 4 bytes in a mini frame |
| 04:46.42 | Corydon76-dig | err, 4 bytes of headers |
| 04:46.46 | tzanger | yep |
| 04:47.14 | tzanger | I sent 10 12 byte frames, I get 1 164 byte one back it seems |
| 04:47.24 | tzanger | that's not 20ms then |
| 04:47.30 | tzanger | 160 bytes should be 20ms |
| 04:48.35 | tzanger | no it's 20ms between 164 byte frames from the real asterisk box |
| 04:48.36 | Corydon76-dig | 160 + 4 bytes of headers |
| 04:48.44 | *** join/#asterisk-dev mog (n=mog@c-68-62-172-83.hsd1.al.comcast.net) |
| 04:48.44 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:49.02 | tzanger | hmm and it's 1ms between my 8-byte frames |
| 04:49.12 | tzanger | so why is it only sending 10 of them instead of 20 |
| 04:49.16 | Corydon76-dig | 1-F bit, 15-source, 16-timestamp |
| 04:50.03 | Corydon76-dig | Dunno, maybe you're stepping incorrectly |
| 04:50.27 | tzanger | 666us, 1055, 3374 |
| 04:50.32 | tzanger | they're not evenly spaced |
| 04:50.37 | Corydon76-dig | Check the size of your datatypes... shorts instead of chars, perhaps? |
| 04:51.08 | tzanger | I'm sending 10 1ms frames in 20ms |
| 04:51.13 | tzanger | that might explain why it's choppy :-) |
| 04:51.28 | Corydon76-dig | So you should see about sending 2ms frames, instead |
| 04:52.01 | tzanger | nah, just fix the driver to send 20ms frames through userspace instead |
| 04:52.04 | Corydon76-dig | Anyway, I have to get to bed. I have to drive to HSV tomorrow |
| 04:52.06 | tzanger | match up wtih everything else |
| 04:52.19 | tzanger | ok :-) thansk for the help and have a safe drive |
| 04:52.24 | file | hola |
| 04:52.24 | tzanger | say hi to everyone at digium for me |
| 04:52.30 | tzanger | hey fiel |
| 04:52.32 | tzanger | er file |
| 04:52.32 | Corydon76-dig | Heh, will do |
| 04:52.52 | file | Corydon76-dig: did you get my text? |
| 04:53.00 | tzanger | tell them I'm pushing 288 channels on a bfin-537 |
| 05:16.37 | *** join/#asterisk-dev grimsy (n=chatzill@203-206-220-214.perm.iinet.net.au) |
| 06:18.47 | *** join/#asterisk-dev grimsy (n=chatzill@203-206-220-214.perm.iinet.net.au) |
| 06:25.16 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:25.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:13.55 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 07:51.06 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 07:51.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:51.51 | oej | Morning folks |
| 09:09.46 | *** join/#asterisk-dev RoyK (n=roy@80.239.107.70) |
| 10:51.08 | *** part/#asterisk-dev msetim (n=marcos@200.195.161.164) |
| 11:01.18 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:18.27 | *** part/#asterisk-dev RoyK (n=roy@80.239.107.70) |
| 11:57.56 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 12:24.52 | *** join/#asterisk-dev dklima (n=dklima@200.195.161.164) |
| 12:28.35 | *** join/#asterisk-dev zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 12:39.23 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.125.196) |
| 12:39.40 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 12:47.36 | *** join/#asterisk-dev eliel (n=eliel@200.59.172.38) |
| 13:36.36 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 13:42.10 | *** join/#asterisk-dev jsmith (i=jsmith@nat/digium/x-94de5081819173c3) |
| 13:42.10 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 13:50.12 | tzanger | morning |
| 13:51.51 | *** join/#asterisk-dev Zuchmir (n=dddddd@123-2-65-142.static.dsl.dodo.com.au) |
| 13:55.02 | Zuchmir | if i made a mod to * where is the place to post them as a possible inclusion in the main tree? |
| 13:55.31 | eliel | Zuchmir: bugs.digium.com |
| 13:57.12 | Zuchmir | is that for patches as well as bugs? |
| 13:57.24 | jsmith | Zuchmir: Yes |
| 13:57.30 | *** join/#asterisk-dev Victor_Yure (n=aaa@postfix.tradein.com.br) |
| 13:58.37 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 14:02.57 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 14:26.34 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 14:48.08 | steliosk | anyone has an idea why when starting asterisk as non root it does not create the asterisk.ctl file unless -c is passed as parameter ? |
| 14:52.14 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 14:53.27 | tzanger | weird |
| 14:53.36 | tzanger | tcpdump confirms I'm receiving iax2 frames full of miliwatt data |
| 14:53.45 | tzanger | but I only hear one brief blip of it at the start of the call and then silence |
| 14:56.42 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 14:56.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:58.30 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 14:58.32 | oej | Afternoon |
| 14:59.05 | tzafrir | steliosk, permissions issue? |
| 14:59.29 | tzafrir | steliosk, I have only encountered the oposite problem |
| 14:59.43 | steliosk | tzafrir : don't think so. then -c should not work also |
| 15:00.30 | steliosk | tzafrir : btw found that the issue i had with chan_zap.so was that libtonezone and libpri where missing from the image.... |
| 15:01.04 | steliosk | tzafrir : the usuall stupid things that take 2 days to figure out :/ |
| 15:04.01 | oej | russellb: Online? |
| 15:04.22 | Qwell | oej: he may be soon |
| 15:04.39 | oej | But I may not... Leaving... |
| 15:04.48 | steliosk | tzafrir : trace without the -c -> http://rafb.net/p/9V0e1k42.html |
| 15:04.54 | oej | The fix I committed was so major that it might be time for a new 1.4 release |
| 15:05.05 | Qwell | oej: which one? I can point him to it |
| 15:05.18 | oej | Qwell: The one with re-invite racing in chan_sip. |
| 15:05.39 | Qwell | 92158? |
| 15:05.47 | oej | file needs to test it with T.38 and if it works properly, then we need to release |
| 15:05.54 | jsmith-hsv | oej: When I talked to him on Friday, he was planning a release today or tomorrow |
| 15:06.02 | oej | qwell: Yes, I think that's it. |
| 15:06.12 | Qwell | jsmith-hsv: good timing then, hmm? |
| 15:06.13 | oej | Can't check from here, but the one with the 491 support |
| 15:06.20 | Qwell | and...hsv again? yay |
| 15:06.30 | *** join/#asterisk-dev syn (i=syn@kenobi.sceen.net) |
| 15:06.36 | oej | Ok, going to become oej-sth now. |
| 15:06.47 | oej | Leaving oej-sol |
| 15:06.49 | oej | he he |
| 15:06.51 | oej | Bye, bye |
| 15:06.55 | jsmith-hsv | Later oej |
| 15:06.57 | syn | hello |
| 15:07.50 | syn | I've set up an IAX trunk without authentication, and it works fine |
| 15:07.53 | syn | but, then |
| 15:08.27 | syn | when moving the "guest" user from static configuration to realtime, chan_iax seems unable to check the access |
| 15:08.49 | syn | i.e. unable to reach the "no host based, no username authentication" |
| 15:09.03 | syn | is it a known issue ? |
| 15:13.27 | syn | the code path when using such "authentication" reaches a point where |
| 15:13.46 | syn | <PROTECTED> |
| 15:13.46 | syn | <PROTECTED> |
| 15:13.49 | syn | <PROTECTED> |
| 15:13.52 | syn | <PROTECTED> |
| 15:13.52 | syn | is executed |
| 15:13.55 | syn | <PROTECTED> |
| 15:14.23 | syn | but it looks like, when realtime is used, the parameters requested by chan_iax are ipaddr and port : |
| 15:14.33 | syn | <PROTECTED> |
| 15:14.35 | syn | ... |
| 15:14.40 | syn | <PROTECTED> |
| 15:14.41 | syn | ... |
| 15:14.46 | syn | <PROTECTED> |
| 15:15.02 | syn | (in realtime_peer()) |
| 15:15.44 | syn | i wonder why the ipaddr is used when anonymous access should be allow |
| 15:17.12 | *** join/#asterisk-dev dklima (n=dklima@200.195.161.164) |
| 15:29.25 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 15:29.25 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 15:32.35 | *** join/#asterisk-dev kpfleming (i=kpflemin@nat/digium/x-7185d53586bb2ca1) |
| 15:32.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:47.55 | *** join/#asterisk-dev russellb (i=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:47.55 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:48.45 | Qwell | russellb: before I forget - oej was asking about a release today/soon. I can give details later, when you're not just getting in :D |
| 15:50.37 | file | but this is the *best* time |
| 16:00.02 | *** join/#asterisk-dev putnopvut (i=putnopvu@nat/digium/x-0ea9c317cd831f6e) |
| 16:00.30 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:01.00 | *** join/#asterisk-dev ctooley (n=ctooley@rrcs-71-42-115-242.sw.biz.rr.com) |
| 16:04.15 | *** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com) |
| 16:12.34 | *** join/#asterisk-dev Corydon76-lap (i=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:12.35 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:12.59 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:12.59 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 16:14.59 | russellb | file: Qwell ... sure, fill me in. |
| 16:15.10 | Qwell | russellb: sec, lemme get rev |
| 16:15.29 | Qwell | 92158 |
| 16:15.30 | Qwell | <oej> The fix I committed was so major that it might be time for a new 1.4 release |
| 16:15.38 | russellb | A92158 |
| 16:15.39 | file | A92158 |
| 16:15.40 | MuffinMan | [92158] Committed by oej on 2007-12-10 10:04:44: Avoid reinvite race situations with two Asterisks trying |
| 16:15.40 | MuffinMan | ning network. |
| 16:15.41 | MuffinMan | [92158] Committed by oej on 2007-12-10 10:04:44: Avoid reinvite race situations with two Asterisks trying |
| 16:15.41 | MuffinMan | ning network. |
| 16:15.46 | Qwell | <oej> file needs to test it with T.38 and if it works properly, then we need to release |
| 16:15.47 | De_Mon | lol I almost did it too |
| 16:15.55 | putnopvut | Ah, the 491 fix. |
| 16:16.02 | file | lemme looksee... |
| 16:16.04 | De_Mon | 491 fix? |
| 16:16.06 | putnopvut | That might also fix some other issues that oej didn't realize. |
| 16:16.31 | russellb | I have fixed some serious bugs in DEBUG_THREADS, too |
| 16:16.42 | Qwell | M11499 |
| 16:16.42 | MuffinMan | [assigned] [Asterisk] Applications/app_queue 0011499: Crush if i try call to queue that not have memebers reported by slavon http://bugs.digium.com/view.php?id=11499 |
| 16:16.49 | Qwell | If that's good, then it should probably be committed first |
| 16:16.56 | blitzrage | morning all |
| 16:16.59 | russellb | yes, it should |
| 16:17.04 | putnopvut | I was just about to comment on that issue. |
| 16:17.54 | file | the oej fix should be fine with T38 |
| 16:19.17 | *** join/#asterisk-dev ManxPower (n=manxpowe@182.sub-70-221-78.myvzw.com) |
| 16:20.23 | putnopvut | Qwell: yeah that fix looks right on 11499 |
| 16:20.49 | file | putnopvut: is it applicable to app_dial as well though? |
| 16:21.22 | putnopvut | I don't think so, because I can't think of a way that app_dial would go through its loop without setting the datastore. |
| 16:21.56 | putnopvut | While app_queue can skip over the loop because there are no members to dial, I don't know of a way that app_dial can be told to not dial anyone. |
| 16:22.14 | file | ah I see |
| 16:22.25 | file | nifty |
| 16:22.54 | Qwell | putnopvut: I'll let you commit then |
| 16:26.08 | putnopvut | All righty |
| 16:30.32 | Zuchmir | how do i attach a file/patch in http://bugs.digium.com/bug_report_page.php ? |
| 16:31.00 | Qwell | Zuchmir: do it after you open the report |
| 16:31.13 | Zuchmir | thanks |
| 16:31.59 | Qwell | Zuchmir: multiple skipms? |
| 16:33.13 | Qwell | the patch in 8213 does something quite similar |
| 16:34.11 | *** join/#asterisk-dev msetim (n=marcos@200.195.161.164) |
| 16:35.11 | Zuchmir | hmm, that looks good, why did that not make it into the main codebase? |
| 16:36.19 | Qwell | just needs further review |
| 16:36.27 | Qwell | (and testing..) |
| 16:38.48 | Qwell | does your patch do anything that the one on 8213 does not? I may go ahead and relate them, and close it |
| 16:40.05 | Zuchmir | 8213 took it further than mine, in the sense that it was actually implemented in the dialplan. |
| 16:40.35 | Zuchmir | no, i would call them related, using different style implementation |
| 16:43.48 | Zuchmir | actually, 8213 rewrote alot of code, which mine does alot simpler, i.e. in my patch, i only add a few paramateres to a few functions, and modify waitstream_core() to allow the multi speed |
| 16:44.18 | Qwell | Zuchmir: that's what I suspected. I'll look at it a bit more after your license is approved. Perhaps yours can be used as the method of implementing 8213 |
| 16:45.57 | *** join/#asterisk-dev jsmith-teaching (i=jsmith@nat/digium/x-c1b208cd511eab10) |
| 16:45.57 | *** mode/#asterisk-dev [+o jsmith-teaching] by ChanServ |
| 16:47.34 | *** join/#asterisk-dev agx (n=AGX@88.34.216.63) |
| 16:49.27 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:52.20 | Zuchmir | ok, thanks |
| 16:54.36 | Zuchmir | there's definately merit on the 8213 implemetation, but that duplicates alot of code, there can be a hybrid of the 2 methods implemented |
| 17:18.57 | *** join/#asterisk-dev Sentinal1 (n=Sentinal@87-194-204-58.bethere.co.uk) |
| 17:19.14 | Sentinal1 | hi! |
| 17:21.02 | Sentinal1 | i just asked in the other channel and was pointed here |
| 17:21.32 | Sentinal1 | i'm interested in developing a feature in asterisk where it would sample anouncments and be able to indetify them |
| 17:21.45 | Sentinal1 | much like VAD, but identify specific anouncements like 'the number is busy' |
| 17:22.05 | Sentinal1 | the first step would be to fingerprint each anouncement over 3 seconds for example |
| 17:22.15 | Sentinal1 | then fingerprint the first 3 seconds of voice, and match against our list |
| 17:22.30 | Sentinal1 | does asterisk have any code i could use to help me do that? |
| 17:22.46 | Sentinal1 | i'm sure sampling speech is easy, but are there any VAD routines? |
| 17:23.50 | ManxPower | Sentinal1: dsp.c |
| 17:24.22 | tzafrir | The list of versions for zaptel in the Mantis still has no version later than 1.4.5.1 ... |
| 17:24.48 | Sentinal1 | cool, so what does it do so far? (of course i'll look through the source myself, but any pointers would be appreciated) |
| 17:34.02 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 17:47.35 | eliel | ping file |
| 17:47.41 | eliel | M11489 |
| 17:47.42 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/General 0011489: During call setup signalling asterisk does not offer telephone-event (rfc2833) anymore reported by macbrody http://bugs.digium.com/view.php?id=11489 |
| 17:48.46 | eliel | there was a discussion a long time ago about supporting this propietary options... we should start the discussion again? or just close the issue and continue... |
| 17:51.35 | Sentinal1 | ahh |
| 17:51.43 | Sentinal1 | i'd be interested to develop it further |
| 17:54.15 | *** part/#asterisk-dev syn (i=syn@kenobi.sceen.net) |
| 17:58.06 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 18:08.26 | *** part/#asterisk-dev Zuchmir (n=dddddd@123-2-65-142.static.dsl.dodo.com.au) |
| 18:42.14 | *** join/#asterisk-dev jtexter3 (n=jamest@69-153-182-116.bn02845.tulsok.wayport.net) |
| 18:42.34 | *** join/#asterisk-dev jtexter3 (n=jamest@69-153-182-116.bn02845.tulsok.wayport.net) |
| 19:08.32 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:09.18 | fakhir | haker0 |
| 19:10.36 | tzanger | hmm |
| 19:10.38 | tzanger | I think I need a smarter poll |
| 19:10.41 | tzanger | polling 288fds seems to eat all my cpu |
| 19:10.46 | tzanger | how odd |
| 19:10.52 | tzanger | none of the fds are returning (I'm making it that way) yet a 1000ms timeout seems to take about ten times that long |
| 19:11.12 | tzanger | no priority events, so it should just sleep |
| 19:11.24 | tzanger | I'm polling a 289th FD (stdin) so I can quit with a keypress |
| 19:11.29 | tzanger | and it's very responsive |
| 19:19.56 | tzafrir | how well is zaptel on kernel 2.4? |
| 19:21.04 | tzafrir | Someone reported a while ago on #asterisk that it fails to build on 2.4.33.1 because <linux/workqueue.h> is missing |
| 19:21.46 | tzafrir | It took me a while to realize that this builds well for me, because I have /usr/include/linux/workqueue.h |
| 19:22.23 | tzafrir | And there are quite a few other warnings on 2.4 build. |
| 19:22.30 | tzafrir | Is it actually being used? |
| 19:27.31 | tzanger | not sure |
| 19:27.42 | tzanger | tzafrir: how many channels does the astribank run at once |
| 19:28.06 | mvanbaak | ok, who talked to wampie earlier today ? |
| 19:28.11 | mvanbaak | in the channel #openmoko ? |
| 19:28.43 | tzafrir | tzanger, "the astribank"? you need several devices to get to an ammount that is worth talking about |
| 19:29.02 | tzanger | tzafrir: well, I'm pushing 288 channels in my channel driver |
| 19:29.04 | tzanger | 288 separate fds |
| 19:29.51 | tzanger | I had defined a waitqueue and the 1ms interrupt would wake everyone on that waitqueue if there was something worth waking them for |
| 19:30.00 | tzanger | and poll() of course then poll_wait()ed on that wq |
| 19:30.06 | tzanger | but that was dragging it down like crazy |
| 19:30.12 | tzanger | removed that and I'm cool again |
| 19:30.58 | tzafrir | the main optimization we use there is not to have channels you don't need, which probably won't work in your setup |
| 19:31.09 | tzanger | yeah |
| 19:31.15 | tzafrir | (as the driver can't tell when a channel is needed) |
| 19:31.18 | tzanger | I think I am going to have to use a waitqueue for each channel |
| 19:31.37 | tzanger | and actually give each channel two waitqueues... one for data and one for events |
| 19:31.40 | tzanger | actually |
| 19:31.40 | tzanger | I bet that was the problem |
| 19:31.45 | tzanger | I have one waitqueue for everything |
| 19:32.20 | tzanger | which means I'm getting constantly woke up (at least in the kenrel poll(), it never makes it to userspace) because every 1ms there's data to read, space to write |
| 19:32.26 | tzanger | and the monitor thread doesn't care about that |
| 19:32.31 | tzanger | it just wants events (hookstate) |
| 19:32.40 | tzanger | balls, I bet I"m going to have to make this a zaptel driver yet |
| 19:32.54 | tzanger | for CID spill, call waiting and all that |
| 19:46.26 | Sentinal1 | ahha Asterisk/Sphinx |
| 19:46.28 | Sentinal1 | :) |
| 19:58.32 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 20:06.00 | *** join/#asterisk-dev ctooley (n=ctooley@rrcs-71-42-115-242.sw.biz.rr.com) |
| 20:32.19 | *** join/#asterisk-dev jsmith-teaching (i=jsmith@nat/digium/x-1dd04815c0f403ba) |
| 20:32.19 | *** mode/#asterisk-dev [+o jsmith-teaching] by ChanServ |
| 20:36.54 | *** part/#asterisk-dev eliel (n=eliel@200.59.172.38) |
| 20:37.57 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 20:58.23 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 21:23.27 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 21:23.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:28.00 | mvanbaak | hey oej |
| 21:28.11 | oej | hey |
| 21:28.33 | mvanbaak | howz you ? |
| 21:30.20 | oej | Tired... Time to go to bed. Been talking about Asterisk tonight again at a meeting in Stockholm :-) |
| 21:30.58 | oej | See you guys! |
| 21:31.09 | mvanbaak | latero |
| 21:40.38 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 21:58.37 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177581616.dsl.bell.ca) |
| 22:33.16 | *** join/#asterisk-dev tzafrir_home (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 22:54.55 | *** join/#asterisk-dev RoyK (n=roy@ip-10-16-149-91.dialup.ice.no) |
| 23:05.50 | *** join/#asterisk-dev Simon-- (n=sim@staff-nat.netnation.com) |
| 23:08.12 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 23:08.12 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:17.52 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 23:31.38 | *** join/#asterisk-dev dklima (n=sparch@200.175.197.171.adsl.gvt.net.br) |
| 23:40.20 | *** join/#asterisk-dev mvanbaak_ (n=michiel@vanbaak.xs4all.nl) |
| 23:45.57 | *** join/#asterisk-dev jsmith-teaching (i=jsmith@nat/digium/x-2084136e49a264f3) |
| 23:45.57 | *** mode/#asterisk-dev [+o jsmith-teaching] by ChanServ |
| 23:53.47 | *** part/#asterisk-dev zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |