> On June 19, 2014, 2: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.
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. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3625/#review12220 ----------------------------------------------------------- On June 19, 2014, 3: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, 3: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
