mpg123-devel — Mailing list for mpg123 developers

[mpg123-devel] mpg123 1.28.2 released (for sndio)

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

Hi folks,

as a quick follow-up, there is mpg123 1.28.2 now, completing the fix
for bug 314. Better jump directly to that if sndio is relevant for you.

1.28.2
------
- libout123
-- Complete the fix for bug 314, reopening the device after format
   setup failure.

1.28.1
------
- build:
-- Explain --with-default-audio in configure help better.
-- Fix build of arm_fpu (regression of configure reorg).
-- Re-introduce AC_PROG_C_C99 macro for autoconf 2.69, it's only
   obsolete after that.
-- Un-break CMake build for botched move of CheckCPUArch.c.in (bug 315).
-- Avoid conflict of warning macro with MSVC pragmas in two places. Also
   fix UWP build with strerror check and move down inclusion of intsym.h
   (bug 316).
-- Disable libout123 (and mpg123, out123) on UWP with cmake to get at least
   the decoder lib built (317).
-- Hack around CMake bug(?) with QUERY_HAS_FPU to make ports/cmake also
   work in MinGW (bug 318).
- libmpg123:
-- Make mpg123.h.in usable again with MPG123_NO_CONFIGURE,
   for external uses (bug 313).
-- Use predefined MPG123_API_VERSION in mpg123.h.in for the same.
-- Better handle the ssize_t situation via typedef mpg123_ssize_t, less
   likely to be broken in future MSVC versions.
-- Fix an integer constant definition for the most negative 32 bit numnber to
   avoid justified compiler complaints.
- libsyn123:
-- More support for MPG123_NO_CONFIGURE.
-- Optionally use predefined SYN123_API_VERSION in syn123.h.in for the same.
-- Add a cast to silence integer sign warning for offset in muloffdiv64()
   (bug 317)
- libout123:
-- Pulse module advertises wider format support now, not
   just s16. This makes mpg123 -e s24 work with it, not just out123.
-- Optionally use predefined OUT123_API_VERSION in out123.h.in for
   non-configure use.
-- Fix sndio output to properly query device format support and get
   default fomat on FreeBSD (bug 314).

Get it from http://mpg123.org/download.shtml as usual.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.28.1 released

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

Hi folks,

there is a new mpg123 relese that cleans up some build issues and
improves a bit on the output side.

1.28.1
------
- build:
-- Explain --with-default-audio in configure help better.
-- Fix build of arm_fpu (regression of configure reorg).
-- Re-introduce AC_PROG_C_C99 macro for autoconf 2.69, it's only
   obsolete after that.
-- Un-break CMake build for botched move of CheckCPUArch.c.in (bug 315).
-- Avoid conflict of warning macro with MSVC pragmas in two places. Also
   fix UWP build with strerror check and move down inclusion of intsym.h
   (bug 316).
-- Disable libout123 (and mpg123, out123) on UWP with cmake to get at least
   the decoder lib built (317).
-- Hack around CMake bug(?) with QUERY_HAS_FPU to make ports/cmake also
   work in MinGW (bug 318).
- libmpg123:
-- Make mpg123.h.in usable again with MPG123_NO_CONFIGURE,
   for external uses (bug 313).
-- Use predefined MPG123_API_VERSION in mpg123.h.in for the same.
-- Better handle the ssize_t situation via typedef mpg123_ssize_t, less
   likely to be broken in future MSVC versions.
-- Fix an integer constant definition for the most negative 32 bit numnber to
   avoid justified compiler complaints.
- libsyn123:
-- More support for MPG123_NO_CONFIGURE.
-- Optionally use predefined SYN123_API_VERSION in syn123.h.in for the same.
-- Add a cast to silence integer sign warning for offset in muloffdiv64()
   (bug 317)
- libout123:
-- Pulse module advertises wider format support now, not
   just s16. This makes mpg123 -e s24 work with it, not just out123.
-- Optionally use predefined OUT123_API_VERSION in out123.h.in for
   non-configure use.
-- Fix sndio output to properly query device format support and get
   default fomat on FreeBSD (bug 314).


Get it from http://mpg123.org/download.shtml as usual.


Alrighty then,

Thomas

Re: [mpg123-devel] how to create Draining buffer

[Didier C. <did...@ya...>]

Hello Mr. Thomas Orgis

I looked in the source file "mpg123-1.28.0.tar.bz2" for your code and I was able to follow the example.

I adapted it in my "Player" program, it works great

Thank you so much
Didier

Didier CastellacciDéveloppeur C/C++ QT/GTK/.NETVisitez mon site web : www.system-caisse.com 

    Le mardi 15 juin 2021, 18:55:28 UTC+2, Thomas Orgis <tho...@or...> a écrit :  
 
 Am Tue, 15 Jun 2021 12:30:22 +0000 (UTC)
schrieb Didier Castellacci via mpg123-devel <mpg...@li...>: 

> Do you have any ideas for me to be able to develop the same thing?

Sure. Just look at what src/mpg123.c does;-)

/* Drain output device/buffer, but still give the option to interrupt things. */
static void controlled_drain(void)
{
        int framesize;
        size_t drain_block;

        play_prebuffer();

        if(intflag || !out123_buffered(ao))
                return;
        if(out123_getformat(ao, NULL, NULL, NULL, &framesize))
                return;
        drain_block = 1152*framesize;
        if(param.verbose)
                fprintf(stderr, "\n");
        do
        {
                out123_ndrain(ao, drain_block);
                if(param.verbose)
                        print_buf("Draining buffer: ", ao);
#ifdef HAVE_TERMIOS
                if(param.term_ctrl)
                        term_control(mh, ao);
#endif
        }
        while(!intflag && out123_buffered(ao));
        if(param.verbose)
                fprintf(stderr, "\n");
}


If you don't want to be able to interrupt things, you can just call
out123_drain(). The fluff around it is just to figure out a block for
out123_ndrain() and to react to key presses … and to give that progress
info.


Alrighty then,

Thomas
  

Re: [mpg123-devel] how to create Draining buffer

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

Am Tue, 15 Jun 2021 12:30:22 +0000 (UTC)
schrieb Didier Castellacci via mpg123-devel <mpg...@li...>: 

> Do you have any ideas for me to be able to develop the same thing?

Sure. Just look at what src/mpg123.c does;-)

/* Drain output device/buffer, but still give the option to interrupt things. */
static void controlled_drain(void)
{
        int framesize;
        size_t drain_block;

        play_prebuffer();

        if(intflag || !out123_buffered(ao))
                return;
        if(out123_getformat(ao, NULL, NULL, NULL, &framesize))
                return;
        drain_block = 1152*framesize;
        if(param.verbose)
                fprintf(stderr, "\n");
        do
        {
                out123_ndrain(ao, drain_block);
                if(param.verbose)
                        print_buf("Draining buffer: ", ao);
#ifdef HAVE_TERMIOS
                if(param.term_ctrl)
                        term_control(mh, ao);
#endif
        }
        while(!intflag && out123_buffered(ao));
        if(param.verbose)
                fprintf(stderr, "\n");
}


If you don't want to be able to interrupt things, you can just call
out123_drain(). The fluff around it is just to figure out a block for
out123_ndrain() and to react to key presses … and to give that progress
info.


Alrighty then,

Thomas

[mpg123-devel] how to create Draining buffer

[Didier C. <did...@ya...>]

Hello

with mpg123 when we use the buffer example mpg123 -b 700 at the end of the mp3 there is a countdown "Draining buffer: [00: 00.00]"

I would like to do the same on my "Player mp3"

Do you have any ideas for me to be able to develop the same thing?

Thank you
Didier


Didier CastellacciDéveloppeur C/C++ QT/GTK/.NETVisitez mon site web : www.system-caisse.com

Re: [mpg123-devel] How to use out123_set_buffer()

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

Am Sun, 13 Jun 2021 07:35:36 +0000 (UTC)
schrieb Didier Castellacci via mpg123-devel <mpg...@li...>: 

> buffer_bytes = 700;
> out123_set_buffer(ao, buffer_bytes);
>
> how should i use out123_set_buffer () API to be able to play smooth mp3 music

The buffer is really present in your build, right? You might want to
check the return value of out123_set_buffer() to make sure.

But mainly: 700 bytes is way to small for smooth playback. The mpg123
argument is taken as count of KiB, so it does

out123_set_buffer(ao, param.usebuffer*1024)

You're off by some magnitudes here with 700 bytes;-)


Alright then,

Thomas

[mpg123-devel] How to use out123_set_buffer()

[Didier C. <did...@ya...>]

Hello,

I have a very small problem using the out123_set_buffer() API here is what I did : 




ao = out123_new();

buffer_bytes = 700;
out123_set_buffer(ao, buffer_bytes);

out123_open(ao, driverao, outfileao);
out123_driver_info(ao, & driverao, & outfileao);
out123_start(ao, rate, channels, encoding);

out123_play(ao, (char *) buffer, done);



When reading my mp3 music the reading is jerky
not fluid

how should i use out123_set_buffer () API to be able to play smooth mp3 music

Thank you
Didier


Didier CastellacciDéveloppeur C/C++ QT/GTK/.NETVisitez mon site web : www.system-caisse.com

[mpg123-devel] mpg123 IRC channel

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

Hi,

you might have noticed some upheaval in the world if Internet Relay
Chat (if not, then this message is probably not relevant to you;-). We
got #mpg123 on libera.chat now. The other channel also exists, but
future is looking rather bleak. I'm still watching the whole drama fade
out.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.25.15 stealth release for conservatives

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

Hi folks,

following specific demand, I am releasing mpg123 1.25.15 as stealthy
backport release, skipping the even more stealthy 1.25.14:

(1.25.15)
-------
- libmpg123: Backport bit reservoir CRC fix from 1.26

(1.25.14)
-------
- libmpg123: Backport part2_3_length regression fix (bug 312).


You find it on sf.net under

	https://sourceforge.net/projects/mpg123/files/mpg123/1.25.15/

as well as in

	https://mpg123.org/download/
.

You can use these as sources for a software collection that wants to
stay on the old trusted path of 1.25.x but doesn't want to import the
patches on top.


Alrighy then,

Thomas

Re: [mpg123-devel] mpg123 1.28.0 released

[Peter K. <pe...@ko...>]

>>>>> "Thomas" == Thomas Orgis <tho...@or...> writes:

Hi,

 >> Out of interest, why not do normal releases of these? Wouldn't that make
 >> it more likely that distributions would pick them up?

 > I don't know. I imagine a stable distro not wanting to change the base
 > tarball a package is built from, but willing to add patches they
 > reviewed. Thinking about RHEL kernels as an extreme case of 'it says
 > 3.13 on the tin because based on that, but is patched up beyond
 > recognition' (bad example for release tarballs, as they'll have their
 > git branches).

I guess it depends a lot on the distribution. I indeed know that RHEL
and Debian typically cherry-pick patches rather than bumping the
version, but other distributions (like Buildroot) are fine with updating
to the latest bugfix releases if provided by upstream.

I guess it is an open question what variant is safest.


 >> With my Buildroot hat on, I can say that it would for us at least.

 > … but upgrading to the actual current stable release of mpg123 (1.28.0)
 > is not happening?

We support both a yearly "LTS" version (from February) and a current
version that gets released every 3 months. The LTS version is currently
using 1.25.13, so I would prefer to stick to 1.25.x - But for the
current version there is no problem going to 1.28.0.


 > If you say it really helps, I can upload tarballs of those. But so far,
 > mpg123 was not really doing differing release streams.

Yes please. Given that you have already done the work to backport those
fixes it IMHO makes sense to do the (presumably fairly limited?) effort
to also upload the tarballs to make it more visible.

Thanks!

-- 
Bye, Peter Korsgaard

Re: [mpg123-devel] mpg123 1.28.0 released

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

Am Mon, 07 Jun 2021 22:58:23 +0200
schrieb Peter Korsgaard <pe...@ko...>: 

> Out of interest, why not do normal releases of these? Wouldn't that make
> it more likely that distributions would pick them up?

I don't know. I imagine a stable distro not wanting to change the base
tarball a package is built from, but willing to add patches they
reviewed. Thinking about RHEL kernels as an extreme case of 'it says
3.13 on the tin because based on that, but is patched up beyond
recognition' (bad example for release tarballs, as they'll have their
git branches). 

> With my Buildroot hat on, I can say that it would for us at least.

… but upgrading to the actual current stable release of mpg123 (1.28.0)
is not happening?

If you say it really helps, I can upload tarballs of those. But so far,
mpg123 was not really doing differing release streams.


Alrighty then,

Thomas

Re: [mpg123-devel] mpg123 1.28.0 released

[Peter K. <pe...@ko...>]

>>>>> "Thomas" == Thomas Orgis <tho...@or...> writes:

Hi,

 > For those looking for fixes for 1.25 and 1.26, I prepared backport branches:

 > http://scm.orgis.org/view/mpg123/branches/1.25-fixes/

 > and

 > http://scm.orgis.org/view/mpg123/branches/1.26-fixes/

 > Those contain the code that would have been shipped as followup-releases, if I did these.
 > The 1.25 one also contains the fix for the double crc removal so that
 > the compliance test passes now.

 > I hope this enters LTS distros as a regular update.

Out of interest, why not do normal releases of these? Wouldn't that make
it more likely that distributions would pick them up?

With my Buildroot hat on, I can say that it would for us at least.

-- 
Bye, Peter Korsgaard

Re: [mpg123-devel] mpg123 1.28.0 released

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

Am Sat, 5 Jun 2021 18:32:15 +0200
schrieb Thomas Orgis <tho...@or...>: 

> Among all the build noise, the regression fix in the decoder warrants
> some attention. I might publish patches for that one to fix 1.25.x in
> stable distros. It buggers me a lot having that in the wild.

For those looking for fixes for 1.25 and 1.26, I prepared backport branches:

http://scm.orgis.org/view/mpg123/branches/1.25-fixes/

and

http://scm.orgis.org/view/mpg123/branches/1.26-fixes/

Those contain the code that would have been shipped as followup-releases, if I did these.
The 1.25 one also contains the fix for the double crc removal so that the compliance test passes now.

I hope this enters LTS distros as a regular update.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.28.0 released

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

Hi folks,

there comes a fresh mpg123 distribution:

1.28.0
------
- build:
-- Fix up the build to actually build all library objects with libtool
   consistently, also ensuring no pointless static archives for output
   modules.
-- Adapted things to autoconf 2.71, requiring 2.69 now (the latter tested
   on Debian, with their patches).
-- Improved configure to be more useful --with-default-audio to define
   the search order, fix static build for --with-audio being a list
   (just choosing the first one).
-- Ensure consistent use of LINK_MPG123_DLL in headers.
- build (ports/cmake):
-- Thanks to Evgeni Poberezhnikov for working with us on that.
-- Fix up ports/cmake to really work in MSVC also for users of the lib
   (tested in vcpkg, bug 310).
-- Hardcode ports/cmake CPU detection for x64 and ARM as
   CMAKE_SYSTEM_PROCESSOR is useless crap (bug 298 for real).
-- Add missing io.h for _setmode() MSVC warned about (bug 311).
-- Added BUILD_NO_LARGENAME define to be used by MSVC builds. Note that
   an MSVC build of libmpg123 does not support 64 bit file offsets.
   That would need more morting to the explicit API. Thanks to MS for
   making off_t even more messy and less useful.
-- Added JACK output, fixed handling of compat_str there and in win32_wasapi.
- libsyn123: Fix syn123_mix() to actually do intermediate conversion
  when input and output encoding are the same but non-float. This makes
  out123 --mix work with s16 input and output, which is not that special!
- libmpg123: Fix misguided handling of part2_3_length checks in
  III_get_scale_factors_1() and III_get_scale_factors_2() which invalidated
  decoding of a mono source encoded as ms+i-stereo (bug 312). This was
  a regression introduced with version 1.25.7.
- libout123:
-- Print basic module loading errors only for last one in list.
   This enables use of an output module search list that anticipates module
   files not installed with the main package.
-- Fixes for win32_wasapi build with MSVC.


Among all the build noise, the regression fix in the decoder warrants
some attention. I might publish patches for that one to fix 1.25.x in
stable distros. It buggers me a lot having that in the wild.


Alrighty then,

Thomas

Re: [mpg123-devel] Changes to the mpg123 build system, please re-check all your funky platforms

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

On 05/23/21 09:24 PM, Thomas Orgis wrote:
> (Certain reason why you reply off-list?)

Stupidly hit reply instead of reply list, taking it back to the list.

>
> Am Sun, 23 May 2021 18:12:29 -0800
> schrieb Dave Yeo <dav...@gm...>:
>
>> It does build with cpu=mmx, i586 and i486 as well as a quick build on a
>> handy svn rev 4827 with cpu=sse.
>> Appears that dct64_sse_float.o is referenced twice while linking mpg1230.dll
>> It's an out of tree build.
>
> Thanks. This is exactly what I was looking for … my box had no issue
> with a sse build. Not every toolchain has a problem with the repeated
> presence of an object file.

Yes our GCC fork is a bit different as it converts to native obj format.

>
> I removed the additional reference in src/libmpg123/Makemodule.am. It
> should work now from trunk.
>

This fixes the build here, thanks
Dave

[mpg123-devel] Changes to the mpg123 build system, please re-check all your funky platforms

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

Hi folks,

a particular build environment prompted me to fix up the switchery with
the various combinations of objects that make up libmpg123. This means
that I possibly broke any platform that I do not have at hand right now.

It would be very good if you could have a go with the current

	https://mpg123.org/snapshot

especially on systems that are not Linux/x86-64 and report any issues.
In theory, nothing of substance has changed, but there might be typos
to catch.

Here is the commit message for a bit more detai:

------------------------------------------------------------------------
r4900 | thor | 2021-05-23 21:12:43 +0200 (So, 23 Mai 2021) | 16 lines

build: rework to properly handle libs with libtool

The optional objects in libmpg123 meant that parts were built
with libtool as part of the library with its flags and others
without. Now, one list of sources is built from AM_CONDITIONALs
like with the other libs.

A -shared is added to the library CFLAGS to ensure we are not
fooled by a replaced libtool that ignores our M4 macros for
disabling static libs by default.

Specifically, the output modules now get a fixed -shared in 
there to avoid any pointless static archives possibly being
crated.


------------------------------------------------------------------------



Alrighty then,

Thomas

[mpg123-devel] A little mpg123 update: 1.27.2

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

Dear mpg123 folks,

a small bugfix release follows 1.27.0 (there was no 1.27.1 releaase,
just a tag in the repository):


1.27.2
------

(Trying some svn tag discipline: 1.27.1 has been tagged before, but
not released. Let's increment for any change.)

- Removed ports/Xcode, ports/cmake should handle that case.
- Ensure debug.h is included last where it matters to avoid
  conflicts with debug/warning macros in system headers
  (bug 308).
- Fix some debug/printf integer casts for 32 bit platforms (bug 309).

You get it from

	https://mpg123.org/download.shtml

as usual.


Alrighty then,

Thomas

[mpg123-devel] releasing mgp123 1.27.0

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

Dear MPEG players,

version 1.27.0 of mpg123 arrived with these changes:

1.27.0
------

- libmpg123:
-- Running on precomputed tables now, no need to call
   mpg123_init() anymore. That and mpg123_exit() are both just
   empty shells. You can omit them if you do not care about earlier
   libmpg123. You can check for MPG123_API_VERSION >= 46.
-- Added API that avoids enums, mapped-to by default unless
   MPG123_ENUM_API is defined.
- libout123:
-- Added API that avoids enums, mapped-to by default unless
   MPG123_ENUM_API is defined.
-- Added device enumeration for win32, win32_wasapi, alsa, pulse.
   This increments the output module ABI version to 3.
-- You can choose output devices now on Windows.
-- Changed default output module order to put pulse before alsa since
   we now ensure that pulse is not inadvertedly started by the
   autospawn feature. This improves the experience on desktop
   systems with pulse where the alsa to pulse use causes glitches.
   Note that on a modern Linux desktop (Ubuntu), you will not
   escape an instance of pulseaudio being started, with even the
   enumeration of the ALSA default device summoning the daemon.
   If you _want_ sound daemon autospawn behaviour on other platforms,
   you need to trigger it outside of libout123.
- examples: Update for dropped mpg123_init(), more sensible
  copyright notes.
- out123:
-- safer limiting of maximum playback rate
-- Added --list-devices.
- mpg123:
-- Fix --continue output to print track_count+1 as continue
   position after hitting the end of playlist. Makes scripts/conplay
   go to back to the beginning again (regression in 1.24.0, bug 250).
-- Remote control API version 9 with @I { .. @I } wrapping of ID3 and
   playlist display.
-- Added --list-devices.
-- Fix console printout on Windows.
-- Fix terminal control logic to better handle cases where stdin or
   stderr is not a terminal, also avoid enabling control if you specify
   stdin as input file.
- Updated debugging/warning/error message macros to include the function
  name.


In short: cleaned up API, output device listing and choice, less
terminal screwup.

Get it from http://www.mpg123.org/download.shtml and make the world a
little bit better by updating your install to this version.


Alrighty then,

Thomas

Re: [mpg123-devel] Windows wasapi mode device listing support

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

On 04/18/21 08:49 AM, Thomas Orgis wrote:
> Anyhow, if you know a bit about audio programming on your *BSD or OS/2
> box, please consider sending a patch to implement device listing,
> looking at src/libout123/modules/dummy.c for the interface
> (enumerate_dummy()).

For OS/2, currently, without completely rewriting the module, different 
devices don't make sense.
Dave

Re: [mpg123-devel] Windows wasapi mode device listing support

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

Am Sat, 17 Apr 2021 14:19:52 +0000
schrieb Jonathan Yong <10...@gm...>: 

> The wasapi module now has support for listing and selecting playback 
> devices:

I want to point out that Jonathan was busy and also the plain win32
output can do enumeration and selection now (via simple numeric IDs). I
added the same for alsa and pulse in current svn trunk (to appear in a
snapshot around midnight CET). So these work now:

mpg123 -o win32 --list-devices
mpg123 -o win32_wasapi --list-devices
mpg123 -o alsa --list-devices
mpg123 -o pulse --list-devices

and just as example to base other modules on, the dummy also lists some:

$ mpg123 -o dummy --list-devices
foo     some dummy device
bar     some other dummy device

I did not bother writing something for OSS as /dev/dspX is in plain
sight. Simple. But for OSS v4 it there might be more to get. If you
fancy device listing for your platform, we welcome patches to add an
enumerate function to the respective module.

Things seem on track for releasing mpg123 1.27.0 soon. I am looking
into avoiding the pulse plugin to start a server itself, so that it
could be put in the list of modules to test before alsa on modern Linux
desktop systems … the alsa → pulse layer can introduce issues that
plain pulse or alsa usage does not have. Hopefully the next release
uses pulse by default if it sees a running server and alsa otherwise.

Other systems don't have the issue of too many sound APIs;-)

Anyhow, if you know a bit about audio programming on your *BSD or OS/2
box, please consider sending a patch to implement device listing,
looking at src/libout123/modules/dummy.c for the interface
(enumerate_dummy()).


Alrighty then,

Thomas

[mpg123-devel] Windows wasapi mode device listing support

[Jonathan Y. <10...@gm...>]

The wasapi module now has support for listing and selecting playback 
devices:

mpg123.exe -o win32_wasapi --list-devices
Devices for output module win32_wasapi:
{0.0.0.00000000}.{10A23E73-ED10-459C-B062-FC580CE0E3D9} Out: default
{0.0.0.00000000}.{2E1C9BD0-5B2B-4016-AD83-A14390CA44DE} Out: HDA NVidia 
- HDMI 5
{0.0.0.00000000}.{31083A05-0AD6-447A-9A97-B2D15E9F9BC4} Out: HDA Intel 
PCH - ALC1220 Analog
{0.0.0.00000000}.{4A9E7F20-3B29-4BFD-B0B0-D278FD047945} Out: 2-Loopback 
- Loopback PCM

The above is a sample output from a Linux machine under Wine, to select 
a device for audio playback, do:

mpg123.exe -o win32_wasapi -a 
"{0.0.0.00000000}.{10A23E73-ED10-459C-B062-FC580CE0E3D9}" <MP3 File>

Wasapi audio is now defaulting to shared mode instead of exclusive mode.

Please help test out the code by getting the latest code from SVN trunk 
or downloading from https://mpg123.org/snapshot.

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

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

On 04/02/21 09:09 AM, Thomas Orgis wrote:
> Am Fri, 2 Apr 2021 08:46:20 -0800
> schrieb Dave Yeo <dav...@gm...>:
>
>> OK, operator error. Rereading your directions, setting up the
>> environment so the DLLs can be loaded, it seems to run fine besides the
>> output having the wrong line endings for the console to display
>> correctly, worked around by piping the results to a file or less.
>
> Hm, no … the compliance test is wholly broken. I did not write it with
> too much portability in mind (just a bit, though).
>
> fl2.bit:	RMS=     nan (FAIL) maxdiff=0.000000e+00 (PASS)
> fl3.bit:	RMS=     nan (FAIL) maxdiff=0.000000e+00 (PASS)
> fl4.bit:	RMS=     nan (FAIL) maxdiff=0.000000e+00 (PASS)
>
> The computations don't work at all. Also, the regression tests …
> there's some basic breakage apparently with some of them.
>
>> out123_passthrough:                                       FAIL
>
> no idea
>
>> basic_resync:                                             FAIL
>
> You get:
>
> TEST: Output of ./basic_resync.bin drum\.mp3:
> fd: 3 5
> Successfully prepared bad file.
> Note: Illegal Audio-MPEG-Header 0xfbc44418 at offset 102272.
> Note: Trying to resync...
> […]
> Note: Trying to resync...
> Note: Skipped 671 bytes in input.
> good file samples: 1412352
> bad file  samples: 1390464
>
> I get
>
> TEST: Output of ./basic_resync.bin drum\.mp3:
> fd: 3 4
> Successfully prepared bad file.
> Note: Illegal Audio-MPEG-Header 0x00000000 at offset 50432.
> Note: Trying to resync...
> Note: Skipped 2000 bytes in input.
> good file samples: 1434624
> bad file  samples: 1434624
>
> I suppose prepare_badfile() does something different on your system.
> Does OS/2 share the DOS thing about opening files in text or binary
> mode? I guess some O_BINARY might help.

Yes, this is the problem, needs O_BINARY, I'll look after.
For now I did
make LDFLAGS="-Zbin-files -Zomf"
where -Zbin-files does a hack to add O_BINARY most of the time and -Zomf 
converts GCC's aout object files to the native OMF and uses the native 
linker, the preferred method of building.

>
>> custom_io:                                                FAIL
>
> I suspect something similar here. I guess these tests would also be
> broken on Windows. And just perhaps these subtle portability issues are
> also to blame for the compliance failure.

After using the above make command, I now get,
chomp_strings:                                            PASS
less_bytes_after_seek2:                                   PASS
more_bytes_on_second_decode:                              PASS
2859531_id3_tag_not_skipped_when_NO_ID3V2_is_defined:     PASS
frame_seek_weirdness:                                     PASS
seek_accuracy:                                            PASS
out123_passthrough:                                       PASS
bug201_wrong_frame_buffer:                                PASS
premature_decoder_change:                                 PASS
bug201_another_one:                                       PASS
basic_resync:                                             PASS
freeformat:                                               PASS
out123_errorlist:                                         PASS
less_bytes_after_seek:                                    PASS
custom_io:                                                PASS
string_alloc:                                             PASS
2950218_extra_samples_seek_last_frame:                    PASS

PASS

>
> Regarding the README … yes … it could take a lot of updating. I am
> still not sure if I can advertise distribution of the compliance
> samples. I guess it's kindof public domain now, also not very creative
> work. I don't have a proper license for these files at hand. The
> regression tests are also not polished … they're at least there for
> occasional use (automatically with each nightly snapshot).
>
> I at least added a `make check` for the normal mpg123 build with some
> specific little tests. Being in part around 26 years old, the mpg123
> codebase doesn't tick all boxes for modern software engineering
> practices.

Yes, make check passes here.
Thanks,
Dave

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

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

Am Fri, 2 Apr 2021 08:46:20 -0800
schrieb Dave Yeo <dav...@gm...>: 

> OK, operator error. Rereading your directions, setting up the 
> environment so the DLLs can be loaded, it seems to run fine besides the 
> output having the wrong line endings for the console to display 
> correctly, worked around by piping the results to a file or less. 

Hm, no … the compliance test is wholly broken. I did not write it with
too much portability in mind (just a bit, though).

fl2.bit:	RMS=     nan (FAIL) maxdiff=0.000000e+00 (PASS)
fl3.bit:	RMS=     nan (FAIL) maxdiff=0.000000e+00 (PASS)
fl4.bit:	RMS=     nan (FAIL) maxdiff=0.000000e+00 (PASS)

The computations don't work at all. Also, the regression tests …
there's some basic breakage apparently with some of them.

> out123_passthrough:                                       FAIL

no idea

> basic_resync:                                             FAIL

You get:

TEST: Output of ./basic_resync.bin drum\.mp3:
fd: 3 5
Successfully prepared bad file.
Note: Illegal Audio-MPEG-Header 0xfbc44418 at offset 102272.
Note: Trying to resync...
[…]
Note: Trying to resync...
Note: Skipped 671 bytes in input.
good file samples: 1412352
bad file  samples: 1390464

I get

TEST: Output of ./basic_resync.bin drum\.mp3:
fd: 3 4
Successfully prepared bad file.
Note: Illegal Audio-MPEG-Header 0x00000000 at offset 50432.
Note: Trying to resync...
Note: Skipped 2000 bytes in input.
good file samples: 1434624
bad file  samples: 1434624

I suppose prepare_badfile() does something different on your system.
Does OS/2 share the DOS thing about opening files in text or binary
mode? I guess some O_BINARY might help.

> custom_io:                                                FAIL

I suspect something similar here. I guess these tests would also be
broken on Windows. And just perhaps these subtle portability issues are
also to blame for the compliance failure.

Regarding the README … yes … it could take a lot of updating. I am
still not sure if I can advertise distribution of the compliance
samples. I guess it's kindof public domain now, also not very creative
work. I don't have a proper license for these files at hand. The
regression tests are also not polished … they're at least there for
occasional use (automatically with each nightly snapshot).

I at least added a `make check` for the normal mpg123 build with some
specific little tests. Being in part around 26 years old, the mpg123
codebase doesn't tick all boxes for modern software engineering
practices.


Alrighty then,

Thomas

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

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

On 04/02/21 02:33 AM, Thomas Orgis wrote:
> Am Thu, 1 Apr 2021 21:17:18 -0800
> schrieb Dave Yeo <dav...@gm...>:
>
>> 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.
>
> Sorry, apparently lost track of that one. I applied it now. I also
> tried a x86 build again (without audio output, but basic multilib
> support is in the system … nice that mpg123 doesn't need any deps
> besides libc) and fixed a bit of const discarding in dct64_i386.

Thanks

>
>> 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
>
> Eh … that is the last line of the `make` to build the compliance test
> data. You're missing the actual output of the compliance perl script.
> So that one is totally broken on OS/2? Might be a portability project
> of its own.
>

OK, operator error. Rereading your directions, setting up the 
environment so the DLLs can be loaded, it seems to run fine besides the 
output having the wrong line endings for the console to display 
correctly, worked around by piping the results to a file or less. 
Results attached.
The readme could use updating, mentioning editing the BIN_SUFFIX line in 
the makefile and clearly stating how to run, perhaps including the 
regression directory, which gives this here,
chomp_strings:                                            PASS
less_bytes_after_seek2:                                   PASS
more_bytes_on_second_decode:                              PASS
2859531_id3_tag_not_skipped_when_NO_ID3V2_is_defined:     PASS
frame_seek_weirdness:                                     PASS
seek_accuracy:                                            PASS
out123_passthrough:                                       FAIL
bug201_wrong_frame_buffer:                                PASS
premature_decoder_change:                                 PASS
bug201_another_one:                                       PASS
basic_resync:                                             FAIL
freeformat:                                               PASS
out123_errorlist:                                         PASS
less_bytes_after_seek:                                    PASS
custom_io:                                                FAIL
string_alloc:                                             PASS
2950218_extra_samples_seek_last_frame:                    PASS

FAIL
make: *** [testscript] Error 1

Thanks,
Dave

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

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

Am Thu, 1 Apr 2021 21:17:18 -0800
schrieb Dave Yeo <dav...@gm...>: 

> 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.

Sorry, apparently lost track of that one. I applied it now. I also
tried a x86 build again (without audio output, but basic multilib
support is in the system … nice that mpg123 doesn't need any deps
besides libc) and fixed a bit of const discarding in dct64_i386.

> 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

Eh … that is the last line of the `make` to build the compliance test
data. You're missing the actual output of the compliance perl script.
So that one is totally broken on OS/2? Might be a portability project
of its own.


Alrighty then,

Thomas