Menu
▾
▴
sox-devel
|
From: Jaromír M. <mir...@gm...> - 2017-11-04 09:47:02
|
Hi sox devs, I am thinking to adopt sox package in debian and maintain it in debian pkg-multimedia team. There are couple of bugs reported in debian against sox package. https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sox Especially CVE bugs needs to be fixed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878808 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878809 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878810 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870328 Please let me know if you can provide patches for these fixes or make new release to fix these issues. best regards mira |
|
From: Eric W. <nor...@yh...> - 2017-11-04 18:43:26
|
Jaromír Mikeš <mir...@gm...> wrote: > Please let me know if you can provide patches for these fixes > or make new release to fix these issues. Thanks for the email. I guess neither Mans or I pay attention to the bugtrackers :x, and the original developers are busy. (and I don't like web-based UIs) Anyways, I'll try to take a look at the CVEs this weekend or next week, at latest. |
|
From: Måns R. <ma...@ma...> - 2017-11-04 20:10:55
|
Eric Wong <nor...@yh...> writes: > Jaromír Mikeš <mir...@gm...> wrote: >> Please let me know if you can provide patches for these fixes >> or make new release to fix these issues. > > Thanks for the email. I guess neither Mans or I pay attention > to the bugtrackers :x, and the original developers are busy. > (and I don't like web-based UIs) > > Anyways, I'll try to take a look at the CVEs this weekend or next > week, at latest. I started looking at them today. At least some of them seem easy to fix. -- Måns Rullgård |
|
From: Jaromír M. <mir...@gm...> - 2017-11-04 20:43:17
|
2017-11-04 21:10 GMT+01:00 Måns Rullgård <ma...@ma...>: > Eric Wong <nor...@yh...> writes: > > > Jaromír Mikeš <mir...@gm...> wrote: > >> Please let me know if you can provide patches for these fixes > >> or make new release to fix these issues. > > > > Thanks for the email. I guess neither Mans or I pay attention > > to the bugtrackers :x, and the original developers are busy. > > (and I don't like web-based UIs) > > > > Anyways, I'll try to take a look at the CVEs this weekend or next > > week, at latest. > > I started looking at them today. At least some of them seem easy to > fix. > Thank you Eric and Mans for quick answer ... let me informed please about progress. Good to hear that at least some CVE are not difficult best regards mira |
|
From: Jaromír M. <mir...@gm...> - 2017-11-05 01:40:56
Attachments:
0003-spelling.patch
|
2017-11-04 21:43 GMT+01:00 Jaromír Mikeš <mir...@gm...>: > > > 2017-11-04 21:10 GMT+01:00 Måns Rullgård <ma...@ma...>: > >> Eric Wong <nor...@yh...> writes: >> >> > Jaromír Mikeš <mir...@gm...> wrote: >> >> Please let me know if you can provide patches for these fixes >> >> or make new release to fix these issues. >> > >> > Thanks for the email. I guess neither Mans or I pay attention >> > to the bugtrackers :x, and the original developers are busy. >> > (and I don't like web-based UIs) >> > >> > Anyways, I'll try to take a look at the CVEs this weekend or next >> > week, at latest. >> >> I started looking at them today. At least some of them seem easy to >> fix. >> > > Thank you Eric and Mans for quick answer ... let me informed please about > progress. > Good to hear that at least some CVE are not difficult > While I am playing a little bit with sox package debian spell checking tool find some spelling errors in sox source code. You might be interested apply attached patch upstream. Hope attachments are allowed in mailing list best regards mira |
|
From: Måns R. <ma...@ma...> - 2017-11-05 12:32:18
|
Jaromír Mikeš <mir...@gm...> writes: > 2017-11-04 21:43 GMT+01:00 Jaromír Mikeš <mir...@gm...>: > >> >> >> 2017-11-04 21:10 GMT+01:00 Måns Rullgård <ma...@ma...>: >> >>> Eric Wong <nor...@yh...> writes: >>> >>> > Jaromír Mikeš <mir...@gm...> wrote: >>> >> Please let me know if you can provide patches for these fixes >>> >> or make new release to fix these issues. >>> > >>> > Thanks for the email. I guess neither Mans or I pay attention >>> > to the bugtrackers :x, and the original developers are busy. >>> > (and I don't like web-based UIs) >>> > >>> > Anyways, I'll try to take a look at the CVEs this weekend or next >>> > week, at latest. >>> >>> I started looking at them today. At least some of them seem easy to >>> fix. >>> >> >> Thank you Eric and Mans for quick answer ... let me informed please about >> progress. >> Good to hear that at least some CVE are not difficult >> > > While I am playing a little bit with sox package debian spell checking > tool find some spelling errors in sox source code. > You might be interested apply attached patch upstream. > Hope attachments are allowed in mailing list Thanks. Next time, however, please send git-formatted patches based on the latest revision. Some of the mistakes in your patch had already been fixed. -- Måns Rullgård |
|
From: Jaromír M. <mir...@gm...> - 2017-11-05 15:03:49
|
2017-11-05 13:32 GMT+01:00 Måns Rullgård <ma...@ma...>: > Jaromír Mikeš <mir...@gm...> writes: > > > > While I am playing a little bit with sox package debian spell checking > > tool find some spelling errors in sox source code. > > You might be interested apply attached patch upstream. > > Hope attachments are allowed in mailing list > > Thanks. Next time, however, please send git-formatted patches based on > the latest revision. Some of the mistakes in your patch had already > been fixed. > Ohh yes ... sorry about that. Now I updated to latest version ... but build failed due this error: /bin/bash ../libtool --silent --tag=CC --silent --mode=link gcc -Wtraditional-conversion -g -O2 -fdebug-prefix-map=/build/sox-14.4.2=. -fstack-protector-strong -Wformat -Werror=format-security -fstack-protector -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp -avoid-version -module -Wl,-z,relro -Wl,-z,defs -o libsox_fmt_gsm.la -rpath /usr/lib/x86_64-linux-gnu/sox gsm.lo libsox.la -lgsm -lm .libs/flac.o: In function `decoder_read_callback': ./src/flac.c:63: undefined reference to `lsx_error' collect2: error: ld returned 1 exit status Makefile:1284: recipe for target 'libsox_fmt_flac.la' failed make[3]: *** [libsox_fmt_flac.la] Error 1 Can you help me to fix it please? best regards mira |
|
From: Måns R. <ma...@ma...> - 2017-11-05 15:43:04
|
Jaromír Mikeš <mir...@gm...> writes: > 2017-11-05 13:32 GMT+01:00 Måns Rullgård <ma...@ma...>: > >> Jaromír Mikeš <mir...@gm...> writes: >> > >> > While I am playing a little bit with sox package debian spell checking >> > tool find some spelling errors in sox source code. >> > You might be interested apply attached patch upstream. >> > Hope attachments are allowed in mailing list >> >> Thanks. Next time, however, please send git-formatted patches based on >> the latest revision. Some of the mistakes in your patch had already >> been fixed. >> > > Ohh yes ... sorry about that. > Now I updated to latest version ... but build failed due this error: > > /bin/bash ../libtool --silent --tag=CC --silent --mode=link gcc > -Wtraditional-conversion -g -O2 -fdebug-prefix-map=/build/sox-14.4.2=. > -fstack-protector-strong -Wformat -Werror=format-security -fstack-protector > -Wall -W -Wmissing-prototypes -Wstrict-prototypes -pedantic -fopenmp > -avoid-version -module -Wl,-z,relro -Wl,-z,defs -o libsox_fmt_gsm.la -rpath > /usr/lib/x86_64-linux-gnu/sox gsm.lo libsox.la -lgsm -lm > .libs/flac.o: In function `decoder_read_callback': > ./src/flac.c:63: undefined reference to `lsx_error' > collect2: error: ld returned 1 exit status > Makefile:1284: recipe for target 'libsox_fmt_flac.la' failed > make[3]: *** [libsox_fmt_flac.la] Error 1 > > Can you help me to fix it please? https://github.com/mansr/sox/commit/600c291ab00f4afb2941cd93f69942fe395f3e8a -- Måns Rullgård |
|
From: Måns R. <ma...@ma...> - 2017-11-05 17:12:35
|
Jaromír Mikeš <mir...@gm...> writes: > Hi sox devs, > > I am thinking to adopt sox package in debian and maintain it in debian > pkg-multimedia team. > There are couple of bugs reported in debian against sox package. > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sox > > Especially CVE bugs needs to be fixed > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878808 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878809 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878810 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870328 > > Please let me know if you can provide patches for these fixes > or make new release to fix these issues. All but one fixed here: https://github.com/mansr/sox -- Måns Rullgård |
|
From: Jaromír M. <mir...@gm...> - 2017-11-05 17:19:49
Attachments:
0003-spelling.patch
|
2017-11-05 18:12 GMT+01:00 Måns Rullgård <ma...@ma...>: > Jaromír Mikeš <mir...@gm...> writes: > > > Hi sox devs, > > > > I am thinking to adopt sox package in debian and maintain it in debian > > pkg-multimedia team. > > There are couple of bugs reported in debian against sox package. > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sox > > > > Especially CVE bugs needs to be fixed > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878808 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878809 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878810 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870328 > > > > Please let me know if you can provide patches for these fixes > > or make new release to fix these issues. > > All but one fixed here: https://github.com/mansr/sox > Thank you ... you are super quick! There is one more spelling fix in 0.14.2 release in src/wav.c see attached file best regards mira |
|
From: Jaromír M. <mir...@gm...> - 2017-11-05 22:37:33
|
2017-11-05 18:19 GMT+01:00 Jaromír Mikeš <mir...@gm...>: > > > 2017-11-05 18:12 GMT+01:00 Måns Rullgård <ma...@ma...>: > >> Jaromír Mikeš <mir...@gm...> writes: >> >> > Hi sox devs, >> > >> > I am thinking to adopt sox package in debian and maintain it in debian >> > pkg-multimedia team. >> > There are couple of bugs reported in debian against sox package. >> > >> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sox >> > >> > Especially CVE bugs needs to be fixed >> > >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878808 >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878809 >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878810 >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870328 >> > >> > Please let me know if you can provide patches for these fixes >> > or make new release to fix these issues. >> >> All but one fixed here: https://github.com/mansr/sox >> > Mans I have a question about lpc10 we have this lib in debian so I would rather build sox against system wide lib than embedded. But when add it as build dependency it is still marked as embedded during configuration. lpc10......................dyn (in-tree) Similar about opus I am building with libopus-dev installed but I see this opus.......................no And what about ffmpeg? it is not needed any more? best regards mira |
|
From: Eric W. <nor...@yh...> - 2017-11-07 01:14:32
|
Måns Rullgård <ma...@ma...> wrote: > All but one fixed here: https://github.com/mansr/sox I think this should fix the last one. I didn't check too closely, just verified it's no longer segfaulting. (But lsx_valloc doesn't check for multiplication overflow) -----------8<--------- From: Eric Wong <e...@80...> Subject: [PATCH] adpcm: fix stack overflow (CVE-2017-15372) --- src/adpcm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/adpcm.c b/src/adpcm.c index 2e13867e..e921eaba 100644 --- a/src/adpcm.c +++ b/src/adpcm.c @@ -113,7 +113,10 @@ const char *lsx_ms_adpcm_block_expand_i( const unsigned char *ip; unsigned ch; const char *errmsg = NULL; - MsState_t state[4]; /* One decompressor state for each channel */ + MsState_t *state; + + /* One decompressor state for each channel */ + lsx_valloc(state, chans); /* Read the four-byte header for each channel */ ip = ibuff; -- EW |
|
From: Måns R. <ma...@ma...> - 2017-11-07 09:26:45
|
Eric Wong <nor...@yh...> writes: > Måns Rullgård <ma...@ma...> wrote: >> All but one fixed here: https://github.com/mansr/sox > > I think this should fix the last one. I didn't check too > closely, just verified it's no longer segfaulting. > > (But lsx_valloc doesn't check for multiplication overflow) > > -----------8<--------- > From: Eric Wong <e...@80...> > Subject: [PATCH] adpcm: fix stack overflow (CVE-2017-15372) > > --- > src/adpcm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/src/adpcm.c b/src/adpcm.c > index 2e13867e..e921eaba 100644 > --- a/src/adpcm.c > +++ b/src/adpcm.c > @@ -113,7 +113,10 @@ const char *lsx_ms_adpcm_block_expand_i( > const unsigned char *ip; > unsigned ch; > const char *errmsg = NULL; > - MsState_t state[4]; /* One decompressor state for each channel */ > + MsState_t *state; > + > + /* One decompressor state for each channel */ > + lsx_valloc(state, chans); > > /* Read the four-byte header for each channel */ > ip = ibuff; This will leak memory like crazy. I'd prefer not to do a malloc/free for each block, but rather do it just once. This will require a little more work, of course. -- Måns Rullgård |
|
From: Jaromír M. <mir...@gm...> - 2017-11-07 09:42:07
|
2017-11-07 10:26 GMT+01:00 Måns Rullgård <ma...@ma...>: > Eric Wong <nor...@yh...> writes: > > > Måns Rullgård <ma...@ma...> wrote: > >> All but one fixed here: https://github.com/mansr/sox > > > > I think this should fix the last one. I didn't check too > > closely, just verified it's no longer segfaulting. > > > > (But lsx_valloc doesn't check for multiplication overflow) > > > > -----------8<--------- > > From: Eric Wong <e...@80...> > > Subject: [PATCH] adpcm: fix stack overflow (CVE-2017-15372) > > > > --- > > src/adpcm.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/src/adpcm.c b/src/adpcm.c > > index 2e13867e..e921eaba 100644 > > --- a/src/adpcm.c > > +++ b/src/adpcm.c > > @@ -113,7 +113,10 @@ const char *lsx_ms_adpcm_block_expand_i( > > const unsigned char *ip; > > unsigned ch; > > const char *errmsg = NULL; > > - MsState_t state[4]; /* One decompressor state for each channel */ > > + MsState_t *state; > > + > > + /* One decompressor state for each channel */ > > + lsx_valloc(state, chans); > > > > /* Read the four-byte header for each channel */ > > ip = ibuff; > > This will leak memory like crazy. > > I'd prefer not to do a malloc/free for each block, but rather do it just > once. This will require a little more work, of course. > Hi, good to know I will wait for better fix then. BTW I moved debian packaging here if you are interested: https://anonscm.debian.org/git/pkg-multimedia/sox.git I think it is better than do it in sourceforge upstream repo. best regrads mira |
|
From: Måns R. <ma...@ma...> - 2017-11-07 09:53:40
|
Jaromír Mikeš <mir...@gm...> writes: > BTW I moved debian packaging here if you are interested: > https://anonscm.debian.org/git/pkg-multimedia/sox.git > > I think it is better than do it in sourceforge upstream repo. Yes, that's better handled separately by each distro. -- Måns Rullgård |
|
From: Eric W. <nor...@yh...> - 2017-11-07 17:54:47
|
Måns Rullgård <ma...@ma...> wrote: > This will leak memory like crazy. You're right. I somehow got spoiled into thinking it was alloca-like from another project :x. > I'd prefer not to do a malloc/free for each block, but rather do it just > once. This will require a little more work, of course. Yes, it should be in the per-stream private data. Will work on it later today if you're busy. |
|
From: Måns R. <ma...@ma...> - 2017-11-07 18:13:00
|
Eric Wong <nor...@yh...> writes: > Måns Rullgård <ma...@ma...> wrote: >> This will leak memory like crazy. > > You're right. I somehow got spoiled into thinking it was > alloca-like from another project :x. Never use such functions. They are dangerous. >> I'd prefer not to do a malloc/free for each block, but rather do it just >> once. This will require a little more work, of course. > > Yes, it should be in the per-stream private data. Will work on > it later today if you're busy. OK, I'll leave it to you then. -- Måns Rullgård |
|
From: Eric W. <nor...@yh...> - 2017-11-07 23:37:58
|
Måns Rullgård <ma...@ma...> wrote: > Eric Wong <nor...@yh...> writes: > > > Måns Rullgård <ma...@ma...> wrote: > >> This will leak memory like crazy. > > > > You're right. I somehow got spoiled into thinking it was > > alloca-like from another project :x. > > Never use such functions. They are dangerous. If it were alloca-only, yes. The macro I was thinking of relied on GC for larger allocations; and only used alloca for small ones. > >> I'd prefer not to do a malloc/free for each block, but rather do it just > >> once. This will require a little more work, of course. > > > > Yes, it should be in the per-stream private data. Will work on > > it later today if you're busy. > > OK, I'll leave it to you then. So I didn't want to mess with the lsx_ms_adpcm_block_expand_i signature for now. I've made it use alloca for <= 1024 uses and it'll only use the slow malloc+free path for the rare 128+ channel audio files. |
|
From: Eric W. <nor...@yh...> - 2017-11-07 23:38:30
|
---
src/adpcm.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/adpcm.c b/src/adpcm.c
index 2e13867e..b400eb95 100644
--- a/src/adpcm.c
+++ b/src/adpcm.c
@@ -113,7 +113,13 @@ const char *lsx_ms_adpcm_block_expand_i(
const unsigned char *ip;
unsigned ch;
const char *errmsg = NULL;
- MsState_t state[4]; /* One decompressor state for each channel */
+
+ /* One decompressor state for each channel */
+ MsState_t *state;
+ size_t size = sizeof(*state) * chans;
+ const size_t alloca_max = 1024;
+
+ state = size > alloca_max ? lsx_malloc(size) : alloca(size);
/* Read the four-byte header for each channel */
ip = ibuff;
@@ -158,6 +164,10 @@ const char *lsx_ms_adpcm_block_expand_i(
if (++ch2 == chans) ch2 = 0;
}
}
+
+ if (size > alloca_max)
+ free(state);
+
return errmsg;
}
--
EW
|
|
From: Måns R. <ma...@ma...> - 2017-11-07 23:43:30
|
Eric Wong <nor...@yh...> writes: > Måns Rullgård <ma...@ma...> wrote: >> Eric Wong <nor...@yh...> writes: >> >> > Måns Rullgård <ma...@ma...> wrote: >> >> This will leak memory like crazy. >> > >> > You're right. I somehow got spoiled into thinking it was >> > alloca-like from another project :x. >> >> Never use such functions. They are dangerous. > > If it were alloca-only, yes. The macro I was thinking of relied > on GC for larger allocations; and only used alloca for small ones. > >> >> I'd prefer not to do a malloc/free for each block, but rather do it just >> >> once. This will require a little more work, of course. >> > >> > Yes, it should be in the per-stream private data. Will work on >> > it later today if you're busy. >> >> OK, I'll leave it to you then. > > So I didn't want to mess with the lsx_ms_adpcm_block_expand_i > signature for now. I've made it use alloca for <= 1024 uses > and it'll only use the slow malloc+free path for the rare > 128+ channel audio files. I really don't want to use alloca(). It is non-standard, non-portable, somewhat dangerous, and messes with compiler optimisation. There is nothing good about it. Guess I'll have to do it myself. -- Måns Rullgård |
|
From: Eric W. <nor...@yh...> - 2017-11-07 23:55:22
|
Måns Rullgård <ma...@ma...> wrote: > I really don't want to use alloca(). It is non-standard, non-portable, > somewhat dangerous, and messes with compiler optimisation. There is > nothing good about it. Guess I'll have to do it myself. One could also use thread-specific data to avoid messing with the signature. I don't know if that's too much churn and don't care that much as long as the problem is fixed. Thanks. |
|
From: Måns R. <ma...@ma...> - 2017-11-07 23:58:38
|
Eric Wong <nor...@yh...> writes: F> Måns Rullgård <ma...@ma...> wrote: >> I really don't want to use alloca(). It is non-standard, non-portable, >> somewhat dangerous, and messes with compiler optimisation. There is >> nothing good about it. Guess I'll have to do it myself. > > One could also use thread-specific data to avoid messing with the > signature. I don't know if that's too much churn and don't care > that much as long as the problem is fixed. I'll fix it. -- Måns Rullgård |
|
From: Mans R. <ma...@ma...> - 2017-11-08 00:29:39
|
---
src/adpcm.c | 8 +++++++-
src/adpcm.h | 3 +++
src/wav.c | 5 ++++-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/adpcm.c b/src/adpcm.c
index 2e13867e94b0..f64b7d5c2787 100644
--- a/src/adpcm.c
+++ b/src/adpcm.c
@@ -71,6 +71,11 @@ const short lsx_ms_adpcm_i_coef[7][2] = {
{ 392,-232}
};
+extern void *lsx_ms_adpcm_alloc(unsigned chans)
+{
+ return lsx_malloc(chans * sizeof(MsState_t));
+}
+
static inline sox_sample_t AdpcmDecode(sox_sample_t c, MsState_t *state,
sox_sample_t sample1, sox_sample_t sample2)
{
@@ -102,6 +107,7 @@ static inline sox_sample_t AdpcmDecode(sox_sample_t c, MsState_t *state,
/* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */
const char *lsx_ms_adpcm_block_expand_i(
+ void *priv,
unsigned chans, /* total channels */
int nCoef,
const short *coef,
@@ -113,7 +119,7 @@ const char *lsx_ms_adpcm_block_expand_i(
const unsigned char *ip;
unsigned ch;
const char *errmsg = NULL;
- MsState_t state[4]; /* One decompressor state for each channel */
+ MsState_t *state = priv; /* One decompressor state for each channel */
/* Read the four-byte header for each channel */
ip = ibuff;
diff --git a/src/adpcm.h b/src/adpcm.h
index af4d6f08117d..db5cc6152196 100644
--- a/src/adpcm.h
+++ b/src/adpcm.h
@@ -29,8 +29,11 @@
/* default coef sets */
extern const short lsx_ms_adpcm_i_coef[7][2];
+extern void *lsx_ms_adpcm_alloc(unsigned chans);
+
/* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */
extern const char *lsx_ms_adpcm_block_expand_i(
+ void *priv,
unsigned chans, /* total channels */
int nCoef,
const short *coef,
diff --git a/src/wav.c b/src/wav.c
index fad334cf56e9..066be6d7732d 100644
--- a/src/wav.c
+++ b/src/wav.c
@@ -82,6 +82,7 @@ typedef struct {
/* following used by *ADPCM wav files */
unsigned short nCoefs; /* ADPCM: number of coef sets */
short *lsx_ms_adpcm_i_coefs; /* ADPCM: coef sets */
+ void *ms_adpcm_data; /* Private data of adpcm decoder */
unsigned char *packet; /* Temporary buffer for packets */
short *samples; /* interleaved samples buffer */
short *samplePtr; /* Pointer to current sample */
@@ -175,7 +176,7 @@ static unsigned short AdpcmReadBlock(sox_format_t * ft)
}
}
- errmsg = lsx_ms_adpcm_block_expand_i(ft->signal.channels, wav->nCoefs, wav->lsx_ms_adpcm_i_coefs, wav->packet, wav->samples, samplesThisBlock);
+ errmsg = lsx_ms_adpcm_block_expand_i(wav->ms_adpcm_data, ft->signal.channels, wav->nCoefs, wav->lsx_ms_adpcm_i_coefs, wav->packet, wav->samples, samplesThisBlock);
if (errmsg)
lsx_warn("%s", errmsg);
@@ -791,6 +792,7 @@ static int startread(sox_format_t * ft)
/* nCoefs, lsx_ms_adpcm_i_coefs used by adpcm.c */
wav->lsx_ms_adpcm_i_coefs = lsx_malloc(wav->nCoefs * 2 * sizeof(short));
+ wav->ms_adpcm_data = lsx_ms_adpcm_alloc(wChannels);
{
int i, errct=0;
for (i=0; len>=2 && i < 2*wav->nCoefs; i++) {
@@ -1216,6 +1218,7 @@ static int stopread(sox_format_t * ft)
free(wav->packet);
free(wav->samples);
free(wav->lsx_ms_adpcm_i_coefs);
+ free(wav->ms_adpcm_data);
free(wav->comment);
wav->comment = NULL;
--
2.15.0
|
|
From: Eric W. <nor...@yh...> - 2017-11-08 00:42:24
|
Mans Rullgard <ma...@ma...> wrote: > --- a/src/adpcm.h > +++ b/src/adpcm.h > @@ -29,8 +29,11 @@ > /* default coef sets */ > extern const short lsx_ms_adpcm_i_coef[7][2]; > > +extern void *lsx_ms_adpcm_alloc(unsigned chans); > + > /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */ > extern const char *lsx_ms_adpcm_block_expand_i( > + void *priv, > unsigned chans, /* total channels */ > int nCoef, > const short *coef, Thanks, seems fine; though I'd probably export an opaque struct which makes the unsigned chans arg redundant. I'm a little concerned about the internal API changes like this affecting some 3rd-party code somewhere; but I guess we limit our exports nowadays (ugh, and that export regexp is nasty) |
|
From: Måns R. <ma...@ma...> - 2017-11-08 00:53:06
|
Eric Wong <nor...@yh...> writes: > Mans Rullgard <ma...@ma...> wrote: >> --- a/src/adpcm.h >> +++ b/src/adpcm.h >> @@ -29,8 +29,11 @@ >> /* default coef sets */ >> extern const short lsx_ms_adpcm_i_coef[7][2]; >> >> +extern void *lsx_ms_adpcm_alloc(unsigned chans); >> + >> /* lsx_ms_adpcm_block_expand_i() outputs interleaved samples into one output buffer */ >> extern const char *lsx_ms_adpcm_block_expand_i( >> + void *priv, >> unsigned chans, /* total channels */ >> int nCoef, >> const short *coef, > > Thanks, seems fine; though I'd probably export an opaque struct > which makes the unsigned chans arg redundant. Do you mean to store the number of channels as well as the state buffer in a struct? > I'm a little concerned about the internal API changes like this > affecting some 3rd-party code somewhere; but I guess we limit > our exports nowadays (ugh, and that export regexp is nasty) These functions aren't exported, and the supported interface is whatever is in sox.h, nothing else. -- Måns Rullgård |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X