| 13:43.23 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 14:48.44 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 15:11.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-vpvraqzjbhlyjhcp) |
| 15:11.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:19.13 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 16:29.52 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:29.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:57.26 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:01.49 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:26.11 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:e1c1:4917:44c0:2f0e) |
| 18:42.05 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 19:38.40 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 19:38.40 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 20:18.49 | coreyfarrell | mjordan: for the media_formats-reviewed branch I definitely wouldn't mind if that weren't automerged until after r3625 is done. |
| 20:22.59 | mjordan | Yeah, it failed immediately as well. I'm thinking that was probably just a bad idea regardless |
| 20:23.15 | mjordan | luckily, it didn't 'do' anything. |
| 20:24.18 | mjordan | btw, should have an e-mail out to the -dev list on ASTERISK-23715 later today |
| 20:24.36 | coreyfarrell | looks at jira.. |
| 20:25.14 | coreyfarrell | ah.. ok |
| 20:25.21 | file | mjordan, everything should be named joe. |
| 20:25.37 | mjordan | file: one massive function |
| 20:25.45 | mjordan | with an enum for the operation! |
| 20:25.46 | file | mjordan, voicemail? |
| 20:25.52 | mjordan | file: exactly |
| 20:26.03 | coreyfarrell | no, we need to move all code to main/asterisk.c, inside main() |
| 20:26.08 | mjordan | ew |
| 20:26.14 | file | more use of goto! |
| 20:26.22 | mjordan | file: coreyfarrell: so, after the core patch, what is the next section to tackle? |
| 20:26.29 | mjordan | I'm going to try to get through as much as I can tomorrow |
| 20:26.55 | coreyfarrell | still 3 more files in core.. channel.c, dsp.c and rtp_engine.c |
| 20:27.18 | mjordan | rtp_engine is going to ripple down into res_rtp_asterisk, which will ripple out into a whole lot of portions of channel drivers we haven't finished up yet |
| 20:27.27 | mjordan | might be good to do that one next. Or channel.c. |
| 20:27.44 | coreyfarrell | my goal is to be able to start doing some automated testing with at least one channel driver |
| 20:27.46 | mjordan | coreyfarrell: if you haven't started those yet, I can take a crack at them this weekend |
| 20:27.58 | file | channel.c is probably a good one, it'll prove out the API more |
| 20:28.03 | coreyfarrell | I have started the 3 files in main/*.c |
| 20:28.06 | mjordan | coreyfarrell: agreed. I had started down that road with chan_pjsip, but gave up when I realized we weren't very close to compiling |
| 20:28.33 | coreyfarrell | that's why I started working on main, can't do any testing without it |
| 20:28.52 | mjordan | If you want to do them that's fine, but I definitely have some cycles tomorrow. If you have a partial patch started, I'd be happy to take it on. |
| 20:28.52 | file | ripples |
| 20:29.18 | coreyfarrell | oh and format_cache.c needs to be worked on. currently with all the patches I have we get link errors due to ast_format_ulaw and others not existing |
| 20:29.44 | coreyfarrell | mjordan: you want me to email you a diff for the 3 main/*.c files I have WIP? |
| 20:29.51 | mjordan | sure! |
| 20:30.11 | mjordan | have a neighborhood party tonight (summer solstice!), but tomorrow is all work all the time :-P |
| 20:30.23 | coreyfarrell | sounds like fun |
| 20:30.26 | file | mjordan, ...your neighborhood has... a party? |
| 20:30.35 | file | YOUR neighborhood? |
| 20:30.36 | mjordan | file: luckily, not my neighborhood |
| 20:30.47 | mjordan | the nice one in downtown |
| 20:30.53 | file | :D |
| 20:30.54 | mjordan | mine is the 'not so nice one just outside of downtown' |
| 20:31.04 | mjordan | we have parties, but they usually involve kegs. And eventually cops. |
| 20:31.52 | file | I'd give you bonus points if there were cops partying |
| 20:32.27 | mjordan | no |
| 20:32.30 | mjordan | they did not party. |
| 20:32.50 | mjordan | Honestly, the last time it happened I was quite glad the cops broke it up. I'm not looking forward to the fourth of july here. |
| 20:33.05 | mjordan | Meth heads + explosives + heat == dumbassery |
| 20:33.11 | file | you should have a live webcam |
| 20:33.26 | mjordan | it'd mostly just be a bunch of rebel yells and loud pops |
| 20:33.41 | mjordan | and a few loud trucks roaring by with beer cans flying out the side |
| 20:33.46 | mjordan | 'murica! |
| 20:34.16 | file | January is the month when Earth is closest to the sun. |
| 20:34.54 | coreyfarrell | mjordan: you have that patch. have fun :) |
| 20:34.59 | mjordan | coreyfarrell: thanks! |
| 20:36.12 | coreyfarrell | file: since you are here, how do you feel about ast_codec->frame_bytes, and should I rename the ID used for ast_data_add_int? |
| 20:37.09 | file | I'll answer with a question and an answer 1. What is it conveying? 2. Probably not, although I don't care that much about ast_data_* much like others |
| 20:38.54 | coreyfarrell | It's meant to be a direct replacement for fr_len. sorry if that's a half-answer but this is starting to get into stuff I only 95% understand |
| 20:40.10 | file | I know what it's meant to be, but I don't know what that value actually is. The number of bytes for the data in a frame is dependent on the length of what is contained within it. |
| 20:41.34 | coreyfarrell | and the length is variable (I think?) |
| 20:41.58 | file | sure is |
| 20:43.12 | coreyfarrell | I might be doing the math wrong but I think that's the number of bytes in a frame of inc_ms length |
| 20:46.14 | file | that makes sense |
| 20:46.37 | file | a name descriptive of that would be good |
| 20:48.54 | coreyfarrell | damn looks like we don't have an equivalent to inc_ms either |
| 20:49.03 | file | we do |
| 20:49.09 | file | minimum_ms |
| 20:50.19 | coreyfarrell | oh, that was separate previously (min_ms and inc_ms). so maybe minimum_bytes or minimum_frame_bytes? |
| 20:51.02 | file | hrm, I wonder if we can make it bytes_per_ms |
| 20:51.48 | coreyfarrell | I was thinking about that too, but what if that puts us into fractional territory? |
| 20:51.59 | file | yeah, that's what I pondered as well |
| 20:52.47 | file | minimum_bytes is fine with documentation to explicitly say it is the number of bytes to carry the specified minimum ms |
| 20:53.36 | coreyfarrell | . /*! \brief Length in bytes of a minimum_ms frame */ |
| 20:55.09 | file | Length in bytes of the data payload of a minimum_ms frame |
| 20:58.16 | coreyfarrell | mjordan: I'm getting error's viewing the diff on RB |
| 21:00.42 | coreyfarrell | oh wait the error is on the 2 files I deleted, nevermind probably not an issue. |
| 21:01.46 | coreyfarrell | if you view the diff between 4 and 5, it gives a diff currently unavailable error for format_pref.c and format_pref.h |
| 21:41.27 | mjordan | coreyfarrell: cool, I'll take a look at it. I'm not sure what to do with format_pref |
| 21:41.34 | mjordan | I feel like most of that just needs to go away |
| 21:41.58 | mjordan | for example, rtp_engine uses a format_pref to set the packetization - but no RTP implementations implement the packetization_set callback |
| 21:42.57 | file | it's an optional callback |
| 21:43.06 | file | the information is still stored within the RTP instance |
| 21:43.13 | file | or rather, in the codecs structure |
| 21:44.01 | mjordan | it's an optional callback that isn't used :-P |
| 21:44.38 | mjordan | and right now, ast_rtp_codecs_packetization_set only calls the optional callback |
| 21:44.50 | mjordan | where it gets stored in the RTP implementation is elsewhere |
| 21:45.00 | mjordan | anyway, my hope is to remove as much of format_pref as possible |
| 21:46.38 | mjordan | file: actually, what is format_pref even used for at this point? |
| 21:49.52 | file | uhhhh |
| 21:50.01 | mjordan | for example, chan_iax2 references it a lot, but doesn't really "use" it. iax2_codec_choose ignores the pref parameter, and while it sometimes references a global prefs, it's ... fuzzy as to how well it uses it. |
| 21:50.16 | file | no |
| 21:50.36 | mjordan | ? |
| 21:50.44 | file | to the question |
| 21:51.05 | mjordan | what was my question? |
| 21:51.18 | file | oh I left out a what |
| 21:51.37 | file | the answer is nothing is currently using format_pref.c/format_pref.h, but an impl exists within the legacy compatibility functionality |
| 21:51.58 | mjordan | right |
| 21:52.04 | mjordan | there's some of those functions that could be removed |
| 21:52.14 | mjordan | but it looks like the two major remaining consumers are chan_iax2 and chan_h323 |
| 21:52.30 | mjordan | chan_iax2 "uses it", but it uses it from a remote/our capabilities perspective - which means it could just use ast_format_cap |
| 21:52.38 | mjordan | chan_h323 is ... well, it's chan_h323. |
| 21:52.53 | mjordan | I'm not sure we can't rip it out of format_compatibility |
| 21:53.08 | mjordan | because it's unlikely that chan_iax2 is going to work any way unless we do deal with it |
| 21:53.40 | file | my head hurts |
| 21:53.42 | mjordan | deplores the lack of test infrastructure for chan_iax2 |
| 21:54.32 | mjordan | file: I know, right? This is going to be fun to get done in the next two weeks |
| 21:55.02 | file | time is a construct of human creation |
| 21:56.43 | mjordan | deadlines doubly so |
| 21:57.10 | file | it's not a deadline unless someone loses a life and has to start over from the beginning |
| 22:03.15 | mjordan | file: so, formats are immutable, ast_format_cap is not. Is the expected storage location of something like a packetization preference with ast_format_cap? |
| 22:03.18 | mjordan | or elsewhere? |
| 22:03.37 | file | ast_format_cap |
| 22:03.54 | mjordan | k. Within an ast_format_cap, what determines the preference order of formats? |
| 22:04.06 | file | the order in which they are added |
| 22:04.32 | mjordan | works for me as well. |
| 22:04.35 | mjordan | K! |
| 22:09.20 | coreyfarrell | Only 1 function from format_pref.c was still being used, so I just moved it to format_compatibility.c. then format_pref.{c,h} was deleted since nothing was using it |
| 22:10.20 | coreyfarrell | anyways I'm not really here, got chicken on the grill |
| 22:10.49 | mjordan | heh |
| 22:11.00 | mjordan | I'm about to not be here as well, but that sounds good to me (both the rename and the chicken) |
| 22:11.25 | mjordan | have a good evening file/coreyfarrell - I'll be around tomorrow working on this |
| 22:11.35 | file | don't go insane |
| 22:37.26 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |