| 00:10.24 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 00:25.53 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:25.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:45.32 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.156) |
| 01:47.50 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:47.50 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:21.45 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-76-98-170-static.hfc.comcastbusiness.net) |
| 03:34.30 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:04.01 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:04.01 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:42.26 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:42.37 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:47.06 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:47.06 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 07:19.00 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:19.02 | schmidts | good morning |
| 08:34.40 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:34.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:52.25 | *** join/#asterisk-dev frawd (~francois@221.red-80-28-139.adsl.static.ccgg.telefonica.net) |
| 11:04.37 | *** join/#asterisk-dev jamicque (~jamicque@80.50.125.74) |
| 12:43.40 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:43.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:12.14 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.57.251) |
| 13:34.56 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.113.214) |
| 13:37.02 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fafdihsqfpsbfibs) |
| 13:37.02 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:59.24 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:06.10 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-zqqtmclsfuqzoyio) |
| 14:10.00 | *** join/#asterisk-dev jamicque (~jamicque@80.50.125.74) |
| 14:19.00 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:19.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:30.59 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-jmvkayfvpxsoljwu) |
| 15:00.35 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-czzhcenbaxieyicp) |
| 15:05.52 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.113.214) |
| 15:11.48 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:11.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:17.23 | *** join/#asterisk-dev w9sh (~chatzilla@64.238.96.125) |
| 15:34.51 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:34.51 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:41.43 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:41.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:44.42 | seanbright | sruffell: silly question... the res * 8 change |
| 15:44.54 | seanbright | what would the math be for g723.1 instead of g729? |
| 15:45.05 | sruffell | looks |
| 15:45.09 | seanbright | * 12? |
| 15:46.00 | sruffell | 12 for 5.3kb/s 10 for 6.3kb/s |
| 15:46.08 | seanbright | k |
| 15:46.23 | seanbright | the card does both? |
| 15:46.34 | sruffell | it decodes both..only generates 5.3 |
| 15:46.46 | seanbright | gotcha |
| 15:47.00 | sruffell | actually…so yeah…only need to worry about 5.3 in the frameout rountine |
| 15:47.03 | kpfleming | all g.723.1 decoders have to decode both |
| 15:47.46 | seanbright | i'm just trying to patch codec_dahdi |
| 15:47.50 | seanbright | the 'right' way |
| 15:47.52 | seanbright | so i can commit |
| 15:47.57 | sruffell | :/ thanks |
| 15:50.05 | seanbright | so is it as simple as: |
| 15:50.06 | seanbright | - pvt->f.datalen = res; |
| 15:50.06 | seanbright | + pvt->f.datalen = res * (dahdip->required_samples / 20); |
| 15:50.10 | seanbright | ? |
| 15:50.29 | seanbright | wait... that is fail |
| 15:50.41 | sruffell | yes…although…if you're going to commit that I would use something else besides the magic number. |
| 15:51.30 | seanbright | i should be changing the ->samples assignment (i'm not smart today) |
| 15:51.44 | sruffell | oh yeah..and that |
| 15:52.48 | seanbright | so what is 20 here? bytes per sample? |
| 15:52.50 | sruffell | If it were me…I think I would define SAMPLES_PER_BYTE_XXXX for the different formats. That should make it clear. |
| 15:53.03 | seanbright | k |
| 15:53.53 | kpfleming | there is already an asterisk API call to do that |
| 15:55.35 | sruffell | looks |
| 15:57.14 | sruffell | I failed. kpfleming, where should I be looking? |
| 15:58.48 | kpfleming | checking |
| 15:59.06 | file | I wanna say frame.c |
| 15:59.20 | seanbright | this is what i have |
| 15:59.21 | seanbright | http://pastebin.com/raw.php?i=kTUKtvkm |
| 15:59.40 | file | ast_codec_get_samples ? |
| 15:59.54 | kpfleming | well, i was wrong. the existing functions only work on frames. |
| 16:00.08 | kpfleming | but you are building a frame, so it might work... meeting time though |
| 16:01.16 | seanbright | ok... |
| 16:01.36 | sruffell | seanbright: generally, I think that would work….although if there's an API call that you can use to elimate defining new values it's probably worth seeing if it will work.. |
| 16:03.16 | seanbright | http://pastebin.com/raw.php?i=mw3fPUjW |
| 16:03.19 | seanbright | so that ^^^^ |
| 16:03.44 | seanbright | it compiles |
| 16:03.45 | seanbright | :-) |
| 16:03.57 | file | seems sane |
| 16:04.25 | seanbright | sruffell: +1? |
| 16:04.36 | sruffell | looking (never looked at that function before) |
| 16:04.40 | sruffell | uno momento |
| 16:04.42 | seanbright | k |
| 16:06.07 | sruffell | heh..yes...cool |
| 16:06.28 | sruffell | looks better…looks like it would handle other frame types if the tc400 ever generated them. |
| 16:06.35 | seanbright | excellent |
| 16:06.43 | file | sure would |
| 16:06.50 | seanbright | i choose to... COMMIT |
| 16:06.56 | sruffell | ack |
| 16:07.05 | sruffell | or Acked-by: Shaun Ruffell <sruffell@digium.com> :) |
| 16:07.22 | file | Shaun 'Roflcopter' Ruffell |
| 16:07.24 | sruffell | well..after a smoke test firt, right? |
| 16:07.27 | sruffell | first |
| 16:07.41 | sruffell | :) |
| 16:10.11 | seanbright | i tested with g729 |
| 16:12.36 | sruffell | I can test with g723…but it will take me a couple of hours to do so. |
| 16:12.55 | sruffell | (but I don't really think there is any risk) |
| 16:13.07 | sruffell | so…I still say commit..I'll just be sure to test before release. |
| 16:13.14 | seanbright | already done :-) |
| 16:13.18 | sruffell | man your fast |
| 16:13.25 | sruffell | you're |
| 16:13.30 | seanbright | they call me the minute man... |
| 16:13.32 | sruffell | lol |
| 16:13.36 | seanbright | probably for different reasons... |
| 16:13.37 | seanbright | :D |
| 16:13.46 | file | twss |
| 16:18.31 | seanbright | sruffell: thanks for your continued support of my million questions |
| 16:18.43 | sruffell | heh..thanks for you tollerance of my laggardness. |
| 16:18.57 | sruffell | tolerance. |
| 16:19.09 | sruffell | sheesh….it's going to be hard to break my non-IM proofreading ways. |
| 16:19.10 | seanbright | your typing today is more of a concern |
| 16:19.17 | sruffell | nods |
| 16:19.19 | sruffell | it always is... |
| 16:19.31 | file | gives sruffell a cookie |
| 16:19.36 | sruffell | nom nom nom |
| 16:19.45 | file | hey! that's my hand! |
| 16:31.50 | sruffell | seanbright, one comment for next time. https://wiki.asterisk.org/wiki/display/AST/Commit+Messages There is no one line summary on the commit message. Someday asterisk will switch to git (most likely) and those one-line summaries will become much more important. |
| 16:35.08 | seanbright | sruffell: updated |
| 16:35.16 | seanbright | sruffell: will make sure to do it right in the future |
| 16:36.38 | tzafrir_laptop | Anybody got to use dahdi recently on a system with no CONFIG_SMP ? |
| 16:37.46 | sruffell | that sounds ominous |
| 16:38.16 | sruffell | and…I don't think I have. |
| 16:38.26 | sruffell | oh..I have.. |
| 16:38.32 | sruffell | $ cat /boot/config-2.6.32-5-powerpc | grep SMP |
| 16:38.32 | sruffell | # CONFIG_SMP is not set |
| 16:38.32 | sruffell | CONFIG_BROKEN_ON_SMP=y |
| 16:38.32 | sruffell | CONFIG_SCSI_SAS_HOST_SMP=y |
| 16:38.32 | sruffell | CONFIG_VIDEO_VP27SMPX=m |
| 16:40.24 | sruffell | currently running r10464 "sysfs channels: cleanup device files handling" on it |
| 16:41.12 | tzafrir_laptop | hmmm... maybe it's not that. where is <linux/smp_lock.h> ? |
| 16:42.09 | sruffell | I'm not sure I understand. Where is smp_lock included in the dahdi sources? |
| 16:42.13 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-76-98-170-static.hfc.comcastbusiness.net) |
| 16:46.56 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 17:04.43 | tzafrir_laptop | sruffell, dahdi-base.c |
| 17:05.19 | sruffell | ahh…2.6.32 doesn't have CONFIG_BKL set I don't think |
| 17:10.33 | sruffell | what is the error that you're seeing…lock_kernel in smp_lock.h should still be valid when CONFIG_SMP is not set. |
| 17:26.25 | kpfleming | sees dogs |
| 17:27.31 | seanbright | kpfleming: and buck showalter |
| 17:28.04 | kpfleming | yes i thought i recognized that face from my day in phoenix |
| 17:28.19 | kpfleming | for some reason chat in the hangout is failing to work for me |
| 17:28.32 | seanbright | strange |
| 17:28.42 | seanbright | google's fault |
| 17:28.49 | kpfleming | yes, i am using that crappy chrome browser |
| 17:28.56 | seanbright | the worst |
| 17:33.32 | russellb | the dogs have it rough |
| 17:34.19 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@38.100.211.103) |
| 17:38.26 | tzafrir_laptop | sruffell, the file was not found |
| 17:38.48 | tzafrir_laptop | But maybe that build tree was broken |
| 17:57.48 | leifmadsen | for anyone using JIRA on a regular basis: https://chrome.google.com/webstore/detail/afpofdeegmmclngjmadpjaajacebkege |
| 18:25.58 | seanbright | leifmadsen: fancy |
| 18:26.25 | leifmadsen | seanbright: seems to work alright |
| 18:27.44 | seanbright | yeah |
| 18:41.10 | tzafrir_laptop | sruffell, Oron's hit-list of supported kernels: https://gitorious.org/~tzafrir/asterisk-tools/dahdi-linux-tzafrir/commits/remove_before_2618 |
| 18:42.20 | tzafrir_laptop | Removes more than 600 lines, including more than 100 ifdef-s |
| 18:43.31 | sruffell | bah: "This Git object is too large to be displayed in the browser Consider cloning the repository locally and look at the object there" |
| 18:44.28 | sruffell | although, I'm all for it…although I think we'll want kpfleming to give an Ack on asterisk-dev (or users?) |
| 18:45.55 | sruffell | actually…what about SUSE? 2.6.16 not still supported there? |
| 18:48.28 | sruffell | Looking at http://thread.gmane.org/gmane.comp.telephony.pbx.asterisk.devel/50063 now... |
| 18:49.09 | sruffell | yes..I see that Oron already noted that kernel ended general support on 12-Apr-2011 |
| 18:54.02 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:54.02 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 19:13.01 | *** join/#asterisk-dev jamicque (~jamicque@80.50.125.74) |
| 20:49.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 20:50.51 | otherwiseguy | Corydon76-work: I moved the "if" statement. The other thing wasn't an issue. |
| 20:54.40 | Corydon76-work | otherwiseguy: yes, it is |
| 20:55.23 | Corydon76-work | Oh, okay, nevermind, I see it now |
| 20:56.04 | Corydon76-work | I do think you should emit a warning on that, however, rather than just silently ignoring the specified value |
| 20:57.02 | otherwiseguy | It is an INSERT. Having columns that are autonumbered, nullable, have default values, etc. should not produce a warning. |
| 20:58.26 | Corydon76-work | Yes, but someone might have "alias cid_nam => callerid" in the config file, where "cid_name" is misspelled, and in that case, the column would be blank |
| 20:59.11 | Corydon76-work | We should spit out a warning that "cid_nam" is an unknown CEL field. |
| 20:59.18 | otherwiseguy | And in that case, there would be a warning when the INSERT failed. |
| 20:59.49 | Corydon76-work | The INSERT won't fail, because the column won't be specified in the query |
| 21:00.36 | Corydon76-work | We dynamically build the SQL based upon what values are present. |
| 21:01.46 | otherwiseguy | I'm not going to add a warning that will show up for everyone who defines an id column in their table every time an insert is done. |
| 21:02.02 | Corydon76-work | You misunderstand. |
| 21:02.55 | Corydon76-work | It won't show up for columns which don't have an associated CEL value. It should show up only when you specify a CEL field in the config file which doesn't actually exist |
| 21:03.59 | Corydon76-work | due to a misspelling or something else, like a new feature added to core CEL without it being added to cel_odbc |
| 21:06.59 | Corydon76-work | i.e. you can skip columns with blank CEL fields (as long as it's not a staticvalue), but if there's really an unknown CEL field, we should warn that it's an unknown field |
| 21:07.34 | Corydon76-work | and given how often CEL records are posted maybe on a (count++ % 100 == 0) basis |
| 21:16.02 | otherwiseguy | The whole reason I made the 'unknown' thing was because it was hitting on my 'id' column and going through and eventually producing an error. How do I differentiate between "column that is in the database that CEL doesn't understand" and fake column that was added because some dude can't type? |
| 21:16.49 | Corydon76-work | Ah. I posted a possible patch. I also gave you another Ship it! |
| 21:19.31 | otherwiseguy | I'll go ahead and ship it. The patch looks like it would just make the possibly false warning happen less. |
| 21:21.46 | Corydon76-work | Well, the patch specifically is looking to ensure that the specified CEL field is not blank, which it would be for your id field |
| 21:22.38 | Corydon76-work | There are two different "name" fields in cel_odbc, "name" and "celname". For your "id" column, name=id, celname is blank |
| 21:30.09 | otherwiseguy | I was printing celname to know that it was the "id" field that was hitting. |
| 21:42.54 | Corydon76-work | Ah, I know why, but I'm not going to bother trying to fix it. Just go ahead and ship it |
| 22:20.39 | kpfleming | sruffell: tzafrir_laptop: i have no objection to removing support for the stated kernels in the next major DAHDI release |
| 22:21.45 | sruffell | ok, cool. I just need to make sure product management doesn't have any objections (which I doubt they will..but, you never know…) I've sent them an email. |
| 22:48.40 | malcolmd | I object! oh wait..those aren't my products... I support this decision! :D |
| 23:55.22 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fafdihsqfpsbfibs) |