<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/06/2016 12:52 PM, John Kiniston
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAFJQOGeAth0nvYN4dXrTL+8XkktD9B+N28P-DGabY=A4LtuC+g@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>I got all fired up on getting up to date with the current
          LTS version of Asterisk while at Astricon and I'd like to make
          my first patch.<br>
        </div>
      </div>
    </blockquote>
    <br>
    Awesome! Hopefully this will be the first of many to come.<br>
    <br>
    <blockquote
cite="mid:CAFJQOGeAth0nvYN4dXrTL+8XkktD9B+N28P-DGabY=A4LtuC+g@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>I want to modify bridge_builtin_features.c to honor
          the"MONITOR_EXEC" and "MONITOR_EXEC_ARGS" variables like
          Monitor() does so that my one touch recordings using automon
          get post processed. <br>
          <br>
          I'm no C programmer but I took a class at the local community
          college uh I guess it's been two decades ago now so forgive
          me.<br>
          <br>
          I found the code in res/res_monitor.c that handles setting the
          execute application and running it and I've copied what looked
          like the part I needed into bridges/bridge_builtin_
          <div><wbr>features.c and with a few minor changes it almost
            works.<br>
            <br>
          </div>
          The part where it's breaking down is getting the format of the
          recorded file which I think should be touch_format I'm getting
          (null) so I reckon set_touch_variables doesn't do what I hoped
          it did.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <blockquote
cite="mid:CAFJQOGeAth0nvYN4dXrTL+8XkktD9B+N28P-DGabY=A4LtuC+g@mail.gmail.com"
      type="cite">
      <div dir="ltr">Would someone please help me get the file-name
        extension or point me in a better direction if this doesn't look
        like a good idea?<br>
      </div>
    </blockquote>
    <br>
    I'm going to answer your question in two ways here: first, from the
    perspective of helping to understand the code you've written, and
    second addressing the "if this doesn't look like a good idea" angle.<br>
    <br>
    Let's examine what set_touch_variables does. set_touch_variables
    first determines which channel variables it needs to be looking at.
    Assuming you're using monitor and not mixmonitor, that means that it
    will look up the TOUCH_MONITOR_FORMAT, TOUCH_MONITOR, and
    TOUCH_MONITOR_PREFIX channel variables. It will place the values of
    each into the touch_monitor_format, touch_monitor, and
    touch_monitor_prefix local variables, respectively. In your case, it
    appears that touch_mointor_format ends up NULL, which most likely
    stems from the fact that the TOUCH_MONITOR_FORMAT variable is not
    set on the channel which was passed into set_touch_variables. So
    later when you start outputting your debug, since
    touch_monitor_format is NULL, the glibc print routines turn that
    into "(null)".<br>
    <br>
    Why don't you see the same thing happen in the res_monitor.c code?
    In that code, the ast_monitor_start() function requires a file
    format to be passed to it, and that format ends up getting set on
    the ast_monitor structure that gets created. That structure then
    gets set on the channel, and it can be later accessed by calling
    ast_channel_monitor(chan). When ast_monitor_stop() is called, it is
    able to get that saved format off the channel and use that for its
    post-processing. You could potentially do the same thing to get the
    file format by getting the value of
    ast_channel_monitor(chan)->format in your code.<br>
    <br>
    So now let's talk about whether your approach is the right one to
    take. One thing you may have noticed when doing your experimental
    coding is that the code that you copy/pasted comes from
    ast_monitor_stop(). ast_monitor_stop() is a C-level API call that is
    called by several places in the code, including in
    bridge_builtin_features.c when one-touch monitoring is stopped. This
    means, at least the way I see it, that the use of MONITOR_EXEC and
    MONITOR_EXEC_ARGS should already be in a position where they could
    "just work" with builtin automon. We can take a closer look at
    ast_monitor_stop() and see that the guard for determining if
    MONITOR_EXEC and MONITOR_EXEC_ARGS is used is:<br>
    <br>
        if (ast_channel_monitor(chan)->joinfiles &&
    !ast_strlen_zero(ast_channel_monitor(chan)->filename_base))<br>
    <br>
    If MONITOR_EXEC and MONITOR_EXEC_ARGS is currently not working, it
    is likely because one or both of these conditions are not met. Let's
    examine them one by one.<br>
    <br>
    ast_channel_monitor(chan)->joinfiles is a boolean that indicates
    if files should be joined together once recording is done. With the
    Monitor() application, this gets set true by setting the 'm' option
    (see start_monitor_exec() if you want to follow how that is done,
    specifically looking at MON_FLAG_MIX). Otherwise, though, this value
    is false. When ast_monitor_start() is called, it does not
    automatically set joinfiles to true. There is a function, though,
    called ast_monitor_setjoinfiles() you can use to set this value to
    true.<br>
    <br>
    ast_channel_monitor(chan)->filename_base is the base filename
    being used for monitor recordings. "base filename" means the
    filename minus the extra bits indicating the audio direction. The
    only reason this would not be set is if there were some catastrophic
    error. ast_strlen_zero() is a utility function that returns true if
    the input string is either NULL or zero-length. So since
    filename_base is almost certainly more than zero characters long,
    it's likely that ast_strlen_zero() of that is false, and negating
    that makes it true.<br>
    <br>
    Summary:<br>
    This probably means that you could get the functionality you desire
    by calling ast_monitor_setjoinfiles(chan, 1) after
    ast_monitor_start() in start_automonitor() of
    bridge_builtin_features.c. This approach would be better than
    copying/pasting because it keeps the code in one spot and makes use
    of already tested code.<br>
    <br>
    Hope this was helpful,<br>
    Mark Michelson<br>
  </body>
</html>