mpg123-devel — Mailing list for mpg123 developers

Re: [mpg123-devel] A round of testing of upcoming mpg123 1.27.0, please.

[Dave Y. <dav...@gm...>]

On 03/31/21 08:15 AM, Thomas Orgis wrote:
> It would
> be nice if I could get a heads-up from the various platforms mpg123
> supports. So far, I got a boring x86-64 Linux system and checked if the
> compliance still works and if the performance is off. What about proper 32 bit
> x86 machines, what about 3DNow, AltiVec? It would be nice to know that
> I didn't break something in our forest of platform and hardware ifdefs.
>
> So, please, fetch a current https://mpg123.org/snapshot and reply with
> your results!
>
> Just building mpg123 and listening to some music would be fine. Bonus
> points for running the compliance tests using the procedure below.
>
> 	wget -O test.tar.gz https://scm.orgis.org/view/mpg123/test/?view=tar
> 	tar -xf test.tar.gz
> 	cd test
> 	make
> 	perl compliance.pl /path/to/mpg123
>
> I hope this can become a new release soon-ish.

Seems fine on OS/2 (x86). AS does puke on the .section directive, 
thought I'd already sent a patch to deal with that, anyways here it is 
again.
Do have a couple of more CPU options to test.
The compliance test seems to run fine here, but it may be terminating 
early, last line is,
./hex24_double.exe < compliance/layer3is/drumshort48kHz.hex > 
compliance/layer3is/drumshort48kHz.double
Thanks
Dave

Re: [mpg123-devel] [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

[Thomas O. <tho...@or...>]

Am Thu, 1 Apr 2021 20:53:07 -0400
schrieb Alan Corey <ala...@gm...>: 

> Raspberry Pi ZeroW, about 3 inches long, cost $10 from Adafruit.
> Plugged it and the USB sound card into a DrOk power monitor and
> they're using 1.25 watts (0,25 amps) idling.  So solar powering them
> would be no big deal.  Listening to some Pink Floyd with Koss R/80
> headphones, sounds fine.  I have a touchpanel LCD, one project would
> be to retrofit a boom box.  Oh, CPU usage, the peak I saw watching top
> was about 13%.

Nice. MP3 decoding really is no big task anymore for small hardware.
Though, you could compare the generic decoder with the neon one. Would
be more than 13%, I presume.

Regarding solar power: I got a 4 inch speaker with an extensible Tube
as cabinet vor bass response and a little chip amp (class D) embedded,
behind a supercap and a step-up converter. A 12 W panel is plenty to
work it, even with moderate sun being available. With the efficient
class D amp, the mean power draw is way below your 1.25 W. You just
need the cap for bass-heavy transients. The simple joys of life;-)


Alrighty then,

Thomas

Re: [mpg123-devel] [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

[Thomas O. <tho...@or...>]

Am Thu, 1 Apr 2021 20:59:28 +0200
schrieb Martin Guy <mar...@gm...>: 

> Compared with Debian stable's /usr/bin/mpg123 (1.25.10) there are many
> fewer FAILs

Well, those are still OK, as we're in the range of LIMITED accuracty,
where the maxdiff value doesn't count (acurrate rounding gives full
PASS).

Looks fine so far … nice. The situation on x86-64 is rather boring
compared to all that history of x86 optimizations.


Alrighty then,

Thomas

Re: [mpg123-devel] [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

[Thomas O. <tho...@or...>]

Am 31. März 2021 22:10:32 MESZ schrieb Alan Corey <ala...@gm...>:
>OK, it runs fine here.  Debian Bullseye on a Pinebook Pro laptop.
>Want a test on a Raspberry Pi (3B)?  ZeroW?

Any variation is good (mainly, 32 bit and 64 bit, nofpu, neon ... see --with-cpu for configure).


Alrighty then,

Thomas

Re: [mpg123-devel] [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

[Thomas O. <tho...@or...>]

Thanks! Things looking good so far.

Am 1. April 2021 01:30:57 MESZ schrieb Martin Guy <mar...@gm...>:

>This laptop has 3DNow in its cpu; does the vanilla build use that or
>do I need to compile -mcpu=native?

On x86, it's a runtime choice. See

mpg123 --test-cpu

You can give the cpu parameter to the compliance script, just append --cpu foo.

It would be reassuring to have confirmation for 3dnow, mmx, sse. Also if you notice any speed difference (time mpg123 --cpu foo --loop n  some_file.mp3  against your /usr/bin/mpg123).


Alrighty then,

Thomas

Re: [mpg123-devel] [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

[Thomas O. <tho...@or...>]

Am 31. März 2021 20:23:43 MESZ schrieb Alan Corey <ala...@gm...>:
>I guess I flunk, I don't see a new mpg123 biinary.  This is building
>on aarch64, log file made with tee.

That's one of the arches to test ... 

>cc -Wall -Werror -g -O2 -o rmsdouble.bin rmsdouble.c -lm
> [...]
>./hex24_double.bin < compliance/layer3is/drumshort48kHz.hex >
>compliance/layer3is/drumshort48kHz.double

Well, you got the compliance test infrastructure built.
Now just combine that with a fresh ./configure && make
on

https://mpg123.org/snapshot

and you hopefully have the mpg123 binary to test (via src/mpg123).


Alrighty then,

Thomas

[mpg123-devel] A round of testing of upcoming mpg123 1.27.0, please.

[Thomas O. <tho...@or...>]

Hi folks,

There are some core changes in libmpg123 scheduld for the next feature
release. Following work by Taihei on the fixed-point decoders, all
common decoding tables are now precomputed and mpg123_init() has
nothing to do anymore. The main reason for this is to make usage of the
library easier in multithreaded contexts where it is not necessarily
easy to insert a call to something like mpg123_init() which, at least
in theory, wants to run non-concurrently.

So, a lot of internal tables and their usage got moved around. It would
be nice if I could get a heads-up from the various platforms mpg123
supports. So far, I got a boring x86-64 Linux system and checked if the
compliance still works and if the performance is off. What about proper 32 bit
x86 machines, what about 3DNow, AltiVec? It would be nice to know that
I didn't break something in our forest of platform and hardware ifdefs.

So, please, fetch a current https://mpg123.org/snapshot and reply with
your results!

Just building mpg123 and listening to some music would be fine. Bonus
points for running the compliance tests using the procedure below.

	wget -O test.tar.gz https://scm.orgis.org/view/mpg123/test/?view=tar
	tar -xf test.tar.gz
	cd test
	make
	perl compliance.pl /path/to/mpg123

I hope this can become a new release soon-ish.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.26.5 relased

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

version 1.26.5 arrived:

1.26.5
------
- Add ./configure --enable-xdebug (for the resampler issue).
- Avoid denormals in the resampler by adding an alternating offset
  (helps performance without -ffast-math, depending on platform).
- libmpg123:
-- Fix ID3v2 APIC parsing when frame length bit is set (bug 306).
-- Also handle the group flag (skip the group byte).
-- Also fix up frame flag handling for ID3v2.3. Did not crop up yet,
   but it was just wrong. Impact was not detecting and bailing out on
   compressed or encrypted frames properly.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.26.4 released

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

as this weird year draws to an end, I present to you a rather mundane
mpg123 release. It's mainly build fixes people contributed for the
cmake port, but also this long-standing issue about theoretically bad
trigonometry.

1.26.4
------
- Clarify seeking documentation regarding samples and PCM frames.
- Fix build on MorphOS (patch by Ozkan Sezer, bug 295).
- Fix cmake build to install fmt123.h.
- Some cmake build fixes, tinyalsa addition by Maarten (bug 299).
- libmpg123: explicitly handle some irrelevant corner cases in tabinit
  (bug 279)

It's available at the usual places.


I wish you all a good start into the new year, which has a good chance
to being a better one for most of us than the one that is ending now.


Alrighty then,

Thomass

[mpg123-devel] mpg123 1.26.3 released (relevant for Windows OS)

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

the fre:ac userbase uncovered long-standing errors in the Windows
variant of x86-64 assembly code that wasn't in use by default in
earlier times. This release thusly contains one change:

1.26.3
------
- Fix accurate (--enable-int-quality) and s32 x86-64 assembly for Windows ABI
  (thanks to Robert Kausch of fre:ac). The accurate code just crashed before.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.26.2 released

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

version 1.26.2 just got released.

1.26.2
------
- Enable terminal control by default only when both input and output
  are connected to a terminal. This avoids messing with terminal settings
  when piping stderr to a pager, which takes over terminal input anyway,
  while mpg123 still thinks it got control.
- Windows build fixes for UWP and without GetThreadErrorMode when not
  building modules, thanks to Steve LHomme.
- Android build fix regarding off64_t use, thanks to Steve LHomme.
- More CMake build fixes thanks to David Callu (bug 290).
- Use PROG_LIBS for output modules, to reinstate not necessarily proper but
  previous behaviour and fix FreeBSD port build (bug 291).
- Refine LFS support in libsyn123, avoiding architecture-dependent syn123.h
  (debian bug 963205).


Alrighty then,

Thomas

Re: [mpg123-devel] [PATCH v2] fix lfs_alias_t type for Android

[Thomas O. <tho...@or...>]

Thanks, applied.

Am Wed, 10 Jun 2020 16:24:20 +0200
schrieb mpg123@ycbcr.xyz: 

> From: Steve Lhomme <robux4@ycbcr.xyz>
> 
> ---
>  configure.ac                   | 20 ++++++++++++++++++++
>  ports/cmake/src/CMakeLists.txt |  4 ++++
>  2 files changed, 24 insertions(+)

[mpg123-devel] [PATCH v2] fix lfs_alias_t type for Android

[<mp...@yc...>]

From: Steve Lhomme <robux4@ycbcr.xyz>

---
 configure.ac                   | 20 ++++++++++++++++++++
 ports/cmake/src/CMakeLists.txt |  4 ++++
 2 files changed, 24 insertions(+)

diff --git a/configure.ac b/configure.ac
index c494221..4fc0e36 100644
--- a/configure.ac
+++ b/configure.ac
@@ -159,6 +159,7 @@ fi
 dnl We need the windows header also for checking the module mechanism.
 AC_CHECK_HEADERS([windows.h])
 
+android_build=no
 case "$host" in
 	*-*-mingw*)
 		win32=yes
@@ -180,6 +181,21 @@ case "$host" in
 		  AC_DEFINE( [WINDOWS_UWP], 1, [Windows UWP build] )
 		fi
 	;;
+	linux*)
+		dnl Android is linux, but a bit different
+		AC_MSG_CHECKING([for an Android system])
+		AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
+				[[#ifndef __ANDROID__
+				 # error Not Android
+				 #endif
+				]],[[;]])
+		],[
+		  android_build=yes
+		  AC_MSG_RESULT([yes])
+		],[
+		  AC_MSG_RESULT([no])
+		])
+	;;
 	*)
 		win32=no
 	;;
@@ -1158,6 +1174,7 @@ AC_CHECK_TYPE(uint16_t, unsigned short)
 AC_CHECK_SIZEOF(size_t,4)
 AC_CHECK_SIZEOF(ssize_t,4)
 AC_CHECK_SIZEOF(off_t,4)
+AC_CHECK_SIZEOF(off64_t,8)
 AC_CHECK_SIZEOF(int32_t)
 AC_CHECK_SIZEOF(long,4)
 
@@ -1167,6 +1184,9 @@ dnl but it is actual plain off_t if the system does not have such switches.
 if test "x$largefile_sensitive" = xyes; then
   lfs_alias_type=long
   lfs_alias_size=$ac_cv_sizeof_long
+elif test "x$android_build" = xyes; then
+  lfs_alias_type=off64_t
+  lfs_alias_size=$ac_cv_sizeof_off64_t
 else
   lfs_alias_type=off_t
   lfs_alias_size=$ac_cv_sizeof_off_t
diff --git a/ports/cmake/src/CMakeLists.txt b/ports/cmake/src/CMakeLists.txt
index 7ea2282..4b7b931 100644
--- a/ports/cmake/src/CMakeLists.txt
+++ b/ports/cmake/src/CMakeLists.txt
@@ -109,6 +109,10 @@ check_type_size(off_t SIZEOF_OFF_T)
 if(LFS_SENSITIVE)
     set(LFS_ALIAS_TYPE long)
     math(EXPR LFS_ALIAS_BITS "${SIZEOF_LONG} * 8")
+elseif(CMAKE_ANDROID_ARCH_ABI)
+    check_type_size(off64_t SIZEOF_OFF64_T)
+    set(LFS_ALIAS_TYPE off64_t)
+    math(EXPR LFS_ALIAS_BITS "${SIZEOF_OFF64_T} * 8")
 else()
     set(LFS_ALIAS_TYPE off_t)
     math(EXPR LFS_ALIAS_BITS "${SIZEOF_OFF_T} * 8")
-- 
2.26.2

Re: [mpg123-devel] [PATCH] configure: detect WINDOWS_UWP for mingw as well

[Thomas O. <tho...@or...>]

Am Wed, 3 Jun 2020 08:04:01 +0200
schrieb Thomas Orgis <tho...@or...>: 

> can you test this on (some kind of) Mingw and commit?

Thanks … so this patch is in. The Android thing is still lingering. If
we got that off64_t stuff wrapped in some Android-specific condition,
it should also be fine.


Alrighty then,

Thomas

Re: [mpg123-devel] [PATCH] fix lfs_alias_t type for Android

[Thomas O. <tho...@or...>]

Hi Steve,

Am Tue,  2 Jun 2020 09:58:28 +0200
schrieb mpg123@ycbcr.xyz: 

> @@ -1168,8 +1169,8 @@ if test "x$largefile_sensitive" = xyes; then
>    lfs_alias_type=long
>    lfs_alias_size=$ac_cv_sizeof_long
>  else
> -  lfs_alias_type=off_t
> -  lfs_alias_size=$ac_cv_sizeof_off_t
> +  lfs_alias_type=off64_t
> +  lfs_alias_size=$ac_cv_sizeof_off64_t
>  fi

That breaks my normal 64 bit Linux build where I really want
off_t in there (oh, the foolery of the many names of a 64 bit integer
there …). Android needs off64_t instead of off_t? Doesn't that map to 64
bits?

Anyhow, can you wrap this into another if block that checks for Android?


Alrighty then,

Thomas

Re: [mpg123-devel] [PATCH] configure: don't error on GetThreadErrorMode if we're not going to use it

[Thomas O. <tho...@or...>]

Applied that simple one, thanks.


Alrighty then,

Thomas

Re: [mpg123-devel] [PATCH] configure: detect WINDOWS_UWP for mingw as well

[Thomas O. <tho...@or...>]

Hi Jon,

can you test this on (some kind of) Mingw and commit? At least that the
code runs nicely even with non-UWP. Would be bad form if I just do this
without any Windows at hand.

Am Tue,  2 Jun 2020 09:57:19 +0200
schrieb mpg123@ycbcr.xyz: 

> From: Steve Lhomme <robux4@ycbcr.xyz>
> 
> It is supported as well as with MSVC.
> 
> We need to include winapifamily.h to detect UWP builds.
> The official way is to use the WINAPI_FAMILY_PARTITION macro which is compatible between MSVC and mingw.
> 
> In UWP build we should use UNICODE API.
> ---
>  configure.ac | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index 4dfe617..917d251 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -162,6 +162,23 @@ AC_CHECK_HEADERS([windows.h])
>  case "$host" in
>  	*-*-mingw*)
>  		win32=yes
> +		AC_MSG_CHECKING([if this is a UWP build])
> +			AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
> +			  [[#include <winapifamily.h>
> +			   #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
> +			   # error Win32 Desktop build
> +			   #endif
> +			  ]],[[;]])
> +			],[
> +				uwp_build=yes
> +				AC_MSG_RESULT([yes])
> +			],[
> +				uwp_build=no
> +				AC_MSG_RESULT([no])
> +			])
> +		if test x"$uwp_build" = xyes; then
> +		  AC_DEFINE( [WINDOWS_UWP], 1, [Windows UWP build] )
> +		fi
>  	;;
>  	*)
>  		win32=no
> @@ -2284,6 +2301,9 @@ dnl We do not support non-unicode Windows.
>  if test "x$win32_specific_codes" = xenabled; then
>  #### Check for Wide functions
>    AC_CHECK_FUNC([_wopen], [win32_unicode=enabled],[win32_unicode=disabled])
> +  if test "x$uwp_build" = xyes; then
> +    AC_DEFINE([WANT_WIN32_UNICODE], [1], [ Define to use Unicode for Windows ])
> +  else
>    AC_MSG_CHECKING([if we want Unicode File Open for Win32])
>    if test "x$win32_unicode" = xenabled; then
>      dnl We need to include the header for PathCombineW checking as
> @@ -2331,6 +2351,7 @@ if test "x$win32_specific_codes" = xenabled; then
>    else
>      AC_MSG_ERROR([Unicode File Open for Win32 not available])
>    fi
> +  fi
>  
>  #### Check for Network functions
>    AC_CHECK_HEADERS([ws2tcpip.h], [win32_sockets=enabled], [AC_MSG_WARN([Please update your headers to support winsock 2.2.])])
> -- 
> 2.26.2

Alrighty then,

Thomas

[mpg123-devel] [PATCH] fix lfs_alias_t type for Android

[<mp...@yc...>]

From: Steve Lhomme <robux4@ycbcr.xyz>

---
 configure.ac                   | 5 +++--
 ports/cmake/src/CMakeLists.txt | 4 ++++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index c494221..f22047e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1158,6 +1158,7 @@ AC_CHECK_TYPE(uint16_t, unsigned short)
 AC_CHECK_SIZEOF(size_t,4)
 AC_CHECK_SIZEOF(ssize_t,4)
 AC_CHECK_SIZEOF(off_t,4)
+AC_CHECK_SIZEOF(off64_t,8)
 AC_CHECK_SIZEOF(int32_t)
 AC_CHECK_SIZEOF(long,4)
 
@@ -1168,8 +1169,8 @@ if test "x$largefile_sensitive" = xyes; then
   lfs_alias_type=long
   lfs_alias_size=$ac_cv_sizeof_long
 else
-  lfs_alias_type=off_t
-  lfs_alias_size=$ac_cv_sizeof_off_t
+  lfs_alias_type=off64_t
+  lfs_alias_size=$ac_cv_sizeof_off64_t
 fi
 
 if test "x$lfs_alias_size" = "x"; then 
diff --git a/ports/cmake/src/CMakeLists.txt b/ports/cmake/src/CMakeLists.txt
index 7ea2282..4b7b931 100644
--- a/ports/cmake/src/CMakeLists.txt
+++ b/ports/cmake/src/CMakeLists.txt
@@ -109,6 +109,10 @@ check_type_size(off_t SIZEOF_OFF_T)
 if(LFS_SENSITIVE)
     set(LFS_ALIAS_TYPE long)
     math(EXPR LFS_ALIAS_BITS "${SIZEOF_LONG} * 8")
+elseif(CMAKE_ANDROID_ARCH_ABI)
+    check_type_size(off64_t SIZEOF_OFF64_T)
+    set(LFS_ALIAS_TYPE off64_t)
+    math(EXPR LFS_ALIAS_BITS "${SIZEOF_OFF64_T} * 8")
 else()
     set(LFS_ALIAS_TYPE off_t)
     math(EXPR LFS_ALIAS_BITS "${SIZEOF_OFF_T} * 8")
-- 
2.26.2

[mpg123-devel] [PATCH] configure: don't error on GetThreadErrorMode if we're not going to use it

[<mp...@yc...>]

From: Steve Lhomme <robux4@ycbcr.xyz>

In UWP builds GetThreadErrorMode is not supported (at least not on all Win8/Win10).
But it's still possible to build mpg123 without module handling.
---
 configure.ac | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure.ac b/configure.ac
index 917d251..c494221 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2435,6 +2435,7 @@ if test x$win32_specific_codes = xenabled; then
     AC_MSG_RESULT([no])
   fi
 # Check GetThreadErrorMode
+  if test x"$modules" != xdisabled; then
   AC_MSG_CHECKING([if we have GetThreadErrorMode])
     AC_LINK_IFELSE([AC_LANG_SOURCE([
     #include <windows.h>
@@ -2457,6 +2458,7 @@ if test x$win32_specific_codes = xenabled; then
     AC_MSG_RESULT([no])
     AC_ERROR([GetThreadErrorMode is required but not found])
   fi
+  fi
 fi
 
 #### WINVER Bump
-- 
2.26.2

[mpg123-devel] [PATCH] configure: detect WINDOWS_UWP for mingw as well

[<mp...@yc...>]

From: Steve Lhomme <robux4@ycbcr.xyz>

It is supported as well as with MSVC.

We need to include winapifamily.h to detect UWP builds.
The official way is to use the WINAPI_FAMILY_PARTITION macro which is compatible between MSVC and mingw.

In UWP build we should use UNICODE API.
---
 configure.ac | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/configure.ac b/configure.ac
index 4dfe617..917d251 100644
--- a/configure.ac
+++ b/configure.ac
@@ -162,6 +162,23 @@ AC_CHECK_HEADERS([windows.h])
 case "$host" in
 	*-*-mingw*)
 		win32=yes
+		AC_MSG_CHECKING([if this is a UWP build])
+			AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
+			  [[#include <winapifamily.h>
+			   #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
+			   # error Win32 Desktop build
+			   #endif
+			  ]],[[;]])
+			],[
+				uwp_build=yes
+				AC_MSG_RESULT([yes])
+			],[
+				uwp_build=no
+				AC_MSG_RESULT([no])
+			])
+		if test x"$uwp_build" = xyes; then
+		  AC_DEFINE( [WINDOWS_UWP], 1, [Windows UWP build] )
+		fi
 	;;
 	*)
 		win32=no
@@ -2284,6 +2301,9 @@ dnl We do not support non-unicode Windows.
 if test "x$win32_specific_codes" = xenabled; then
 #### Check for Wide functions
   AC_CHECK_FUNC([_wopen], [win32_unicode=enabled],[win32_unicode=disabled])
+  if test "x$uwp_build" = xyes; then
+    AC_DEFINE([WANT_WIN32_UNICODE], [1], [ Define to use Unicode for Windows ])
+  else
   AC_MSG_CHECKING([if we want Unicode File Open for Win32])
   if test "x$win32_unicode" = xenabled; then
     dnl We need to include the header for PathCombineW checking as
@@ -2331,6 +2351,7 @@ if test "x$win32_specific_codes" = xenabled; then
   else
     AC_MSG_ERROR([Unicode File Open for Win32 not available])
   fi
+  fi
 
 #### Check for Network functions
   AC_CHECK_HEADERS([ws2tcpip.h], [win32_sockets=enabled], [AC_MSG_WARN([Please update your headers to support winsock 2.2.])])
-- 
2.26.2

[mpg123-devel] mpg123 1.26.1 released (just build fixes)

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

here is a quick follow-up to The Big 1.26.0:

1.26.1
------
- Fix cmake build by actually including the read_api_version file in the distro.
- Fix big-endian build, stupid omission of a variable declaration, semicolon
  (bug 289).
- Silence a harmless warning for build without realtime priority.


Grab it from the usual places …


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.26.0 released

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

I finally release the next big feature fest of mpg123 with version
1.26.0. You get this (same list as for rc2):

1.26.0
------

- Starting to intentionally use C99 in the codebase. API headers are still
  supposed to be compatible to C89.
- There is a make check target now that tests some text transformations.
  It is an open question how that should be developed in relation to the
  external regression and compliance test suite.
- Finally silenced memory checkers about leaking memory from getlopt()
  (main code overwriting values without freeing strdup() strings).
- AUTHORS now in UTF-8;-)
- CMake build files in ports/cmake, as an alternative to create MSVC
  project files and the like (thanks to Vitaly Kirsanov)
- Default build with proper integer rounding (--enable-int-quality) now.
- Cygwin/midipix autoconf fixes (thanks to Redfoxmoon).
- Updated Windows build script, notably renaming .dll.def to .def.
  Requires an argument now for build type, an optional one for
  parallel make (not that useful on MinGW).
- Rework library dependency handling to avoid unnecessary linking for
  lib*123. Also add proper Libs.private to .pc files to enable static
  usage (especially on Windows with shlwapi).
- Updated support for OS/2 in the form of ArcaOS.
- Removed outdated Pascal port (ports/mpg123_.pas). There are others
  out there.
- Updated man pages, been a while.
- mpg123:
-- Fixed-rate playback now prefers the libsyn123 resampler instead of NtoM
   in libmpg123, see --resample parameter.
-- Drop --STDOUT (never properly implemented, use pipe to out123 instead).
-- Make --streamdump use unintr_write() to avoid inconsistencies.
-- Now sets non-zero exit code when any one track of the playlist
   fails to either produce at least one frame of playback, if there
   is data that should produce such (i.e. /dev/zero is bad, /dev/null is
   fine). See man page for details.
-- Print out MPEG header info for each frame for mpg123 -vvvv.
-- Added --no-visual to disable cursor/inverse video games explicitly.
-- Clear progress bar before printing updated metadata within a stream.
-- Filter control/non-printable characters from user data printout, reduce
   ID3v1 data to 7-bit ASCII (no way to know correct 8-bit encoding for sure).
   This should  cover bug 267.
-- Set MPG123_NO_PEEK_END when opening special file '-' (standard input).
   That helps Windows where attempting to seek on the non-seekable stream
   is undefined behaviour (bug 285).
-- Print errors in player code also for --quiet operation (just no messages
   from the libraries).
-- Ignore ID3v1 once a Frankenstein stream was detected.
-- Prevent a cosmetic use-after-free in audio playback during program abortion just after
   starting playback (prebuffer still in use, implication a blip of bad sound and
   a complaining sanitizer).
-- Reformat audio capabilities table, more condensed, fits into 80 columns.
   Forced rate on a separated line.
-- Make --pitch actually work, not just interactive changes. Pitching uses
   a resampler now if a fixed output rate is specified.
-- Added --no-frankenstein.
-- Frameflags as long variable, 32 bits are needed since some time now.
- out123:
-- Document --STDOUT, make it more robust regarding fwrite() interruptions.
-- Removed the implicit phase shift that made generated waves exactly at
   Nyquist freq non-silent, but made little sense overall.
-- Less high-frequency shifts to make waves fit into the table (not insisting
   on even number of samples).
-- Option to work without wave table (setting the limit to zero).
-- Added --wave-direction to also enable backward time without phase shift.
-- Waves now generated by re-usable little synthethizer library dubbed
   libsyn123.
-- Pink noise from libsyn123 added (using code from Phil Burk).
-- White noise from libsyn123.
-- Geiger-Mueller counter simulation from libsyn123.
-- Wave sweep generator from libsyn123.
-- Some rearrangement in help text.
-- Changed output of --test-encodings to list of encoding names
   instead of raw bitmask value.
-- Added --endian, --inputend, and --byteswap.
- libsyn123:
-- Created the library to host some simple signal generators for testing
   output.
-- It also hosts sample format conversions as a necessity to be able to
   directly produce the format output devices need.
-- Well, also channel mixing while we're at it.
-- Oh, and a minimal-latency-and-reasonably-efficient resampler that only
   took me over a year to figure out. I should write a paper about it.
- libout123:
-- Added out123_free() for the benefit of library wrappers. (bug 276)
-- Removed change of effective user ID in the WAV/RAW/AU/CDR writer.
   This was intended as a safeguard to avoid creating files with root
   priviledges. But: Other output modules still allowed root-level
   access to various devices and files, so it was never safe to do
   something awful like installing mpg123 with suid bit or configure
   sudo to allow users to run mpg123 with arbitrary arguments.
   You should treat out123_open just like the regular open(): You can
   write to any file/device depending on your permissions.
-- Finally maybe fixed the damaged playback when using pulse hidden
   behind the ALSA API (on Ubuntu, for example) by setting a high value
   for device start threshold.
-- Fixed out_play() abortion logic to better detect fatal situations
   (broken pipe). Needed on FreeBSD, while Linux buffers the issue away.
   Should resolve bug 283.
-- Limit size of buffer block being written in out123_play to 16K, avoiding
   unnecessary failure with ALSA at least.
-- Using SDL2 now if found. Output module code unchanged.
-- Added hex and txt (plain text) printout.
-- Eliminated spots where error messages would still be printed
   also for OUT123_QUIET being effect.
-- Dummy output accepts any encoding now.
- libmpg123:
-- Added mpg123_open_fixed() to ease API for applications that just
   want to decode well-behaved local files.
-- The user buffers for audio output data are now declared as void* for
   mpg123_read(), mpg123_decode(), and mpg123_replace_buffer() to avoid
   the useless need for casting your nice int16_t buffer to unsigned char
   for decoding MPG123_ENC_SIGNED_16 data to it.
-- Added mpg123_free() for the benefit of library wrappers. (bug 276)
-- Add mpg123_format2() and mpg123_fmt2() supporting special value 0 for all
   rates.
-- Fix changing of decoder (and output format along with that) after stream
   opening. This was never recommened and only now should work at all.
-- Also mpg123_decode_frame() now sets return buffer to NULL and returned byte
   count to zero in case of MPG123_NEED_MORE (or any other early abort).
-- MPG123_NEED_MORE not returned anymore for non-feeder streams. Got in
   there for generic partial frame body reads, but was only intended for
   feeder API.
-- Added mpg123_set_moreinfo() to support the Lame project's frame analyzer,
   disabled by ./configure --disable-moreinfo.
-- Added optional storage and retrieval of raw ID3 data.
-- Fix skipping of ID3v2 footers (too much was attempted to be skipped). This
   is of not much practical consequence as a tag with footer would appear on
   the end of files anyway and files with ID3v2 tags at the end seem to be
   rather rare.
-- Add mpg123_new_string() and mpg123_delete_string() to avoid confusion
   about what mpg123_init_string() and mpg123_free_string() do.
-- Make mpg123_resize_string() terminate the string if shrinking (fill now
   limited to new size).
-- Improve layer III frame parsing/error reporting for bad part2_3_length.
-- Fix crashing on stupidly low NtoM rates (exceeding downsampling factor 31).
   This was only triggered by you specifying a forced sampling rate below 1550 Hz.
-- Do not remove CRC bits twice from possibly available bit reservoir.
   This move needed recomputation of the layer3is reference data for 8 and
   24 kHz. Old mpg123 is _wrong_ in the first few frames.
-- Generally more tight control and early bail out on reading bits of
   frame data for all layers. This reduces the count of error messages
   on badly damaged files a lot and feels a lot safer, too. Note that
   we already silently returned zero bytes instead of actually over-reading
   the frame buffer before, but now it happens with diagnostics and more
   checks before it may happen.
-- Optionally enforce output endianess (big/little) away from native.
-- Fix build without error messages.
-- Fix build without gapless decoding.
-- Disable buffer when neither mmap nor shm functions detected (fixes
   build for Android, thanks to vquicksilver).
-- Some support for extremely small streams (below 128 bytes). Those are
   too short to contain anything useful besides some tiny metadata, but
   serve to find/reproduce parser bugs.
-- Fix mpg123_read() for builds without feeder. It calls mpg123_decode()
   without feeding input, which was disabled by mistake. The use of
   mpg123_read() (instead of mpg123_decode_frame()) with mpg123_open()
   was broken in feederless builds since those were fixed in version 1.15.
-- Fix ID3v2 parser logic for multiple ID3v2 tags being encountered in one
   stream. New tags replace old data instead of appending to it when the
   extended header update flag is not set (ID3v2.4). Update tags only
   replace data that shall be unique. So far, I have never seen an update
   tag in the wild, so the check for the flag is untested. The mechanism
   of replacing parts of existing tag data has been tested, though.
   Note that the updated libmpg123 also avoids a growing ID3 data structure
   when repeatedly seeking back to the beginning in a file with disabled
   seek index.
-- Eliminated a spots where error messages would still be printed
   also for MPG123_QUIET being effect.
-- Added MPG123_NO_FRANKENSTEIN, MPG123_FLOAT_FALLBACK flags.
-- Now actually try floating point encoding if format matrix allows it
   (can be disabled by unsetting MPG123_FLOAT_FALLBACK).
-- Added mpg123_feature2() that takes an int, as enums are not ABI-safe,
   also added feature queries for floating point output. 


Also, the experiment with the merged mpg123-discuss list officially
failed. I'm closing it. Please forget it existed.


Alrighty then,

Thomas

Re: [mpg123-devel] mpg123 1.26rc3 released

[Thomas O. <tho...@or...>]

Well, then.

Since I see no new issues coming up with 1.26rc3, I intend to turn it
into a final release very soon (about tomorrow).

Regarding the race for only one mailing list, it seems like I have to
admit defeat. The current subscriber counts:

- devel: 19
- users: 28
- discuss: 11

So if that does not drastically change during a day, I will close the
new list -discuss with the release and you all can continue with your
existing filters and chuckle about this little failed experiment;-)

And of course you have the last-minute chance to report any issue with
the 1.26rc3.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.26rc3 released

[Thomas O. <tho...@or...>]

Dear mpg123 people,

I just released mpg123 1.26rc3 with only a few changes relating to
build and documentation. This changed compared to 1.26rc2:

- Install libsyn123.pc file in main build system.
- Add NEWS.libsyn123.
- Update doxygen files for libsyn123 addition.
- Set library API versions also in CMake build (thanks to David Callu,
  bug 287).
- Fix some casts in printouts to silence clang (on 32 bit).
- Check for SIZE_MAX > UINT64_MAX before doing silly check for
  larger-than-64-bits sizes, to silence clang.
- Fix typos in NEWS.

And remember: The race is still open for the future of the mailing
lists. With the impending release of 1.26.0, it will be decided if the
project will keep separated lists for users and developers or just use
one discussion list for the rather low overall volume. If you prefer
one or the other, make sure you are subscribed to your preference.

If the count of subscribers to mpg123-discuss is close to the others, I
assume the shift is taking place. If not, the new list will be closed
again. So (un)subscribe at your will:

	https://sourceforge.net/p/mpg123/mailman/mpg123-discuss/
or
	https://sourceforge.net/p/mpg123/mailman/mpg123-devel/
	https://sourceforge.net/p/mpg123/mailman/mpg123-users/


Alrighty then,

Thomas

-- 
GPG public key 60D5CAFE: https://thomas.orgis.org/public_key
Fingerprint: D021 FF8E CF4B E097 19D6  1A27 231C 4CBC 60D5 CAFE
And despite all of you, I'm still doing it. Yes, I do write Perl code.

Re: [mpg123-devel] [mpg123-users] New merged mailing list for mpg123 discussion

[Thomas O. <tho...@or...>]

Am Sun, 10 May 2020 23:07:01 +0200
schrieb Martin Guy <mar...@gm...>: 

> Developers if it regards people (potentially) modifying the code base,
> users for people using it […] but not expecting to have to dig into the
> source code.

Sure, but what's with discussion of possible changes in the code?
Developers might have an idea they like, but it would have consequences
for users that they did not think about. Users could jump in early in
the process. I think that synergy has value that for bigger projects is
overshadowed by the issue of high volume of posts. But then, really big
projects need further divisions. Try to get a discussion on LKML … or
anyone notice your patch proposal at all (I tried, with CC to the
maintainer of the portion of code I was patching …)!

But back to developer discussions: Frankly, this mostly takes place in
IRC (#mpg123 on freenode) or in my head. There are occasional
contributions from people that they share, again, often personally to
me. Some more complicated issues and patches get communicated to the
list.

The place for serious developer discussion about definite development
issues (bug or feature) is actually the bug tracker. We got already
several channels to choose from.

> I guess other developers using libmpg123 but not expecting to modify
> its internals are "users" in this case.

Yes. I do consider people building their applications using the library
users of the project.

I'm still open for the outcome of this attempted merge. And I hope you
have no hard feelings if it does go through. The current subscriber
score is this:

- mpg123-devel:  21 (-1)
- mpg123-users:  29 (-2)
- mpg123-discuss: 8 (+8)

Most people are still watching the game and stay on the old lists,
too. I am keeping this open till the release of mpg123-1.26.0 (so,
something like two weeks). The announcement of the release will be on
all lists in any case, along with the announcement of mailing list
future. If the count of mpg123-discuss is not at least on par with the
bigger of the other two (± 5, adjusting for inactive folks), I consider
the attempt failed and will remove it again. 


Alrighty then,

Thomas

PS: It's a tad ironic that this discussion about separation of
discussions is providing a peak of activity for both lists now, with
two people being involved;-)