You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(147) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(278) |
Feb
(171) |
Mar
(37) |
Apr
(89) |
May
(175) |
Jun
(44) |
Jul
(62) |
Aug
(26) |
Sep
(94) |
Oct
(53) |
Nov
(44) |
Dec
(19) |
2008 |
Jan
(56) |
Feb
(49) |
Mar
(54) |
Apr
(40) |
May
(9) |
Jun
(42) |
Jul
(188) |
Aug
(88) |
Sep
(64) |
Oct
(133) |
Nov
(96) |
Dec
(39) |
2009 |
Jan
(20) |
Feb
(65) |
Mar
(26) |
Apr
(43) |
May
(33) |
Jun
(29) |
Jul
(24) |
Aug
(25) |
Sep
(125) |
Oct
(29) |
Nov
(12) |
Dec
(53) |
2010 |
Jan
(11) |
Feb
(6) |
Mar
(2) |
Apr
(5) |
May
(13) |
Jun
(6) |
Jul
(5) |
Aug
(20) |
Sep
(8) |
Oct
(3) |
Nov
(8) |
Dec
(9) |
2011 |
Jan
(27) |
Feb
(92) |
Mar
(81) |
Apr
(13) |
May
(13) |
Jun
(5) |
Jul
(12) |
Aug
(13) |
Sep
(18) |
Oct
(42) |
Nov
(8) |
Dec
(41) |
2012 |
Jan
(58) |
Feb
(30) |
Mar
(75) |
Apr
(19) |
May
(53) |
Jun
(16) |
Jul
(4) |
Aug
(17) |
Sep
(4) |
Oct
(29) |
Nov
(24) |
Dec
(16) |
2013 |
Jan
(61) |
Feb
(96) |
Mar
(21) |
Apr
(13) |
May
(4) |
Jun
|
Jul
(3) |
Aug
(15) |
Sep
(13) |
Oct
(1) |
Nov
(1) |
Dec
(9) |
2014 |
Jan
(7) |
Feb
(8) |
Mar
(2) |
Apr
(7) |
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(2) |
Dec
(11) |
2015 |
Jan
(2) |
Feb
(13) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(11) |
Oct
(6) |
Nov
(4) |
Dec
(25) |
2016 |
Jan
(18) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(4) |
Jul
(6) |
Aug
|
Sep
(14) |
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(57) |
Dec
|
2018 |
Jan
|
Feb
(2) |
Mar
(13) |
Apr
(34) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(2) |
Nov
(3) |
Dec
(1) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
(8) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
(5) |
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(24) |
Aug
(148) |
Sep
(16) |
Oct
|
Nov
(2) |
Dec
(1) |
2021 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(5) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Eric W. <nor...@yh...> - 2023-02-18 09:20:15
|
ping? |
From: Jan S. <ha...@st...> - 2023-02-13 20:13:03
|
On Feb 13 14:50:41, ha...@st... wrote: > On Feb 13 14:02:34, ha...@st... wrote: > > On Feb 07 14:20:42, ma...@ma... wrote: > > > > Also, last release was 8 years ago. Piling the patches > > > > is starting to get cubersome when packaging downstream > > > > - are there any plans for a release? > > > > > > I can slap a tag on the git repo and call it a day if that makes people > > > happy. > > > > Some would surely see a difference between that and a release, > > but the diverging piles of patches downsteream would have > > a common starting point . > > > > > The process for creating the files comprising earlier releases > > > is convoluted and probably broken in a million ways by now. > > > > Yes, that is convoluted and broken; but I believe it can be > > simplified: for example, there's no need to have a separate > > macOS tarball or a precompiled binary, singling macOS out > > among all the other unixes ... > > The debian packaging and the msvc* are already gone (good). As a natural next step, let's get rid of the OSX cruft: https://sourceforge.net/p/sox/code/merge-requests/25/ Jan |
From: Jan S. <ha...@st...> - 2023-02-13 13:50:58
|
On Feb 13 14:02:34, ha...@st... wrote: > On Feb 07 14:20:42, ma...@ma... wrote: > > > Also, last release was 8 years ago. Piling the patches > > > is starting to get cubersome when packaging downstream > > > - are there any plans for a release? > > > > I can slap a tag on the git repo and call it a day if that makes people > > happy. > > Some would surely see a difference between that and a release, > but the diverging piles of patches downsteream would have > a common starting point . > > > The process for creating the files comprising earlier releases > > is convoluted and probably broken in a million ways by now. > > Yes, that is convoluted and broken; but I believe it can be > simplified: for example, there's no need to have a separate > macOS tarball or a precompiled binary, singling macOS out > among all the other unixes ... The debian packaging and the msvc* are already gone (good). Jan |
From: Jan S. <ha...@st...> - 2023-02-13 13:02:42
|
On Feb 07 14:20:42, ma...@ma... wrote: > > Also, last release was 8 years ago. Piling the patches > > is starting to get cubersome when packaging downstream > > - are there any plans for a release? > > I can slap a tag on the git repo and call it a day if that makes people > happy. Some would surely see a difference between that and a release, but the diverging piles of patches downsteream would have a common starting point . > The process for creating the files comprising earlier releases > is convoluted and probably broken in a million ways by now. Yes, that is convoluted and broken; but I believe it can be simplified: for example, there's no need to have a separate macOS tarball or a precompiled binary, singling macOS out among all the other unixes ... Jan |
From: Jan S. <ha...@st...> - 2023-02-13 12:55:13
|
On Feb 07 14:20:42, ma...@ma... wrote: > > What is currently the right way to report bugs and propose fixes? > > Are diffs to this devel list the preffered way? > > This list or the SF trackers are both fine by me. I just created individual merge requests in the SF tracker. Jan |
From: Jan S. <ha...@st...> - 2023-02-13 09:48:04
|
> That seems like a good opportunity to get them in. > As a first attempt, here is the simplest of them: > when failing an open_read(), sox does not deallocate the comments. Ah, and the same for open_write; diff in https://sourceforge.net/p/sox/code/merge-requests/17/ Jan |
From: Jan S. <ha...@st...> - 2023-02-10 08:39:29
|
This is a trivial fix of https://sourceforge.net/p/sox/bugs/359/ - increase LINEWIDTH to hold more channels git branch here if it's easier https://sourceforge.net/u/janstary/sox/ci/dat/tree/ but it's just the one line. Jan diff --git a/src/dat.c b/src/dat.c index b014f234..075fe2e1 100644 --- a/src/dat.c +++ b/src/dat.c @@ -12,7 +12,7 @@ #include "sox_i.h" #include <string.h> -#define LINEWIDTH (size_t)256 +#define LINEWIDTH (size_t)1024 /* Private data for dat file */ typedef struct { |
From: Jan S. <ha...@st...> - 2023-02-07 16:28:02
|
On Feb 07 14:20:42, ma...@ma... wrote: > Jan Stary <ha...@st...> writes: > > > Hi Mans, > > > > just to clear it up for myself: > > https://sourceforge.net/p/sox/code/ci/master/tree/ > > is still the ultimate upstream, right? > > Yes, that is the most current code. > > > For reference: there is also > > https://github.com/cbagwell/sox (last commit 2015, 4 issues, 2 PRs) > > https://github.com/mansr/sox (forked, last 2017, 1PR, no issue tracker) > > (and a bunch of nobody's forks of these of course, such as mine). > > > > These can be ignored when packaging downstream, right? > > Right, packagers should ignore those. > > > Are the commits in your GH fork included in the SF git? > > Some, not all. There are some things there of a more experimental > nature that I'm not comfortable making official. > > > What is currently the right way to report bugs and propose fixes? > > Are diffs to this devel list the preffered way? > > This list or the SF trackers are both fine by me. OK, thanks for clearing that up. > > Last commit to the SF git is May 2021; where should current fixes > > such as https://marc.info/?l=oss-security&m=167546008232629&w=2 be sent? > > I detest so-called security people and the way they handle their > so-called vulnerabilities. If they cared about anything other than > their own egos, they'd try to engage constructively with the code > authors/maintainers rather than filing CVE entries without asking or > understanding, then sending menacing emails in private. Well, the purpose of my message is precisely to engage constructively about these patches. The original diffs (by Helmut Grohne) https://marc.info/?t=167546017100001&r=1&w=2 were prepared against the Debian fork and do not apply to the SF git master. They are then tweaked by Steffen Nurpmeso to apply to the last commit of Sun May 9 21:17:32 2021 (which is what the OpenBSD audio/sox port is). That seems like a good opportunity to get them in. As a first attempt, here is the simplest of them: when failing an open_read(), sox does not deallocate the comments. diff --git a/src/formats.c b/src/formats.c index 3fcf4382..5eda5e36 100644 --- a/src/formats.c +++ b/src/formats.c @@ -627,6 +627,7 @@ error: free(ft->priv); free(ft->filename); free(ft->filetype); + sox_delete_comments(&ft->oob.comments); free(ft); return NULL; } Jan |
From: Måns R. <ma...@ma...> - 2023-02-07 14:39:35
|
Jan Stary <ha...@st...> writes: > Hi Mans, > > just to clear it up for myself: > https://sourceforge.net/p/sox/code/ci/master/tree/ > is still the ultimate upstream, right? Yes, that is the most current code. > For reference: there is also > https://github.com/cbagwell/sox (last commit 2015, 4 issues, 2 PRs) > https://github.com/mansr/sox (forked, last 2017, 1PR, no issue tracker) > (and a bunch of nobody's forks of these of course, such as mine). > > These can be ignored when packaging downstream, right? Right, packagers should ignore those. > Are the commits in your GH fork included in the SF git? Some, not all. There are some things there of a more experimental nature that I'm not comfortable making official. > What is currently the right way to report bugs and propose fixes? > Are diffs to this devel list the preffered way? This list or the SF trackers are both fine by me. > The SF issues seem to be untouched for years. Send more time. > Last commit to the SF git is May 2021; where should current fixes > such as https://marc.info/?l=oss-security&m=167546008232629&w=2 be sent? I detest so-called security people and the way they handle their so-called vulnerabilities. If they cared about anything other than their own egos, they'd try to engage constructively with the code authors/maintainers rather than filing CVE entries without asking or understanding, then sending menacing emails in private. > Also, last release was 8 years ago. Piling the patches > is starting to get cubersome when packaging downstream > - are there any plans for a release? I can slap a tag on the git repo and call it a day if that makes people happy. The process for creating the files comprising earlier releases is convoluted and probably broken in a million ways by now. -- Måns Rullgård |
From: Jan S. <ha...@st...> - 2023-02-07 13:32:16
|
Hi Mans, just to clear it up for myself: https://sourceforge.net/p/sox/code/ci/master/tree/ is still the ultimate upstream, right? For reference: there is also https://github.com/cbagwell/sox (last commit 2015, 4 issues, 2 PRs) https://github.com/mansr/sox (forked, last 2017, 1PR, no issue tracker) (and a bunch of nobody's forks of these of course, such as mine). These can be ignored when packaging downstream, right? Are the commits in your GH fork included in the SF git? What is currently the right way to report bugs and propose fixes? Are diffs to this devel list the preffered way? The SF issues seem to be untouched for years. Last commit to the SF git is May 2021; where should current fixes such as https://marc.info/?l=oss-security&m=167546008232629&w=2 be sent? Also, last release was 8 years ago. Piling the patches is starting to get cubersome when packaging downstream - are there any plans for a release? Jan |
From: Eric W. <nor...@yh...> - 2022-06-22 00:36:57
|
commit 77360f7193a2ba2e (mp3: fix duration calculation, 2019-12-16) appears incompatible with MP3s made using "lame --id3v2-only". sox ends up thinking the length is too short compared to the actual MP3 length. Reverting that commit fixes the issue. I haven't had a chance to look further into it, being mathematically challenged :x I used a 11:23.00 source FLAC file (44.1 kHz, 16-bit, 2ch) and fed it to "lame --id3v2-only /path/to.flac" The resulting /path/to.mp3 is only 15.49 seconds long when fed to soxi (but correctly 11:23.05 according to "ffprobe -i"). "play" stops after 15.49s, and "sox /path/to.mp3 -n stats" only shows 15.488 seconds. The 15.49s matches (to my ears) the first 15.49s of the 11:23.00 track. I can provide sample FLAC and mp3 files privately; but I suspect they're not needed as I've reproduced it with a few other CDDA-sourced FLAC files. I'm using lame 3.100 as distributed w/ Debian buster (3.100-b+b1). Omitting --id3v2-only from the lame invocation avoids this sox regression. Thanks. |
From: Eric W. <nor...@yh...> - 2022-06-11 02:17:28
|
Måns Rullgård <ma...@ma...> wrote: > The return value and ft->tell_off will be wrong in case the fwrite() was > restarted. Right, updated patch (covers fread + fflush) below; but still somewhere else is hitting EINTR... I'm still alive for now, but not feeling great about it :< > What did you do that caused the EINTR error? SIGWINCH -------8<------- Subject: [PATCH] WIP EINTR handling Still incomplete, SIGWINCH in a complex pipeline (sox -M "|sox ..." "|sox ..." -p) is still causing problems for me even with this patch. Not sure how much time I can devote to tracking more of it down of if I'll just setsid the parent script and call it a day since I fear this can turn into a long-term whack-a-mole situation... --- src/formats.c | 6 ++++- src/formats_i.c | 59 +++++++++++++++++++++++++++++++++++++++---------- 2 files changed, 52 insertions(+), 13 deletions(-) diff --git a/src/formats.c b/src/formats.c index 3fcf4382..31ab99f8 100644 --- a/src/formats.c +++ b/src/formats.c @@ -370,6 +370,10 @@ static sox_bool is_url(char const * text) /* detects only wget-supported URLs */ static int xfclose(FILE * file, lsx_io_type io_type) { + int ret; + do { + ret = fflush(file); + } while (ret == EOF && errno == EINTR); return #ifdef HAVE_POPEN io_type != lsx_io_file? pclose(file) : @@ -1064,7 +1068,7 @@ int sox_close(sox_format_t * ft) if (ft->fp == stdin) { sox_globals.stdin_in_use_by = NULL; } else if (ft->fp == stdout) { - fflush(stdout); + lsx_flush(ft); sox_globals.stdout_in_use_by = NULL; } else if (ft->fp) { xfclose(ft->fp, ft->io_type); diff --git a/src/formats_i.c b/src/formats_i.c index 7048040d..c4ead348 100644 --- a/src/formats_i.c +++ b/src/formats_i.c @@ -95,11 +95,24 @@ int lsx_check_read_params(sox_format_t * ft, unsigned channels, */ size_t lsx_readbuf(sox_format_t * ft, void *buf, size_t len) { - size_t ret = fread(buf, (size_t) 1, len, (FILE*)ft->fp); - if (ret != len && ferror((FILE*)ft->fp)) - lsx_fail_errno(ft, errno, "lsx_readbuf"); - ft->tell_off += ret; - return ret; + FILE *fp = (FILE*)ft->fp; + + while (1) { + size_t ret = fread(buf, 1, len, fp); + ft->tell_off += ret; + + if (ret) + return ret; + + if (feof(fp)) + break; + if (ferror(fp) && errno != EINTR) { + lsx_fail_errno(ft, errno, "lsx_readbuf"); + break; + } + } + + return 0; } /* Skip input without seeking. */ @@ -129,13 +142,29 @@ int lsx_padbytes(sox_format_t * ft, size_t n) */ size_t lsx_writebuf(sox_format_t * ft, void const * buf, size_t len) { - size_t ret = fwrite(buf, (size_t) 1, len, (FILE*)ft->fp); - if (ret != len) { - lsx_fail_errno(ft, errno, "error writing output file"); - clearerr((FILE*)ft->fp); /* Allows us to seek back to write header */ + FILE *fp = (FILE*)ft->fp; + const char *c = (const char *)buf; + sox_uint64_t orig_off = ft->tell_off; + + while (len) { + size_t ret = fwrite(c, 1, len, fp); + + ft->tell_off += ret; + c += ret; + len -= ret; + if (len && ferror(fp)) { + if (errno == EINTR) { + clearerr(fp); + /* retry */ + } else { + lsx_fail_errno(ft, errno, "error writing output file"); + clearerr(fp); /* Allows us to seek back to write header */ + break; + } + } } - ft->tell_off += ret; - return ret; + + return ft->tell_off - orig_off; } sox_uint64_t lsx_filelength(sox_format_t * ft) @@ -148,7 +177,13 @@ sox_uint64_t lsx_filelength(sox_format_t * ft) int lsx_flush(sox_format_t * ft) { - return fflush((FILE*)ft->fp); + int ret; + + do { + ret = fflush((FILE *)ft->fp); + } while (ret == EOF && errno == EINTR); + + return ret; } off_t lsx_tell(sox_format_t * ft) |
From: Måns R. <ma...@ma...> - 2022-06-10 19:25:00
|
Eric Wong <nor...@yh...> writes: > Only compile-tested, and I gotta run out for a bit and my not > return alive. I just noticed some EINTR errors while writing to > pipes and haven't dealt with stdio or C in ages at this point. > > diff --git a/src/formats_i.c b/src/formats_i.c > index 7048040d..d4082cc5 100644 > --- a/src/formats_i.c > +++ b/src/formats_i.c > @@ -129,10 +129,21 @@ int lsx_padbytes(sox_format_t * ft, size_t n) > */ > size_t lsx_writebuf(sox_format_t * ft, void const * buf, size_t len) > { > - size_t ret = fwrite(buf, (size_t) 1, len, (FILE*)ft->fp); > - if (ret != len) { > - lsx_fail_errno(ft, errno, "error writing output file"); > - clearerr((FILE*)ft->fp); /* Allows us to seek back to write header */ > + FILE *fp = (FILE*)ft->fp; > + const char *c = (const char *)buf; > + size_t ret = fwrite(c, 1, len, fp); > + > + while (ret != len) { > + switch (errno) { > + case EINTR: > + len -= ret; > + c += ret; > + ret = fwrite(c, 1, len, fp); > + break; > + default: > + lsx_fail_errno(ft, errno, "error writing output file"); > + clearerr(fp); /* Allows us to seek back to write header */ > + } > } > ft->tell_off += ret; > return ret; The return value and ft->tell_off will be wrong in case the fwrite() was restarted. What did you do that caused the EINTR error? -- Måns Rullgård |
From: Eric W. <nor...@yh...> - 2022-06-05 21:25:47
|
Only compile-tested, and I gotta run out for a bit and my not return alive. I just noticed some EINTR errors while writing to pipes and haven't dealt with stdio or C in ages at this point. diff --git a/src/formats_i.c b/src/formats_i.c index 7048040d..d4082cc5 100644 --- a/src/formats_i.c +++ b/src/formats_i.c @@ -129,10 +129,21 @@ int lsx_padbytes(sox_format_t * ft, size_t n) */ size_t lsx_writebuf(sox_format_t * ft, void const * buf, size_t len) { - size_t ret = fwrite(buf, (size_t) 1, len, (FILE*)ft->fp); - if (ret != len) { - lsx_fail_errno(ft, errno, "error writing output file"); - clearerr((FILE*)ft->fp); /* Allows us to seek back to write header */ + FILE *fp = (FILE*)ft->fp; + const char *c = (const char *)buf; + size_t ret = fwrite(c, 1, len, fp); + + while (ret != len) { + switch (errno) { + case EINTR: + len -= ret; + c += ret; + ret = fwrite(c, 1, len, fp); + break; + default: + lsx_fail_errno(ft, errno, "error writing output file"); + clearerr(fp); /* Allows us to seek back to write header */ + } } ft->tell_off += ret; return ret; |
From: Sven N. <Sve...@lo...> - 2021-10-07 14:27:57
|
Hi, thanks for the feedback. Attached you find a patch for the seeking that occurs when the WAV header is rewritten. This fixes the reported problem for me and it has seen some testing, mostly with dynamic memory streams though. I should be able to find time to look at other places that might need a similar fix. Regards, Sven ________________________________ From: Sun Zhenliang <his...@ou...> Sent: 07 October 2021 14:22 To: sox...@li... <sox...@li...> Subject: Re: [SoX-devel] .Re: [PATCH] formats: disallow seeking in dynamic memory buffers 在 2021年10月7日 +0800 14:18,Sven Neumann via SoX-devel <sox...@li...>,写道: Hi, thanks for pointing me to https://sourceforge.net/p/sox/mailman/message/37325794/<https://urldefense.com/v3/__https://sourceforge.net/p/sox/mailman/message/37325794/__;!!OA8L0MA-!shZZ0FsVq0F9l-rCU2Rs5tb3a6ZMpc9T5GrKQyIPeMAmADELDfUqDjZGdc51LFq0oA$>. This is exactly the problem I am trying to solve. I am somewhat surprised that we can actually recover the whole buffer after a seek and write because the memory stream maintains a null byte after the data. I was assuming that this means that we can not simply recover by seeking back to the end of the buffer because one byte would have been overwritten by that terminator byte. I tried what you suggested (code attached), and it seems that the terminating null byte is not moved on a seek operation, but only when the file descriptor is closed. Of course it would be desirable to have a proper WAV header even for streams opened with sox_open_memstream_write(). I can prepare a fix that introduces a seek back, but I guess I would have to do something similar for all formats that seek in the output buffer. Before I start to work on that I would like to get approval from the maintainer that this is the right approach. Yes, I guess there are lots of works to do related to this seek opt. Let me know if you need any help. Regards, SunZhenliang Regards, Sven From: Sun Zhenliang <his...@ou...> Sent: 07 October 2021 04:24 To: sox...@li... <sox...@li...> Subject: Re: [SoX-devel] [PATCH] formats: disallow seeking in dynamic memory buffers 在 2021年10月7日 +0800 05:35,Sven Neumann via SoX-devel <sox...@li...>,写道: Hi, in one of our internal applications we are using SoX (the 14.4.2+git20190427 version from Ubuntu) to convert from a variety of audio formats to the WAV file format. We observed that the tests for the conversion occasionally failed and over the last days I found time to dig deeper into this. We are using sox_open_memstream_write() to write to a dynamically allocated in-memory stream. In our tests sometimes the size of the resulting WAV buffer would have the expected size, sometimes it would be 44 bytes, the size of the WAV header. Valgrind told me that the behavior of is_seekable() in formats.c depends on uninitialized memory. In your git repository I found a fix for this: commit bb38934e11035c8fab141f70dabda3afdd17da36 Author: Mans Rullgard <ma...@ma...> Date: Tue Aug 4 17:19:49 2020 +0100 format: improve is_seekable() test Streams opened with fmemopen() do not have an underlying file descriptor, so the fstat() will fail, and a random result is returned. A simpler method that works regardless of file type is to call fseek() and check if it reports success. Suggested by Stefan Sauer <en...@go...>. Now with this fix applied valgrind was happy, however now our conversion from MP3 to WAV would always result in only 44 bytes, as read from the buffer_size_ptr location passed to sox_open_memstream_write(). It turns out that with above change the undefined behavior is fixed for streams created with open_memstream() and is_seekable() will now reliably returns sox_true for such streams. This allows the WAV writer code to do an fseek() to the start of the stream followed by a write of the WAV header with correct length information. However such a seek followed by a write causes the dynamically allocated memory stream to be truncated. Thus after calling sox_close() the size reported for the stream will be 44 bytes, that's not what we want. Unfortunately we can not simply fix this by reporting the full buffer size as the buffer will actually have been truncated, and a trailing null byte is appended after the WAV header. It looks like we can indeed not seek and fix data in a dynamically allocated stream. Thus I am attaching a patch that changes the code in formats.c to set ft->seekable to false for streams opened with open_memstream(). With this change applied on top of the improvement for the is_seekable() test, our tests pass reliably and valgrind seems happy as well. I am attaching the patch here, please consider it for inclusion. I am also attaching a simple test application that writes to a stream, seeks to the front and performs another write. The output of this program illustrates that the buffer is truncated: buf = `hello', size = 5 buf = `hello, world', size = 12 buf = `heyho', size = 5 Bug mentioned https://sourceforge.net/p/sox/mailman/message/37325794/<https://urldefense.com/v3/__https://sourceforge.net/p/sox/mailman/message/37325794/__;!!OA8L0MA-!shZZ0FsVq0F9l-rCU2Rs5tb3a6ZMpc9T5GrKQyIPeMAmADELDfUqDjZGdc51LFq0oA$>. It is possible to fix the whole data. From my test to open_memstream(), the dynamically allocated memory would not be free before the ft->fp was closed. The data written is still there if it’s not covered by other write opt. In this WAV issue, the seek opt is just in sox_close() to rewrite header, which is the end of transcoding and will not cover the data area. We can just ftell() to get the end of file before the fseek and seek back to the end after rewriting. Output with ftell opt: buf = `hello', size = 5 buf = `hello, world', size = 12 buf = `heyho, world', size = 12 As for other formats, the situation may be different from WAV and needs specific analysis. Regards, Sven _______________________________________________ SoX-devel mailing list SoX...@li... https://lists.sourceforge.net/lists/listinfo/sox-devel<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/sox-devel__;!!OA8L0MA-!shZZ0FsVq0F9l-rCU2Rs5tb3a6ZMpc9T5GrKQyIPeMAmADELDfUqDjZGdc4ivaLrLA$> _______________________________________________ SoX-devel mailing list SoX...@li... https://lists.sourceforge.net/lists/listinfo/sox-devel<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/sox-devel__;!!OA8L0MA-!shZZ0FsVq0F9l-rCU2Rs5tb3a6ZMpc9T5GrKQyIPeMAmADELDfUqDjZGdc4ivaLrLA$> |
From: Sun Z. <his...@ou...> - 2021-10-07 12:23:04
|
在 2021年10月7日 +0800 14:18,Sven Neumann via SoX-devel <sox...@li...>,写道: > Hi, > > thanks for pointing me to https://sourceforge.net/p/sox/mailman/message/37325794/. This is exactly the problem I am trying to solve. > > I am somewhat surprised that we can actually recover the whole buffer after a seek and write because the memory stream maintains a null byte after the data. I was assuming that this means that we can not simply recover by seeking back to the end of the buffer because one byte would have been overwritten by that terminator byte. I tried what you suggested (code attached), and it seems that the terminating null byte is not moved on a seek operation, but only when the file descriptor is closed. > > Of course it would be desirable to have a proper WAV header even for streams opened with sox_open_memstream_write(). I can prepare a fix that introduces a seek back, but I guess I would have to do something similar for all formats that seek in the output buffer. Before I start to work on that I would like to get approval from the maintainer that this is the right approach. Yes, I guess there are lots of works to do related to this seek opt. Let me know if you need any help. Regards, SunZhenliang > > > Regards, > Sven > > > From: Sun Zhenliang <his...@ou...> > Sent: 07 October 2021 04:24 > To: sox...@li... <sox...@li...> > Subject: Re: [SoX-devel] [PATCH] formats: disallow seeking in dynamic memory buffers > > 在 2021年10月7日 +0800 05:35,Sven Neumann via SoX-devel <sox...@li...>,写道: > Hi, > > in one of our internal applications we are using SoX (the 14.4.2+git20190427 version from Ubuntu) to convert from a variety of audio formats to the WAV file format. We observed that the tests for the conversion occasionally failed and over the last days I found time to dig deeper into this. > > We are using sox_open_memstream_write() to write to a dynamically allocated in-memory stream. In our tests sometimes the size of the resulting WAV buffer would have the expected size, sometimes it would be 44 bytes, the size of the WAV header. Valgrind told me that the behavior of is_seekable() in formats.c depends on uninitialized memory. In your git repository I found a fix for this: > > commit bb38934e11035c8fab141f70dabda3afdd17da36 > Author: Mans Rullgard <ma...@ma...> > Date: Tue Aug 4 17:19:49 2020 +0100 > > format: improve is_seekable() test > > Streams opened with fmemopen() do not have an underlying file descriptor, > so the fstat() will fail, and a random result is returned. > > A simpler method that works regardless of file type is to call fseek() > and check if it reports success. > > Suggested by Stefan Sauer <en...@go...>. > > > Now with this fix applied valgrind was happy, however now our conversion from MP3 to WAV would always result in only 44 bytes, as read from the buffer_size_ptr location passed to sox_open_memstream_write(). It turns out that with above change the undefined behavior is fixed for streams created with open_memstream() and is_seekable() will now reliably returns sox_true for such streams. This allows the WAV writer code to do an fseek() to the start of the stream followed by a write of the WAV header with correct length information. However such a seek followed by a write causes the dynamically allocated memory stream to be truncated. Thus after calling sox_close() the size reported for the stream will be 44 bytes, that's not what we want. Unfortunately we can not simply fix this by reporting the full buffer size as the buffer will actually have been truncated, and a trailing null byte is appended after the WAV header. It looks like we can indeed not seek and fix data in a dynamically allocated stream. Thus I am attaching a patch that changes the code in formats.c to set ft->seekable to false for streams opened with open_memstream(). With this change applied on top of the improvement for the is_seekable() test, our tests pass reliably and valgrind seems happy as well. > > I am attaching the patch here, please consider it for inclusion. I am also attaching a simple test application that writes to a stream, seeks to the front and performs another write. The output of this program illustrates that the buffer is truncated: > > buf = `hello', size = 5 > buf = `hello, world', size = 12 > buf = `heyho', size = 5 > Bug mentioned https://sourceforge.net/p/sox/mailman/message/37325794/. > > It is possible to fix the whole data. From my test to open_memstream(), the > dynamically allocated memory would not be free before the ft->fp was closed. > The data written is still there if it’s not covered by other write opt. > > In this WAV issue, the seek opt is just in sox_close() to rewrite header, which > is the end of transcoding and will not cover the data area. We can just ftell() > to get the end of file before the fseek and seek back to the end after rewriting. > > Output with ftell opt: > buf = `hello', size = 5 > buf = `hello, world', size = 12 > buf = `heyho, world', size = 12 > > As for other formats, the situation may be different from WAV and needs specific > analysis. > > > > Regards, > Sven > > > > > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel |
From: Sven N. <Sve...@lo...> - 2021-10-07 06:18:03
|
Hi, thanks for pointing me to https://sourceforge.net/p/sox/mailman/message/37325794/. This is exactly the problem I am trying to solve. I am somewhat surprised that we can actually recover the whole buffer after a seek and write because the memory stream maintains a null byte after the data. I was assuming that this means that we can not simply recover by seeking back to the end of the buffer because one byte would have been overwritten by that terminator byte. I tried what you suggested (code attached), and it seems that the terminating null byte is not moved on a seek operation, but only when the file descriptor is closed. Of course it would be desirable to have a proper WAV header even for streams opened with sox_open_memstream_write(). I can prepare a fix that introduces a seek back, but I guess I would have to do something similar for all formats that seek in the output buffer. Before I start to work on that I would like to get approval from the maintainer that this is the right approach. Regards, Sven From: Sun Zhenliang <his...@ou...> Sent: 07 October 2021 04:24 To: sox...@li... <sox...@li...> Subject: Re: [SoX-devel] [PATCH] formats: disallow seeking in dynamic memory buffers 在 2021年10月7日 +0800 05:35,Sven Neumann via SoX-devel <sox...@li...>,写道: Hi, in one of our internal applications we are using SoX (the 14.4.2+git20190427 version from Ubuntu) to convert from a variety of audio formats to the WAV file format. We observed that the tests for the conversion occasionally failed and over the last days I found time to dig deeper into this. We are using sox_open_memstream_write() to write to a dynamically allocated in-memory stream. In our tests sometimes the size of the resulting WAV buffer would have the expected size, sometimes it would be 44 bytes, the size of the WAV header. Valgrind told me that the behavior of is_seekable() in formats.c depends on uninitialized memory. In your git repository I found a fix for this: commit bb38934e11035c8fab141f70dabda3afdd17da36 Author: Mans Rullgard <ma...@ma...> Date: Tue Aug 4 17:19:49 2020 +0100 format: improve is_seekable() test Streams opened with fmemopen() do not have an underlying file descriptor, so the fstat() will fail, and a random result is returned. A simpler method that works regardless of file type is to call fseek() and check if it reports success. Suggested by Stefan Sauer <en...@go...>. Now with this fix applied valgrind was happy, however now our conversion from MP3 to WAV would always result in only 44 bytes, as read from the buffer_size_ptr location passed to sox_open_memstream_write(). It turns out that with above change the undefined behavior is fixed for streams created with open_memstream() and is_seekable() will now reliably returns sox_true for such streams. This allows the WAV writer code to do an fseek() to the start of the stream followed by a write of the WAV header with correct length information. However such a seek followed by a write causes the dynamically allocated memory stream to be truncated. Thus after calling sox_close() the size reported for the stream will be 44 bytes, that's not what we want. Unfortunately we can not simply fix this by reporting the full buffer size as the buffer will actually have been truncated, and a trailing null byte is appended after the WAV header. It looks like we can indeed not seek and fix data in a dynamically allocated stream. Thus I am attaching a patch that changes the code in formats.c to set ft->seekable to false for streams opened with open_memstream(). With this change applied on top of the improvement for the is_seekable() test, our tests pass reliably and valgrind seems happy as well. I am attaching the patch here, please consider it for inclusion. I am also attaching a simple test application that writes to a stream, seeks to the front and performs another write. The output of this program illustrates that the buffer is truncated: buf = `hello', size = 5 buf = `hello, world', size = 12 buf = `heyho', size = 5 Bug mentioned https://sourceforge.net/p/sox/mailman/message/37325794/. It is possible to fix the whole data. From my test to open_memstream(), the dynamically allocated memory would not be free before the ft->fp was closed. The data written is still there if it’s not covered by other write opt. In this WAV issue, the seek opt is just in sox_close() to rewrite header, which is the end of transcoding and will not cover the data area. We can just ftell() to get the end of file before the fseek and seek back to the end after rewriting. Output with ftell opt: buf = `hello', size = 5 buf = `hello, world', size = 12 buf = `heyho, world', size = 12 As for other formats, the situation may be different from WAV and needs specific analysis. Regards, Sven _______________________________________________ SoX-devel mailing list SoX...@li... https://lists.sourceforge.net/lists/listinfo/sox-devel |
From: Sun Z. <his...@ou...> - 2021-10-07 02:24:43
|
在 2021年10月7日 +0800 05:35,Sven Neumann via SoX-devel <sox...@li...>,写道: > Hi, > > in one of our internal applications we are using SoX (the 14.4.2+git20190427 version from Ubuntu) to convert from a variety of audio formats to the WAV file format. We observed that the tests for the conversion occasionally failed and over the last days I found time to dig deeper into this. > > We are using sox_open_memstream_write() to write to a dynamically allocated in-memory stream. In our tests sometimes the size of the resulting WAV buffer would have the expected size, sometimes it would be 44 bytes, the size of the WAV header. Valgrind told me that the behavior of is_seekable() in formats.c depends on uninitialized memory. In your git repository I found a fix for this: > > commit bb38934e11035c8fab141f70dabda3afdd17da36 > Author: Mans Rullgard <ma...@ma...> > Date: Tue Aug 4 17:19:49 2020 +0100 > > format: improve is_seekable() test > > Streams opened with fmemopen() do not have an underlying file descriptor, > so the fstat() will fail, and a random result is returned. > > A simpler method that works regardless of file type is to call fseek() > and check if it reports success. > > Suggested by Stefan Sauer <en...@go...>. > > > Now with this fix applied valgrind was happy, however now our conversion from MP3 to WAV would always result in only 44 bytes, as read from the buffer_size_ptr location passed to sox_open_memstream_write(). It turns out that with above change the undefined behavior is fixed for streams created with open_memstream() and is_seekable() will now reliably returns sox_true for such streams. This allows the WAV writer code to do an fseek() to the start of the stream followed by a write of the WAV header with correct length information. However such a seek followed by a write causes the dynamically allocated memory stream to be truncated. Thus after calling sox_close() the size reported for the stream will be 44 bytes, that's not what we want. Unfortunately we can not simply fix this by reporting the full buffer size as the buffer will actually have been truncated, and a trailing null byte is appended after the WAV header. It looks like we can indeed not seek and fix data in a dynamically allocated stream. Thus I am attaching a patch that changes the code in formats.c to set ft->seekable to false for streams opened with open_memstream(). With this change applied on top of the improvement for the is_seekable() test, our tests pass reliably and valgrind seems happy as well. > > I am attaching the patch here, please consider it for inclusion. I am also attaching a simple test application that writes to a stream, seeks to the front and performs another write. The output of this program illustrates that the buffer is truncated: > > buf = `hello', size = 5 > buf = `hello, world', size = 12 > buf = `heyho', size = 5 Bug mentioned https://sourceforge.net/p/sox/mailman/message/37325794/. It is possible to fix the whole data. From my test to open_memstream(), the dynamically allocated memory would not be free before the ft->fp was closed. The data written is still there if it’s not covered by other write opt. In this WAV issue, the seek opt is just in sox_close() to rewrite header, which is the end of transcoding and will not cover the data area. We can just ftell() to get the end of file before the fseek and seek back to the end after rewriting. Output with ftell opt: buf = `hello', size = 5 buf = `hello, world', size = 12 buf = `heyho, world', size = 12 As for other formats, the situation may be different from WAV and needs specific analysis. > > > Regards, > Sven > > > > > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel |
From: Sven N. <Sve...@lo...> - 2021-10-06 21:35:13
|
Hi, in one of our internal applications we are using SoX (the 14.4.2+git20190427 version from Ubuntu) to convert from a variety of audio formats to the WAV file format. We observed that the tests for the conversion occasionally failed and over the last days I found time to dig deeper into this. We are using sox_open_memstream_write() to write to a dynamically allocated in-memory stream. In our tests sometimes the size of the resulting WAV buffer would have the expected size, sometimes it would be 44 bytes, the size of the WAV header. Valgrind told me that the behavior of is_seekable() in formats.c depends on uninitialized memory. In your git repository I found a fix for this: commit bb38934e11035c8fab141f70dabda3afdd17da36 Author: Mans Rullgard <ma...@ma...> Date: Tue Aug 4 17:19:49 2020 +0100 format: improve is_seekable() test Streams opened with fmemopen() do not have an underlying file descriptor, so the fstat() will fail, and a random result is returned. A simpler method that works regardless of file type is to call fseek() and check if it reports success. Suggested by Stefan Sauer <en...@go...>. Now with this fix applied valgrind was happy, however now our conversion from MP3 to WAV would always result in only 44 bytes, as read from the buffer_size_ptr location passed to sox_open_memstream_write(). It turns out that with above change the undefined behavior is fixed for streams created with open_memstream() and is_seekable() will now reliably returns sox_true for such streams. This allows the WAV writer code to do an fseek() to the start of the stream followed by a write of the WAV header with correct length information. However such a seek followed by a write causes the dynamically allocated memory stream to be truncated. Thus after calling sox_close() the size reported for the stream will be 44 bytes, that's not what we want. Unfortunately we can not simply fix this by reporting the full buffer size as the buffer will actually have been truncated, and a trailing null byte is appended after the WAV header. It looks like we can indeed not seek and fix data in a dynamically allocated stream. Thus I am attaching a patch that changes the code in formats.c to set ft->seekable to false for streams opened with open_memstream(). With this change applied on top of the improvement for the is_seekable() test, our tests pass reliably and valgrind seems happy as well. I am attaching the patch here, please consider it for inclusion. I am also attaching a simple test application that writes to a stream, seeks to the front and performs another write. The output of this program illustrates that the buffer is truncated: buf = `hello', size = 5 buf = `hello, world', size = 12 buf = `heyho', size = 5 Regards, Sven |
From: Md. E. H. <en...@go...> - 2021-09-08 21:23:10
|
The logging functions in SoX like lsx_debug, lsx_report, etc. write to the global struct sox_globals before calling the actual print functions. Example macro: #define lsx_report sox_globals.subsystem=__FILE__,lsx_report_impl This can create *race conditions* if run parallely. For example, two lsx_report calls are called parallely. lsx_report call 1 updates sox_globals.subsystem. lsx_report call 2 updates sox_globals.subsystem. lsx_report call 1 prints, but with incorrect subsystem of call 2. lsx_report call 2 prints with the correct subsystem. I am attaching a patch file to make the calls thread-friendly. Please let me know if the patch makes sense. -- Regards, Enzam (enzam@ <http://who/enzam>) *Inlined patch (also attached as file):* >From 3be8226c8ca2b4f29b6927583641cb08ef39dddf Mon Sep 17 00:00:00 2001 From: "Md. Enzam Hossain" <en...@go...> Date: Wed, 8 Sep 2021 12:03:02 -0700 Subject: [PATCH] Make logging thread friendly. If multiple threads tries to log together, the subsystem may get overwritten by each other. Remove the dependency on the global parameter. --- src/libsox.c | 4 ++-- src/mp3.c | 15 +++------------ src/sox.h | 32 ++++++++++++++++++-------------- src/sox_i.h | 16 ++++++++-------- 4 files changed, 31 insertions(+), 36 deletions(-) diff --git a/src/libsox.c b/src/libsox.c index 8e9ebad6..6fc0ec41 100644 --- a/src/libsox.c +++ b/src/libsox.c @@ -195,11 +195,11 @@ size_t sox_basename(char * base_buffer, size_t base_buffer_len, const char * fil } #define SOX_MESSAGE_FUNCTION(name,level) \ -void name(char const * fmt, ...) { \ +void name(char const * filename, char const * fmt, ...) { \ va_list ap; \ va_start(ap, fmt); \ if (sox_globals.output_message_handler) \ - (*sox_globals.output_message_handler)(level,sox_globals.subsystem,fmt,ap); \ + (*sox_globals.output_message_handler)(level,filename,fmt,ap); \ va_end(ap); \ } diff --git a/src/mp3.c b/src/mp3.c index 1fd144d1..552ab0db 100644 --- a/src/mp3.c +++ b/src/mp3.c @@ -680,26 +680,17 @@ static int startread(sox_format_t * ft) static void errorf(const char* fmt, va_list va) { - sox_globals.subsystem=__FILE__; - if (sox_globals.output_message_handler) - (*sox_globals.output_message_handler)(1,sox_globals.subsystem,fmt,va); - return; + lsx_fail(fmt, va); } static void debugf(const char* fmt, va_list va) { - sox_globals.subsystem=__FILE__; - if (sox_globals.output_message_handler) - (*sox_globals.output_message_handler)(4,sox_globals.subsystem,fmt,va); - return; + lsx_debug(fmt, va); } static void msgf(const char* fmt, va_list va) { - sox_globals.subsystem=__FILE__; - if (sox_globals.output_message_handler) - (*sox_globals.output_message_handler)(3,sox_globals.subsystem,fmt,va); - return; + lsx_report(fmt, va); } /* These functions are considered optional. If they aren't present in the diff --git a/src/sox.h b/src/sox.h index bac50354..b9cd9754 100644 --- a/src/sox.h +++ b/src/sox.h @@ -79,14 +79,14 @@ the variable being unused (especially in macro-generated code). /** Plugins API: -LSX_PRINTF12: Attribute applied to a function to indicate that it requires -a printf-style format string for arg1 and that printf parameters start at -arg2. +LSX_PRINTF23: Attribute applied to a function to indicate that it requires +a printf-style format string for arg2 and that printf parameters start at +arg3. */ #ifdef __GNUC__ -#define LSX_PRINTF12 __attribute__ ((format (printf, 1, 2))) /* Function has printf-style arguments. */ +#define LSX_PRINTF23 __attribute__ ((format (printf, 2, 3))) /* Function has printf-style arguments. */ #else -#define LSX_PRINTF12 /* Function has printf-style arguments. */ +#define LSX_PRINTF23 /* Function has printf-style arguments. */ #endif /** @@ -1330,7 +1330,7 @@ typedef struct sox_globals_t { char const * stdin_in_use_by; /**< Private: tracks the name of the handler currently using stdin */ char const * stdout_in_use_by; /**< Private: tracks the name of the handler currently using stdout */ - char const * subsystem; /**< Private: tracks the name of the handler currently writing an output message */ + char const * subsystem; /**< Deprecated, Private: tracks the name of the handler currently writing an output message */ char * tmp_path; /**< Private: client-configured path to use for temporary files */ sox_bool use_magic; /**< Private: true if client has requested use of 'magic' file-type detection */ sox_bool use_threads; /**< Private: true if client has requested parallel effects processing */ @@ -2273,9 +2273,10 @@ Print a fatal error in libSoX. void LSX_API lsx_fail_impl( + LSX_PARAM_IN_Z char const * filename, /**< Source code __FILE__ from which message originates. */ LSX_PARAM_IN_PRINTF char const * fmt, /**< printf-style format string. */ ...) - LSX_PRINTF12; + LSX_PRINTF23; /** Plugins API: @@ -2284,9 +2285,10 @@ Print a warning in libSoX. void LSX_API lsx_warn_impl( + LSX_PARAM_IN_Z char const * filename, /**< Source code __FILE__ from which message originates. */ LSX_PARAM_IN_PRINTF char const * fmt, /**< printf-style format string. */ ...) - LSX_PRINTF12; + LSX_PRINTF23; /** Plugins API: @@ -2295,9 +2297,10 @@ Print an informational message in libSoX. void LSX_API lsx_report_impl( + LSX_PARAM_IN_Z char const * filename, /**< Source code __FILE__ from which message originates. */ LSX_PARAM_IN_PRINTF char const * fmt, /**< printf-style format string. */ ...) - LSX_PRINTF12; + LSX_PRINTF23; /** Plugins API: @@ -2306,33 +2309,34 @@ Print a debug message in libSoX. void LSX_API lsx_debug_impl( + LSX_PARAM_IN_Z char const * filename, /**< Source code __FILE__ from which message originates. */ LSX_PARAM_IN_PRINTF char const * fmt, /**< printf-style format string. */ ...) - LSX_PRINTF12; + LSX_PRINTF23; /** Plugins API: Report a fatal error in libSoX; printf-style arguments must follow. */ -#define lsx_fail sox_get_globals()->subsystem=__FILE__,lsx_fail_impl +#define lsx_fail(...) lsx_fail_impl(__FILE__, __VA_ARGS__) /** Plugins API: Report a warning in libSoX; printf-style arguments must follow. */ -#define lsx_warn sox_get_globals()->subsystem=__FILE__,lsx_warn_impl +#define lsx_warn(...) lsx_warn_impl(__FILE__, __VA_ARGS__) /** Plugins API: Report an informational message in libSoX; printf-style arguments must follow. */ -#define lsx_report sox_get_globals()->subsystem=__FILE__,lsx_report_impl +#define lsx_report(...) lsx_report_impl(__FILE__, __VA_ARGS__) /** Plugins API: Report a debug message in libSoX; printf-style arguments must follow. */ -#define lsx_debug sox_get_globals()->subsystem=__FILE__,lsx_debug_impl +#define lsx_debug(...) lsx_debug_impl(__FILE__, __VA_ARGS__) /** Plugins API: diff --git a/src/sox_i.h b/src/sox_i.h index c8552f97..c843556c 100644 --- a/src/sox_i.h +++ b/src/sox_i.h @@ -31,10 +31,10 @@ #undef lsx_fail #undef lsx_report #undef lsx_warn -#define lsx_debug sox_globals.subsystem=effp->handler.name,lsx_debug_impl -#define lsx_fail sox_globals.subsystem=effp->handler.name,lsx_fail_impl -#define lsx_report sox_globals.subsystem=effp->handler.name,lsx_report_impl -#define lsx_warn sox_globals.subsystem=effp->handler.name,lsx_warn_impl +#define lsx_debug(...) lsx_debug_impl(effp->handler.name, __VA_ARGS__) +#define lsx_fail(...) lsx_fail_impl(effp->handler.name, __VA_ARGS__) +#define lsx_report(...) lsx_report_impl(effp->handler.name, __VA_ARGS__) +#define lsx_warn(...) lsx_warn_impl(effp->handler.name, __VA_ARGS__) #endif #define RANQD1 ranqd1(sox_globals.ranqd1) @@ -56,11 +56,11 @@ assert_static(sizeof(off_t) == _FILE_OFFSET_BITS >> 3, OFF_T_BUILD_PROBLEM); FILE * lsx_tmpfile(void); -void lsx_debug_more_impl(char const * fmt, ...) LSX_PRINTF12; -void lsx_debug_most_impl(char const * fmt, ...) LSX_PRINTF12; +void lsx_debug_more_impl(LSX_PARAM_IN_Z char const * filename, LSX_PARAM_IN_PRINTF char const * fmt, ...) LSX_PRINTF23; +void lsx_debug_most_impl(LSX_PARAM_IN_Z char const * filename, LSX_PARAM_IN_PRINTF char const * fmt, ...) LSX_PRINTF23; -#define lsx_debug_more sox_get_globals()->subsystem=__FILE__,lsx_debug_more_impl -#define lsx_debug_most sox_get_globals()->subsystem=__FILE__,lsx_debug_most_impl +#define lsx_debug_more(...) lsx_debug_more_impl(__FILE__, __VA_ARGS__) +#define lsx_debug_most(...) lsx_debug_most_impl(__FILE__, __VA_ARGS__) /* Digitise one cycle of a wave and store it as * a table of samples of a specified data-type. -- 2.33.0.153.gba50c8fa24-goog |
From: Cary L. <car...@gm...> - 2021-02-01 18:00:40
|
Ha ha. At least you're honest... On Mon, Feb 1, 2021 at 12:56 PM Måns Rullgård <ma...@ma...> wrote: > in...@au... writes: > > >> Simone Filippini <in...@au...> writes: > >> > >>> OS: FreeBSD 12.2 > >>> Commit: dd8b63 > >>> After "autoreconf -i" I get: > >>> "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is > >>> undefined." > >>> I tried several previous commits but the error persists OR there are > >>> errors after "./configure" > >>> I can only compile the 2017 version of SoX on mansr GitHub. > >>> Can anyone help me? > >> Make sure you have all the required packages installed. It works fine > >> on FreeBSD here. > >> $ freebsd-version > >> 12.2-RELEASE-p3 > >> $ pkg info autoconf automake autoconf-archive libtool pkgconf > >> autoconf-2.69_3 > >> automake-1.16.3 > >> autoconf-archive-0.2019.01.06 > >> libtool-2.4.6_1 > >> pkgconf-1.7.3,1 > > > > pkgconf was missing. Thanks a lot. > > Is there any reason why your patches to support dsd are not merged in > this > > version on sourceforge? > > Yes, I'm lazy. > > -- > Måns Rullgård > > > _______________________________________________ > SoX-devel mailing list > SoX...@li... > https://lists.sourceforge.net/lists/listinfo/sox-devel > |
From: Måns R. <ma...@ma...> - 2021-02-01 17:55:58
|
in...@au... writes: >> Simone Filippini <in...@au...> writes: >> >>> OS: FreeBSD 12.2 >>> Commit: dd8b63 >>> After "autoreconf -i" I get: >>> "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is >>> undefined." >>> I tried several previous commits but the error persists OR there are >>> errors after "./configure" >>> I can only compile the 2017 version of SoX on mansr GitHub. >>> Can anyone help me? >> Make sure you have all the required packages installed. It works fine >> on FreeBSD here. >> $ freebsd-version >> 12.2-RELEASE-p3 >> $ pkg info autoconf automake autoconf-archive libtool pkgconf >> autoconf-2.69_3 >> automake-1.16.3 >> autoconf-archive-0.2019.01.06 >> libtool-2.4.6_1 >> pkgconf-1.7.3,1 > > pkgconf was missing. Thanks a lot. > Is there any reason why your patches to support dsd are not merged in this > version on sourceforge? Yes, I'm lazy. -- Måns Rullgård |
From: <in...@au...> - 2021-02-01 17:24:04
|
> Simone Filippini <in...@au...> writes: > >> OS: FreeBSD 12.2 >> Commit: dd8b63 >> >> After "autoreconf -i" I get: >> "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is >> undefined." >> >> I tried several previous commits but the error persists OR there are >> errors after "./configure" >> >> I can only compile the 2017 version of SoX on mansr GitHub. >> >> Can anyone help me? > > Make sure you have all the required packages installed. It works fine > on FreeBSD here. > > $ freebsd-version > 12.2-RELEASE-p3 > $ pkg info autoconf automake autoconf-archive libtool pkgconf > autoconf-2.69_3 > automake-1.16.3 > autoconf-archive-0.2019.01.06 > libtool-2.4.6_1 > pkgconf-1.7.3,1 pkgconf was missing. Thanks a lot. Is there any reason why your patches to support dsd are not merged in this version on sourceforge? I tried to parse all your commits on github when you implemented dsd and tried to merge them all with the code here on SF. When trying to compile I get: --- libsox_la-sdm.lo --- In file included from sdm.c:670: ./sdm_x86.h:52:41: error: unknown type name 'sdm_filter_t' const sdm_filter_t *f, [...] Any input would be really appreciated. Thanks for your work, Regards, Simone |
From: Måns R. <ma...@ma...> - 2021-01-31 11:51:04
|
Simone Filippini <in...@au...> writes: > OS: FreeBSD 12.2 > Commit: dd8b63 > > After "autoreconf -i" I get: > "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is undefined." > > I tried several previous commits but the error persists OR there are errors after "./configure" > > I can only compile the 2017 version of SoX on mansr GitHub. > > Can anyone help me? Make sure you have all the required packages installed. It works fine on FreeBSD here. $ freebsd-version 12.2-RELEASE-p3 $ pkg info autoconf automake autoconf-archive libtool pkgconf autoconf-2.69_3 automake-1.16.3 autoconf-archive-0.2019.01.06 libtool-2.4.6_1 pkgconf-1.7.3,1 -- Måns Rullgård |
From: Simone F. <in...@au...> - 2021-01-31 06:13:28
|
OS: FreeBSD 12.2 Commit: dd8b63 After "autoreconf -i" I get: "Makefile.am:18: error: 'pkgconfig_DATA' Is used but 'pkgconfigdir' Is undefined." I tried several previous commits but the error persists OR there are errors after "./configure" I can only compile the 2017 version of SoX on mansr GitHub. Can anyone help me? Regards, Simone |