search for: float_api

...31320, out_data_bytes at entry=5988, lsb_depth=1065353216, lsb_depth at entry=16, analysis_pcm=analysis_pcm at entry=0x7f26b5a1084c, analysis_size=analysis_size at entry=960, c1=c1 at entry=0, c2=c2 at entry=-2, analysis_channels=1, downmix=downmix at entry=0xa80fe0 <downmix_int>, float_api=float_api at entry=0) at src/opus_encoder.c:1826 #5 0x0000000000a85211 in opus_encode (st=0x158935a0, pcm=0x7f26b5a1084c, analysis_frame_size=960, data=0x7f26b5a1084c "", max_data_bytes=5988) at src/opus_encoder.c:2227 #6 0x00000000004ce892 in opus_encoder::transcode (this=0x21a3020...

...depth=1065353216, lsb_depth at entry=16, >> analysis_pcm=analysis_pcm at entry=0x7f26b5a1084c, >> analysis_size=analysis_size at entry=960, c1=c1 at entry=0, >> c2=c2 at entry=-2, analysis_channels=1, >> downmix=downmix at entry=0xa80fe0 <downmix_int>, >> float_api=float_api at entry=0) at src/opus_encoder.c:1826 >> #5 0x0000000000a85211 in opus_encode (st=0x158935a0, >> pcm=0x7f26b5a1084c, analysis_frame_size=960, >> data=0x7f26b5a1084c "", max_data_bytes=5988) at src/opus_encoder.c:2227 >> #6 0x00000000004ce892 in opu...

...ED 8kHz 2 1150 1000ms 1014ms + 147ms = 1181ms FIXED 8kHz 1 1150 1000ms 1086ms + 135ms = 1241ms FIXED 8kHz 1 1150 10000ms 11206ms + 1318ms = 12544ms H. Build Options FLOAT: OPUS_BUILD,USE_ALLOCA,CUSTOM_SUPPORT FIXED: OPUS_BUILD,USE_ALLOCA,CUSTOM_SUPPORT,FIXED_POINT,DISABLE_FLOAT_API Note: the target bit rate is twice of the sampling frequency. That's to say, the bit rate will be 96kbps, if the sampling frequency is 48kHz. The CPU usage is about 91% (911ms/1000ms), when decode 48KHz/mono/96bps. but encode requires more CPU (132%, 1312/1000ms). I will try lower bit rate...

...=5988, >     lsb_depth=1065353216, lsb_depth at entry=16, > analysis_pcm=analysis_pcm at entry=0x7f26b5a1084c, >     analysis_size=analysis_size at entry=960, c1=c1 at entry=0, > c2=c2 at entry=-2, analysis_channels=1, >     downmix=downmix at entry=0xa80fe0 <downmix_int>, > float_api=float_api at entry=0) at src/opus_encoder.c:1826 > #5  0x0000000000a85211 in opus_encode (st=0x158935a0, > pcm=0x7f26b5a1084c, analysis_frame_size=960, >     data=0x7f26b5a1084c "", max_data_bytes=5988) at src/opus_encoder.c:2227 > #6  0x00000000004ce892 in opus_encoder::trans...

On Wed, Jun 4, 2014 at 4:31 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Alpha Thinktink wrote: >> max_data_bytes=-11 > > That value is passed in by you. I also don't think passing such a value > would have worked in earlier releases. It indicates the size of the > buffer you are passing to the encoder to receive the encoded output. Actually, I'm

...ugh CMakeLists.txt I figured out that I need to specify -DOPUS_BUILD_PROGRAMS=ON. Is it possible to make BUILD_TESTING and BUILD_PROGRAMS consistent? Also the output of cmake is misleading, as it says BUILD_PROGRAMS not OPUS_BUILD_PROGRAMS. For some settings it is even worse; for example it says FLOAT_API but the actual -D option that needs to be used to change that setting is -DOPUS_ENABLE_FLOAT_API=OFF. Can these be made consistent as well? There also seems to be several configure options (see ./configure --help) that have no equivalent, including --enable-assertions, --disable-asm, --disable-in...

...int lsb_depth, > + int c1, > + int c2, > + int analysis_channels, > + downmix_func downmix, > + int float_api) I understand that this was split out into a separate function originally because you wanted to call it twice, but now that you have merged the two calls is there still a need for it to be split out into a separate function? If it had a simple and concise interface then it may make sense even wit...

...left curr_max at -13 The result at line 853 is opus_encode_native is called with parameters so thusly: (encoder state pointer, buf pointer, frame_size=960, tmp_data pointer, curr_max=-13, lsb_depth=24, pcm pointer, analysis_frame_size=960, c1=0, c2=-1, st->layout.nb_channels=4, downmix pointer, float_api=1); I don't know what to suggest as I've never tinkered with the opus library internals, nor have I ever compiled it before today and do not know what it looked like in previous versions. Sorry.

...; The result at line 853 is opus_encode_native is called with parameters > so thusly: > (encoder state pointer, buf pointer, frame_size=960, tmp_data pointer, > curr_max=-13, lsb_depth=24, pcm pointer, analysis_frame_size=960, > c1=0, c2=-1, st->layout.nb_channels=4, downmix pointer, float_api=1); > > > I don't know what to suggest as I've never tinkered with the opus > library internals, nor have I ever compiled it before today and do not > know what it looked like in previous versions. Sorry. > _______________________________________________ > opus maili...

...>> > + int c1, >> > + int c2, >> > + int analysis_channels, >> > + downmix_func downmix, >> > + int float_api) >> >> I understand that this was split out into a separate function >> originally because you wanted to call it twice, but now that you have >> merged the two calls is there still a need for it to be split out into >> a separate function? If it had a simple and conci...

...int c1, > >>> > + int c2, > >>> > + int analysis_channels, > >>> > + downmix_func downmix, > >>> > + int float_api) > >>> > >>> I understand that this was split out into a separate function > >>> originally because you wanted to call it twice, but now that you have > >>> merged the two calls is there still a need for it to be split out into > >>> a sep...

...int lsb_depth, > > + int c1, > > + int c2, > > + int analysis_channels, > > + downmix_func downmix, > > + int float_api) > > I understand that this was split out into a separate function > originally because you wanted to call it twice, but now that you have > merged the two calls is there still a need for it to be split out into > a separate function? If it had a simple and concise interface then it...

...int c1, >>> > + int c2, >>> > + int analysis_channels, >>> > + downmix_func downmix, >>> > + int float_api) >>> >>> I understand that this was split out into a separate function >>> originally because you wanted to call it twice, but now that you have >>> merged the two calls is there still a need for it to be split out into >>> a separate function? If it ha...

Hi, I wondered if are there any further thoughts on these patches? Thanks, Felicia On Thu, Jun 2, 2016 at 2:13 PM Felicia Lim <flim at google.com> wrote: > OK, I've amended the second patch and also added 80 and 100 ms. > > Thanks, > Felicia > > > On Thu, Jun 2, 2016 at 7:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> On 06/01/2016 02:06

On Wed, Apr 10, 2019 at 5:30 PM Marcus Asteborg <xnorpx at outlook.com> wrote: > Hi Mark, > > Thanks for the feedback. > > By default CMake is building the static library in debug, to get other > things one has to explicit turn it on. > > Hi, By default CMake uses the "empty" build, which is used in combination with the environment variables CFLAGS and