libsox build and documentation

[Jan Stary <hans@stare.cz>]

Thanks for the reports so far (mostly off-list).

On top of that build branch, here is a branch that
builds _and_documents_ libsox, i.e. brings libsox(3)
to sync with reality, after many many years.

https://github.com/janstary/sox/tree/libsox
https://github.com/janstary/sox/issues/43
https://github.com/janstary/sox/issues/49


See the git log for more lolz:

/**
Client API:
Signed twos-complement 8-bit type. Typically defined as signed char.
*/
typedef int8_t sox_int8_t;


Please test everywhere and let me know if it works for you.
(Let's see if anyone uses libsox at all.)

	Jan


On Jun 10 20:21:58, hans@stare.cz wrote:
> Dear fellow users of SoX,
> 
> I would like to kindly ask you to test a build system for SoX:
> the 'build' branch at https://github.com/janstary/sox/tree/build
> 
> On the surface it is the same: ./configure && make (see INSTALL).
> On the inside, it is a complete overhaul.
> 
> Branching from Mans's latest commit (the spectrogram fix),
> it consists of about 100 commits, should you want to read
> the whole story; here is the gist of it.
> 
> It replaces the GNU auto* system with a simple, hand-written
> ./configure script, a straightforward Makefile, and a set of
> have-*.c micro-programs testing the availability of libraries.
> It "borrows" heavily (in fact, steals with love) from
> Ingo Schwarze's build system for the mandoc package.
> 
> This has no dependency on anything besides sh(1) and cc(1).
> The main point is to get rid of the GNU autotools monster:
> Do we have strlen()? Can <stdint.h> be included? What of "gcc -v"?
> POSIX.1 came out more than fifteen years ago; all modern systems
> are close to that and we should be coding against that standard.
> 
> Functionaly, this system detects the optional external formats
> and audio drivers the current autotools system tries to detect,
> but correctly, much faster, using elementary tools,
> and actualy respecting the results.
> 
> The single exception is waveaudio, as I have no windows machine.
> 
> A big change in the resulting build is this no longer builds
> or install libsox the library, as opposed to sox the binary.
> SoX itself seems to be the only user of that library.
> Looking into the entire collection of ports and packages
> of all the system below, I have found _two_ things using it.
> (Not to be confused with libsoxr, the resampling library
> extracted from sox by Rob Sykes, maintainer at the time.)
> Details in https://github.com/janstary/sox/issues/43
> 
> Another change is the dynamic loading of libraries with dlopen(),
> which I have completely dropped. Either have the library at build
> and link against it, or don't, like everyone else. (But libltdl
> is not completely gone, because the ladspa plugins need it.)
> 
> Like gsm some years ago, the lpc codec is made an optional,
> external dependecy, as opposed the carrying a copy of its
> entire implementation. If you care about LPC as a format,
> look at https://github.com/janstary/lpc for a separate lib;
> note that the original LPC code (as opposed to the bundled subdir)
> has just been made available, upon asking, by the original author:
> https://github.com/jafingerhut/lpc10
> 
> While here, I have also done some cleaning, but nothing that
> would change SoX's actual audio behaviour. I have removed
> struct timeb, obsoleted ages ago and not even used here,
> the homegrown strcasecmp(), #ifdef HAVE_STDINT_H and
> other ancient cruft. See the git log for the lolz.
> 
> I have been running and testing this for some time on
> 
> 	OpenBSD/current (amd64, i386, arm64, armv7, powerpc, octeon)
> 	FreeBSD 14.1 (amd64)
> 	NetBSD 10.0 (amd64)
> 	macOS 14.5 (M1 MacBook Air)
> 	Debian 13.2 trixie (amd64)
> 	Solaris (SunOS 5.11)
> 
> and everything I could test seems to work. That is to say,
> the build of sox and the detection of external libs as
> optional extra formats and drivers works; the actual
> audio signal processing code, which has its own problems,
> has not been touched.
> 
> During all that, going through the individual formats,
> I have also reviewed the soxi(1) and soxformat(7) manpages,
> untouched for a decade, and synced them with reality,
> refactoring a bit, and rewriting in mdoc(7) not man(7).
> Please read them. (The monstrous sox(1) is for later.)
> 
> Please test on every system you use SoX on.  Please test
> the detection of every audio format and effect and driver
> you care about (or, better yet, test them all). If anything
> doesn't work as expected, please report here or open an issue:
> https://github.com/janstary/sox/issues
> 
> 	Thank you,
> 
> 		Jan
> 
> 
> 
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
> 

----- End forwarded message -----


_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel