| 01:26.17 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.96.186) |
| 01:28.13 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 02:21.09 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 02:45.50 | Juggie | file: pin |
| 02:45.53 | Juggie | *ping |
| 08:09.38 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:09.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:53.02 | *** join/#asterisk-dev mbrevda (~mbrevda@unaffiliated/mbrevda) |
| 11:23.57 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 11:26.45 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 12:01.43 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-103-152-61.cinci.res.rr.com) |
| 12:58.15 | *** join/#asterisk-dev sque (~sque@77.49.154.221.dsl.dyn.forthnet.gr) |
| 12:58.47 | sque | Hi, I want to patch the format_ogg_vorbis and setting an enviroment kills me |
| 12:59.26 | sque | I am working on debian and I have compiled deb packages for 1.8.0 and installed on the system |
| 13:00.21 | sque | on The build directory of the packages I then made somechanges on the format_ogg_vorbis.c file and build it again. I moved the new .so module on the /usr/lib/asterisk/modules and asked for module reload |
| 13:00.24 | sque | the result was: |
| 13:00.43 | sque | [Nov 7 14:55:19] WARNING[3655]: loader.c:774 inspect_module: Module 'format_ogg_vorbis.so' was not compiled with the same compile-time options as this version of Asterisk. |
| 13:01.17 | sque | and the module was not loaded. This check mechanism can be bypassed? Is it so important, even if I am working on same compiler, base version, machine? |
| 13:02.03 | sque | If it is, what is the best approach to develop a module with recompiling everything from the scratch? |
| 13:02.56 | sque | s/with/without* |
| 13:11.31 | pabelanger | sque: Why not use the 1.8.0 build from the debian repo? |
| 13:13.23 | sque | pabelanger, I took the package from svn.debian.org |
| 13:13.25 | sque | and build it |
| 13:13.42 | sque | Is there released a .deb in debian that I didn't noticed? |
| 13:14.37 | sque | pabelanger, http://packages.debian.org/search?keywords=asterisk&searchon=names&exact=1&suite=all§ion=all |
| 13:15.19 | sque | In any case, I don't care about the setup, I fix an annoying bug on vorbis fomat |
| 13:15.27 | sque | I want to fix* |
| 13:15.46 | sque | I want to TRY to fix* is a more appropriate sentence :P |
| 13:41.05 | pabelanger | sque: http://svn.debian.org/viewsvn/pkg-voip/asterisk/branches/experimental/ |
| 13:41.22 | sque | pabelanger, exactly this one I built |
| 13:42.56 | sque | I somehow managed to make it work reloading custom built modules, I will continue till I make a fully working ogg vorbis module and then I will rebuilt everything (deb also) to test it |
| 13:42.57 | pabelanger | sque: Ok, if you can reproduce the issue out side of the debian package, report it to the issue tracker. Otherwise, you'll need to follow up with the pkg-voip debian team |
| 13:44.21 | sque | pabelanger, I am trying to track it down the bug and then I saw that ogg_vorbis module does not support telling and seeking, and I am reimplementing the whole module using libvorbisfile rather than libvorbis |
| 13:44.27 | sque | with supports seeking and telling |
| 13:44.32 | sque | which* |
| 13:45.39 | sque | And at the same time I think this is the reason that asterisk sometimes does not playback all duration of ogg files on voicemail |
| 13:45.55 | pabelanger | what is the difference between libvorbisfile and libvorbis? |
| 13:45.58 | sque | sry not sometimes |
| 13:46.01 | sque | always* |
| 13:46.36 | sque | libvorbisfile is a layer upon libvorbis |
| 13:46.56 | sque | "Libvorbis contains the Vorbis reference encoder and decoder. |
| 13:46.56 | sque | This is the lowest-level interface to the Vorbis encoder and decoder. If you're just looking for a simple way to extract the audio from an Ogg Vorbis file, you probably want to use vorbisfile rather than using libogg and libvorbis directly. " |
| 13:47.43 | sque | and in case of format_ogg_vorbis.c it is just duplicated work of libvorbisfile which is VERY WELL tested. |
| 13:47.57 | pabelanger | seems to make sense to me |
| 13:48.25 | sque | me too, hope to make it work and contribute back :D |
| 14:11.26 | *** join/#asterisk-dev frawd (~francois@6.Red-88-26-139.staticIP.rima-tde.net) |
| 14:21.10 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 15:12.05 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:12.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:16.56 | sque | Who can help me with the formats API? |
| 17:19.06 | sque | for implementing a format module the SEEK function should take the offset to what? Samples? |
| 17:19.44 | sque | For example on 16-bit every two byte? Because on format_ogg_vorbis.c a comment says: |
| 17:19.46 | sque | <PROTECTED> |
| 17:19.48 | sque | and I am confused |
| 18:19.52 | Corydon76-dig | Yes, seek should take you to the offset in samples |
| 18:20.52 | Corydon76-dig | 8000Hz is the typical framerate for telephony |
| 18:21.07 | Corydon76-dig | errr, sample rate, not frame rate |
| 18:25.57 | sque | Corydon76-dig, ty |
| 18:26.23 | *** join/#asterisk-dev hehol (~Adium@ip-78-94-0-76.unitymediagroup.de) |
| 18:28.28 | sque | Corydon76-dig, If you know more the internal, I would be pleased if you helped me. |
| 18:29.08 | sque | In voicemail, if I choose ogg format, the meta data of the message (msg0000.txt) has 0 duration, while the ogg file is properly saved. |
| 18:29.38 | sque | ogg_vorbis didn't provide the tell() and I think this was the problem because I found... (w8) |
| 18:30.50 | Corydon76-dig | Yeah, the problem with it is that ogg vorbis is a variable rate codec, so that is not easily determined |
| 18:31.04 | sque | I fixed all of them |
| 18:31.23 | sque | I rewrite the majority of the module and now almost all the bugs eliminated (even playback had problem) |
| 18:31.51 | Corydon76-dig | How, by doing the actual calculation, or by adding statistics to the format, so that calculations can be saved with it? |
| 18:31.57 | sque | except this one, I now track the samples in writing mode and If you ask tell() it will return properly the samples |
| 18:32.25 | sque | On reading mode I use libvorbisfile which is accurate by design (Dont know internals) |
| 18:32.39 | sque | on writing mode I just count samples before encoding in a statistics variable |
| 18:32.45 | Corydon76-dig | There's a distinct advantage to creating statistics; it will lower the load associated with dealing with that audio format |
| 18:33.07 | Corydon76-dig | Ah, excellent |
| 18:33.38 | sque | so as an example for a ~14seconds file 8khz 16bit |
| 18:33.46 | Corydon76-dig | Yeah, if you want to contribute that back, I'm sure it would be appreciated on many fronts |
| 18:33.56 | sque | If I do tell() at the end it should return 104000 |
| 18:33.58 | sque | right? |
| 18:34.10 | sque | I will, when I finish it :) |
| 18:34.48 | Corydon76-dig | at 14 seconds, 14 * 8000, whatever that comes out to |
| 18:35.44 | Corydon76-dig | the bitrate shouldn't make a difference to the sample calculation |
| 18:36.11 | Corydon76-dig | only the sample rate |
| 18:36.52 | sque | sry I just want to match it, I am freaked out here :P |
| 18:36.57 | Corydon76-dig | For example, in some codecs, there's 6.3 bits per sample. Obviously, fractions wouldn't calculate well |
| 18:37.05 | sque | uncompressed |
| 18:37.09 | sque | no compresion |
| 18:37.34 | sque | tell() should return uncompressed samples, not absolute position on the file? |
| 18:37.44 | sque | that's what I have understood |
| 18:37.53 | Corydon76-dig | Correct |
| 18:37.56 | sque | independant of compression |
| 18:38.10 | Corydon76-dig | And seek should find the position, considering samples |
| 18:38.44 | sque | so telling() at the end of a file with length: 0m:12.939s at 8Khz, 103520 is correct? |
| 18:39.04 | sque | ok I don't think I can support seek on write mode. |
| 18:39.23 | Corydon76-dig | Well, the seek doesn't necessarily need to do a seek on the underlying file |
| 18:40.29 | Corydon76-dig | If you want, it can simply save that internally, then when it comes to actually writing out, you read in the logical block, uncompress, truncate to the appropriate length, save additional samples, recompress, and write to disk |
| 18:40.54 | Corydon76-dig | Make sense? |
| 18:41.40 | Corydon76-dig | The purpose of that mode is to allow something like the dictate app to work, where you can rewind a recording and re-record a section |
| 18:41.59 | sque | ok I will investigate it later |
| 18:42.14 | sque | no my problem is the duration |
| 18:42.22 | sque | and your comments are valuable :) |
| 18:42.56 | Corydon76-dig | Most of the time, the only seek positions you will ever get are to seek to the beginning or seek to the end |
| 18:43.23 | sque | The duration is calculated through the tell() as far as I have understood, tracking all the way to line app.c:909 |
| 18:43.29 | sque | (source code of 1.8.0 released) |
| 18:43.32 | Corydon76-dig | Right |
| 18:44.08 | Corydon76-dig | That's the most efficient method, because the file format should be able to just "say" what the current length is |
| 18:44.38 | sque | yes |
| 18:44.43 | sque | but it doesn't work... |
| 18:44.59 | Corydon76-dig | The problem with wallclock time is that if a recording timed out, then the final section of wallclock time is just silence |
| 18:45.10 | sque | at least I am confident now that I return the proper number |
| 18:45.20 | Corydon76-dig | and that silence doesn't get translated into actual frames |
| 18:45.42 | sque | ok let me show the log |
| 18:47.53 | sque | Corydon76-dig, http://pastebin.com/Y71Rcaaf |
| 18:56.20 | sque | did you see? I return 103520 samples, the ogg file is actual 12,93secs but in metadata it saves only 3! |
| 18:56.22 | sque | :S |
| 18:57.02 | sque | I ll take a break an continue latter, ty for info! |
| 19:18.06 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 19:52.59 | *** join/#asterisk-dev n0tk (~n0tk@216.160.42.30) |
| 20:30.18 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 21:39.57 | sque | Corydon76-dig, are you here? |
| 21:40.20 | Corydon76-dig | I am, but idling |
| 21:41.01 | sque | ok, I tracked down the problem of wrong duration |
| 21:41.56 | sque | and I wanted some help on existing code |
| 21:42.15 | sque | and you were the only one to answer :p |
| 21:42.40 | Corydon76-dig | On the weekend, I'm not surprised |
| 21:43.45 | sque | hmm, thought the weekend was the hack-days |
| 21:43.49 | sque | other day is workday |
| 21:43.51 | sque | anyway |
| 21:44.13 | sque | one moment to collect info and show you, and if you have any comment to make, nothing more. |
| 21:44.20 | WIMPy | Weekend is for work. The rest is for the job. |
| 21:49.22 | sque | Corydon76-dig, http://pastebin.com/LDq3zs1t |
| 21:50.28 | sque | in the log I added an extended print, the problem for me is that in the __ast_play_and_record (app.c) after real encoding it detects silence (A LOT) 14sec/20sec. |
| 21:51.09 | sque | So the ogg_tell() works correctly but it gets wrong value after silence calculation. |
| 21:51.36 | sque | The first bug I see here is that it substructs "Silence" duration without prior truncating file (which would fail) and check it result. |
| 21:51.54 | sque | The second is, why 14 seconds? How is this calculated? |
| 21:53.20 | sque | Anyone with any comment is welcome |
| 21:54.21 | Corydon76-dig | It uses a silencethreshold to determine what is actual speech and what is silence. This is all tweakable |
| 21:54.37 | Corydon76-dig | but it really speaks to you needing to check your audio levels |
| 21:55.18 | Corydon76-dig | See silencethreshold in voicemail.conf, [general] section |
| 22:09.07 | *** join/#asterisk-dev saizai (~saizai@unaffiliated/saizai) |
| 22:09.48 | saizai | I am looking to patch Asterisk to comprehend new input tones (e.g. redbox coin tones). Where in the code does it currently determine how to identify given frames? I tried tracking that down, and eventually ended up in some sort of dahdi/skinny/h232/etc split, and... am kinda confused at its crypticness at this point. |
| 22:10.30 | Corydon76-dig | Yeah, we're not going to help you try to cheat the phone company |
| 22:10.58 | saizai | it's not to cheat a phone company. |
| 22:11.06 | saizai | it's for a special install |
| 22:11.30 | Corydon76-dig | So far, all I'm hearing is that you want to use Asterisk as a redbox |
| 22:11.38 | saizai | you misunderstand |
| 22:11.49 | saizai | I want my install of Asterisk to *recognize* redbox tones |
| 22:11.51 | saizai | not to *generate* them |
| 22:11.53 | Corydon76-dig | Ah |
| 22:12.11 | Corydon76-dig | Then you need to look in dsp.c. That's where tone recognition occurs |
| 22:12.14 | saizai | in the same way that eg it recognizes all 16 DTMF tones |
| 22:12.46 | Corydon76-dig | I can tell you that's where it occurs. Understanding how it works is a whole other ball of wax |
| 22:13.25 | saizai | quite >< |
| 22:14.44 | saizai | hm, is it even the same sort of thing that I could add it in as a psuedo-DTMF? |
| 22:15.17 | Corydon76-dig | Yes, that's pretty much how you'd do it |
| 22:15.57 | saizai | like DTMF doesn't have some sort of ... I dunno, pre-/post- tone things to say 'hey this is a dtmf' |
| 22:16.02 | saizai | that coin tones would lack |
| 22:16.15 | saizai | AFAICT coin tones and the main DTMF tones are just dual pure tones |
| 22:16.34 | saizai | and if it's just a matter of adding a new one, then that *seems* relatively straightforward here |
| 22:16.43 | saizai | (.... relatively ...) |
| 22:17.30 | WIMPy | Is it one tone or two? |
| 22:18.13 | saizai | http://en.wikipedia.org/wiki/Red_box_(phreaking)#United_States says it's 1700Hz + 2200Hz, with duration and separation significant |
| 22:19.06 | Corydon76-dig | Then it's probably going to be easiest if you just recognize it as an extended DTMF character |
| 22:19.15 | Corydon76-dig | like dtmf 'R' |
| 22:19.19 | saizai | blinks |
| 22:19.22 | saizai | wtf is DTMF 'R'? |
| 22:19.30 | WIMPy | Uh. With timing. That surely requires additions not neccessary for dtmf. |
| 22:19.34 | Corydon76-dig | I'm suggesting a design action |
| 22:19.35 | saizai | I thought it was only 0-9*#a-d |
| 22:20.12 | Corydon76-dig | It is. So you clearly don't want your recognition of that tone to conflict with existing tones |
| 22:20.51 | Corydon76-dig | I'm suggesting that you alter the dsp routines to recognize that dtmf tone and to queue a DTMF frame that doesn't conflict with existing DTMF |
| 22:21.30 | saizai | oh, you just mean calling it 'R'. not analogizing to some extant 'R' |
| 22:21.35 | Corydon76-dig | Correct |
| 22:21.40 | saizai | that's basically what I was thinking :p |
| 22:21.52 | saizai | call the coin tones some new letter |
| 22:21.57 | *** join/#asterisk-dev n0tk (~n0tk@216.160.42.30) |
| 22:21.58 | Corydon76-dig | Right |
| 22:22.19 | saizai | 'extended' just meaning as in a-d, yes? |
| 22:22.19 | Corydon76-dig | and then you can process it in the dialplan |
| 22:22.36 | Corydon76-dig | Well, a-d is regular dtmf. |
| 22:22.54 | Corydon76-dig | I'm suggesting you make your own custom expansion of the DTMF set |
| 22:22.58 | saizai | m |
| 22:23.22 | Corydon76-dig | and which additionally does not conflict with the pattern match characters in the dialplan (XZN) |
| 22:24.21 | Corydon76-dig | It's probably preferable to just recognize them in features.conf, then |
| 22:25.01 | Corydon76-dig | Don't know if you need to recognize them mid-call or not, but mid-call, features.conf is your only option |
| 22:25.11 | saizai | it does need to be mid-call |
| 22:25.17 | saizai | like as input to a menu or somesuch |
| 22:25.56 | Corydon76-dig | There are going to be some challenges to doing that, but I'm sure you can manager |
| 22:26.02 | Corydon76-dig | manage it, rather |
| 22:26.05 | saizai | *nod* |
| 22:26.17 | saizai | is there something special to being able to recognize the sequence of tones? |
| 22:26.35 | saizai | I'm not really clear on what the dsp methods are getting in |
| 22:26.36 | Corydon76-dig | It's not a sequence of tones. It's a duality of tones |
| 22:26.46 | saizai | it's a sequence :P |
| 22:26.51 | saizai | "The tones are made by playing back 1700 Hz and 2200 Hz tones together. One 66 ms tone represents a nickel. A set of 2 66 ms tones separated by 66 ms intervals represent a dime, and a quarter is represented by a set of 5 33 ms tones with 33 ms pauses." |
| 22:26.54 | Corydon76-dig | Oh, that's going to be fun, then |
| 22:27.11 | saizai | my impression was the methods are getting some sort of pre-segmented stream |
| 22:27.20 | Corydon76-dig | You'll need to do all of that in dsp.c, then |
| 22:27.25 | saizai | and then they do FFT or something to recognize the tones out of it |
| 22:28.04 | saizai | but they don't have actual access to the stream per se |
| 22:28.27 | saizai | such that they could say oh 'cause this 66ms 1700/2200 Hz is followed by another one, it's actually a dime not a nickel |
| 22:28.37 | Corydon76-dig | Either you use additional characters to represent each or you simply queue multiple DTMF, depending upon the amount |
| 22:29.00 | saizai | hm. |
| 22:29.17 | saizai | solike, I could say one letter for a 66ms and one for a 33ms |
| 22:29.23 | saizai | and not enforce the spacing |
| 22:29.25 | Corydon76-dig | but I'd suggest that you do all of that timing determination directly in dsp.c and not bother the dialplan with it |
| 22:29.42 | saizai | *nod* |
| 22:30.00 | Corydon76-dig | No, I'm saying that you not even worry about how long it is beyond dsp.c |
| 22:30.25 | Corydon76-dig | dsp.c does the duration and sequence determination, using a state machine |
| 22:31.21 | Corydon76-dig | and then from dsp.c, you queue the right DTMF frame to represent the amount added |
| 22:31.52 | Corydon76-dig | R for nickel, S for dime, T for quarter, or something like that |
| 22:32.59 | saizai | m, right |
| 22:33.10 | saizai | that's my ideal |
| 22:33.30 | saizai | I'm just trying to figure out how small an incision I can make without having to make a whole bunch of mucking with the rest of it |
| 22:33.39 | saizai | e.g. DTMF is 40-50ms |
| 22:33.43 | saizai | not 33 or 66 |
| 22:48.17 | saizai | it looks like the place to patch is ast_dsp_process, making a new detector function based on dtmf_detect and ast_dsp_busydetect, which inserts a frame that pretends to be a DTMF. |
| 22:48.38 | saizai | but there's some sort of stateful flagging going on with the DTMF begin/end frames that I'm not grokking |
| 22:53.00 | Corydon76-dig | I wouldn't make a new detection function, but simply amend the existing one |
| 22:53.37 | Corydon76-dig | There's an existing state machine in there |
| 22:53.58 | saizai | the DTMF one doesn't seem set up to comprehend pauses |
| 22:53.59 | saizai | like eg the busy-tone one does |
| 22:54.06 | Corydon76-dig | If you make a new one, then you need to make a determination of when to use each detector |
| 22:54.14 | saizai | n~ |
| 22:54.17 | Corydon76-dig | Sure it is |
| 22:54.37 | Corydon76-dig | When there's no tone, it's detected as the end of a tone |
| 22:55.06 | Corydon76-dig | and you need the end of a tone in order to determine if there's sufficient silence before the next one starts |
| 22:55.20 | Corydon76-dig | Like I said, it's a state machine |
| 22:57.43 | saizai | hm, do I have access to dsp->historicsilence ? |
| 22:57.49 | saizai | from within dtmf_detect |
| 22:59.12 | saizai | or is there some cleverer way to detect those 33/66ms pauses |
| 23:00.18 | Corydon76-dig | No, you'll need to use that |
| 23:00.43 | Corydon76-dig | You'll probably need additional structure elements, especially when it comes to quarter tones |
| 23:00.53 | Corydon76-dig | You need to keep track of how far you're in |
| 23:01.08 | Corydon76-dig | plus you'll probably want some tolerances of inaccurate tones |
| 23:01.13 | saizai | yeah |
| 23:01.17 | Corydon76-dig | i.e. +-5ms |
| 23:01.24 | saizai | right |
| 23:01.58 | saizai | though the structural stuff I'm wary of, since I have no idea how it gets preserved etc and I don't want to have to go editing a whole bunch of other stuff I might miss |
| 23:02.25 | saizai | or risk colliding with some other structural frame somehow |
| 23:09.17 | saizai | unrelated q: how can I play two sound files simultaneously? Like a long menu plus some overlapping short sound |
| 23:11.11 | saizai | (of course I can also just mix them in audio and play the right mixed sound, but it'd be easier if I can just play the two files simultaneously) |
| 23:14.29 | Corydon76-dig | It's a private structure... it's not something you need to worry about |
| 23:14.59 | Corydon76-dig | There's not a straightforward method for playing multiple sounds concurrently |
| 23:15.19 | Corydon76-dig | You could start a conference and play each sound file as a separate user |
| 23:15.29 | saizai | good on the former part. |
| 23:15.42 | saizai | that sounds like quite the kludge for multi sounds :/ |
| 23:15.57 | saizai | I'd rather just punt to shell and mix the files in some sound app |
| 23:16.01 | Corydon76-dig | Yes, that would be a kludge |
| 23:16.13 | Corydon76-dig | And yes, mixing the sounds with sox would probably be a better option |
| 23:16.33 | saizai | well, at least that saves me the time of beating my head against STREAM FILE :p |
| 23:16.53 | saizai | thanks for all the info |
| 23:17.16 | saizai | I'm actually kinda surprised nobody's done a old school phreaker patch yet |
| 23:17.52 | saizai | that's already implemented coin tones eg |
| 23:27.20 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 23:27.20 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 23:30.14 | saizai | looks like 6 years ago someone thought of this, at least? http://lists.digium.com/pipermail/asterisk-dev/2004-February/003055.html |