> On June 19, 2014, 3:56 p.m., Matt Jordan wrote:
> > /team/group/media_formats-reviewed/main/data.c, lines 3122-3126
> > <https://reviewboard.asterisk.org/r/3625/diff/1/?file=59757#file59757line3122>
> >
> >     Is/was fr_len used anywhere else?
> 
> Corey Farrell wrote:
>     fr_len is still referenced from res_rtp_asterisk in the call to 
> ast_smoother_new().  It was previously set by format_list_add_static and the 
> code that added celt/silk.
> 
> Matt Jordan wrote:
>     Hum hum hm. ast_smoother_new wants the number of bytes that a frame 
> produced for that format should have.
>     
>     Shouldn't that be 
> ast_format_get_sample_rate(fmt)/ast_format_get_default_ms(fmt)?
> 
> Corey Farrell wrote:
>     Nope.  sample_rate is number of samples per second, default ms is 
> milliseconds per frame.  Your equation for ulaw would be 8000/20 = 400, but 
> fr_len for ulaw was 80.
> 
> Matt Jordan wrote:
>     Drat. Unless Josh has an idea on how else to get this value, I'd guess 
> that we have to add it back.
> 
> Joshua Colp wrote:
>     Hum, we have to add it back but let's actually name it something sane. 
> "Frame length" is a bit overloaded. Format data size?
> 
> Corey Farrell wrote:
>     How about ast_codec->frame_bytes?  I believe this belongs to codec not 
> format.  I think data_size is ambiguous.  Without reading the comments or 
> just knowing you would question if the size is bytes or bits, and if the 
> period is a frame, sample, or second.  I like self-documenting code.
>     
>     Also are we changing the name used for ast_data_add_int?  I don't 
> personally use any of the features from this file so I don't know how 
> important backwards compatibility is.
> 
> Matt Jordan wrote:
>     Moment of completely honesty: the 'data' stuff is a little broken. I 
> remember playing around with it back in Asterisk 10 and finding that it seg 
> faulted more often than not when exporting data out of app_voicemail 
> (granted, it is app_voicemail).
>     
>     Even if that weren't the case, I'm not sure I agree with the idea that 
> exporting raw data structures out of Asterisk is the best way to expose 
> things to external consumers in the first place. Sure, I suppose it is 
> interesting to see what all the values of an ast_channel structure are: but 
> ... what do you do with it? It feels like an interesting intellectual 
> exercise that ended up complicating a lot of the Asterisk core.
>     
>     Maybe I'm missing something about the Data retrieval API and its intended 
> purpose, but I've yet to find (a) a user of Asterisk who uses it; or (b) what 
> it is super useful for.
>     
>

I agree completely.  I feel that the data retrieval API only serves to burn 
clock cycles and add risk through out the code base.  On the other hand it's a 
feature that has been exposed to end users, so I assume it needs to be updated. 
 I have no objection to saying "codecs are no longer exposed via data.c API" - 
if I'm told to do so.

I'd like to delete main/data.c and every block of code that uses it to make 
copies of data that is never used.  This would be based on my idea that 
unneeded complexity == unneeded risk. Unfortunately data.c was not deprecated 
in Asterisk 12, so I assume the most we can do is mark it deprecated for 
Asterisk 13 and scheduled for removal from Asterisk 14.  This feels like a 
discussion unrelated to media formats API, so if we are to pursue it maybe 
start a new thread on asterisk-dev.  A posting to asterisk-users might also be 
good, to seek out asterisk users who think they need the data retrieval API.


- Corey


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3625/#review12220
-----------------------------------------------------------


On June 19, 2014, 4:31 p.m., Corey Farrell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3625/
> -----------------------------------------------------------
> 
> (Updated June 19, 2014, 4:31 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Updates to allow most of the Asterisk core to compile.  I've excluded 
> main/channel.c, main/dsp.c and main/rtp_engine.c.  Changes to those files 
> will be posted separate since I feel they are more complex and likely to have 
> more error's.  If any of the files included in this review fit that 
> description let me know and I will split them off.
> 
> This change does not include any replacement for calls to 
> ast_format_is_slinear(), and adds it back to the header (but does not 
> implement).  So ast_format_is_slinear hasn't been fixed, just deferred to 
> become a link error.
> 
> The modifications to chan_phone are to allow what I believe to be a 
> comparability function to be in the correct namespace to be implemented in 
> format_compatibility.c.
> 
> 
> Diffs
> -----
> 
>   /team/group/media_formats-reviewed/main/stasis_channels.c 416235 
>   /team/group/media_formats-reviewed/main/sounds_index.c 416235 
>   /team/group/media_formats-reviewed/main/sorcery.c 416235 
>   /team/group/media_formats-reviewed/main/slinfactory.c 416235 
>   /team/group/media_formats-reviewed/main/media_index.c 416235 
>   /team/group/media_formats-reviewed/main/manager.c 416235 
>   /team/group/media_formats-reviewed/main/indications.c 416235 
>   /team/group/media_formats-reviewed/main/image.c 416235 
>   /team/group/media_formats-reviewed/main/frame.c 416235 
>   /team/group/media_formats-reviewed/main/format_pref.c 416235 
>   /team/group/media_formats-reviewed/main/format_compatibility.c 416235 
>   /team/group/media_formats-reviewed/main/format.c 416235 
>   /team/group/media_formats-reviewed/main/file.c 416235 
>   /team/group/media_formats-reviewed/main/dial.c 416235 
>   /team/group/media_formats-reviewed/main/data.c 416235 
>   /team/group/media_formats-reviewed/main/core_unreal.c 416235 
>   /team/group/media_formats-reviewed/main/core_local.c 416235 
>   /team/group/media_formats-reviewed/main/codec.c 416235 
>   /team/group/media_formats-reviewed/include/asterisk/slinfactory.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/rtp_engine.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/format_pref.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/format_compatibility.h 
> 416235 
>   /team/group/media_formats-reviewed/include/asterisk/format_cache.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/format.h 416235 
>   /team/group/media_formats-reviewed/include/asterisk/file.h 416235 
>   /team/group/media_formats-reviewed/channels/chan_phone.c 416235 
> 
> Diff: https://reviewboard.asterisk.org/r/3625/diff/
> 
> 
> Testing
> -------
> 
> Compiled.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to