mpg123-devel — Mailing list for mpg123 developers

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

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

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

> -1
> 
> I aleady have my mail filters set up... you wanna create me new work?

Heh, not specifically. Are you talking about only the merging of the
lists or also the idea of not modifying the subject anymore to be
compatible to the DKIM stuff? Are you using list-id for filtering?

Regarding the list count:  I just noticed that it's sometimes hard for
me to decide if a topic is only for developers or for users, and that I
have the feeling that there is significant overlap between the lists
anyway.

Maybe I am wrong. Could I get more opinions on this? Are there people
annoyed by getting the release announcements twice? Everyone chose
exactly one list?

> I'd leave it as it is, otherwise you get hassle either makig everybody
> unsubscribe and resubscribe to the new list, or pain moving the
> existing subscriptions to the new automatically. You want that?

If people are happy (to some democratic measure) with the current
situation and prefer it to a merged list, I can just remove the new
list again.

If nobody subscribes to it during  the coming days, that's also a sign.

The two lists are a bit of a nuisance to me and seem to me like
pretending that mpg123 is a big project with lots of discussion that
needs to be channeled (in fact, there's the stuff happening on IRC,
at least more frequent than mailing list posts). But if the status quo
is preferred, I'll keep it. No big deal.



Alrighty then,

Thomas

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

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

Am Sun, 10 May 2020 11:05:16 +0200
schrieb Thomas Orgis <tho...@or...>: 

> Btw, the new list is configured to not modify the messages, including
> the subject, to avoid breaking cryptographic signatures. If you rely on
> [mpg123-users] in the subject for sorting your mail, check out the
> List-id header field instead. Same for the other headers that contain
> the further list info and the unsubscribe link that used to be added to
> the mail body before.

Actually, my GPG signature is kept intact by the current lists. They
add the footer via another MIME part and the subject is not signed
anyway. I'm not sure what sf.net does with incoming DKIM that is
supposed to cover more of the mail data. And I am wondering right now
if appending to an existing mail via MIME is really supposed to not
prompt my mail client to utter a little warning about what is signed
and what not.

Is there someone actually preferring the message footer

_______________________________________________
mpg123-devel mailing list
mpg...@li...
https://lists.sourceforge.net/lists/listinfo/mpg123-devel

over the header fields with the same information?


Alrighty then,

Thomas

[mpg123-devel] New merged mailing list for mpg123 discussion

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

Hi mpg123 folks,

I think it is past time to realize that curating two mailing lists for
mpg123 does not make sense. I mostly send duplicate announcements to
both mpg123-devel and mpg123-users. Any discussion about a usage
problem can quickly evolve into a development discussion. People have
to wonder to which list a question should be posed.

And let's face it: The volume of mpg123 discussion is really low. There
is not that much to discuss. Of course that's good and bad, but I'll
take the explanation that it's a mature project with software that
works well for people who use it.

There are right now 22 addresses subscribed to mpg123-devel and 31 to
mpg123-users. I do not know how big the overlap is, as sf.net honours
your privacy and doesn't tell me the addresses. This is a moderate
crowd.

So, I hereby suggest that we all switch to the common mpg123-discuss
list by subscribing to it on

	https://sourceforge.net/projects/mpg123/lists/mpg123-discuss

and unsubscribing from mpg123-devel and mpg123-users.

If somebody has good arguments against this, please speak up. I'll stay
subscribed to all lists until it's clear that people are switching.
Vote with your feet: If I see people really moving, I can close
subscriptions to the old lists and just keep them for the archive.

Btw, the new list is configured to not modify the messages, including
the subject, to avoid breaking cryptographic signatures. If you rely on
[mpg123-users] in the subject for sorting your mail, check out the
List-id header field instead. Same for the other headers that contain
the further list info and the unsubscribe link that used to be added to
the mail body before.


Alrighty then,

Thomas

Re: [mpg123-devel] [mpg123-users] mpg123 1.26rc2 released

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

Am Fri, 8 May 2020 23:51:42 +0200
schrieb Thomas Orgis <tho...@or...>: 

> Get the release candidate from
> 
> 	http://mpg123.org/download/mpg123-1.26rc2.tar.bz2
> 	http://mpg123.org/download/mpg123-1.26rc2.tar.bz2.sig
> 
> and report your success to the devel list or mai...@mp..., or
> the bug tracker if you got something really serious.

We also got binaries for Windows folks up now, mainly for users of
libmpg123 as a DLL in their projects, but the whole program is there,
too.

	http://mpg123.org/download/win64/1.26rc2/
	http://mpg123.org/download/win32/1.26rc2/

Cygwin users are probably better off just building the thing like
on Unix systems. And then, that whole Ubuntu-on-Windows thing. What's
Windows, anyway? ;-)


Alrighty then,

Thomas

Re: [mpg123-devel] [mpg123-users] mpg123 1.26rc2 released

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

Am Sat, 9 May 2020 15:23:12 +0200
schrieb Thomas Orgis <tho...@or...>: 

> > Compiling with clang burps a few warnings

OK, please try the attached patch on 1.26rc2 or the current trunk. I
hope clang is happy with that.


Alrighty then,

Thomas

Re: [mpg123-devel] [mpg123-users] mpg123 1.26rc2 released

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

Am Sat, 9 May 2020 14:33:50 +0200
schrieb Martin Guy <mar...@gm...>: 

> mpg123: error while loading shared libraries: libmpg123.so.0: cannot
> open shared object file: No such file or directory

Ah! Now I get it. The installation runs `ldconfig -n /usr/local/lib` to
set up the symlinks, but this explicitly does not touch the global
linker cache. When you install to some non-standard location
(like /dev/shm/test), the build uses RPATH/RUNPATH in the binary to
locate its libraries. For a system directory, this is omitted, as the
build expects you to handle that via the default paths and the ld cache.

Checking `readelf -d /usr/local/bin/mpg123|grep PATH`, I see the same
on my system and yes, calling mpg123 fails, too, until ldconfig is run.
I think this is something normal and not special to the mpg123 build. I
never install mpg123 into /usr/local myself, so I was surprised by your
report.

> Compiling with clang burps a few warnings - maybe you could check that
> they are OK really (this, compiling on a 32-bit system. On a 64-bit
> one there are no warnings.)

Ah, I'll try to take care of those. 

> src/libsyn123/resample.c:1987:62: warning: result of comparison of
> constant 9223372036854775807 with expression of type 'size_t' (aka
> 'unsigned int') is always false
> [-Wtautological-constant-out-of-range-compare]
>         if(ins > syn123_resample_maxincount(inrate, outrate) || ins > INT64_MAX)
>                                                                 ~~~ ^ ~~~~~~~~~

Yeah, that is the point;-) I use the power of C99 to get int64_t and
just want to ensure that things always fit, not dealing with 32 or 64
bit platform differences. And now the compiler complains about me
playing safe;-) I'll try to wrap this into something along
sizeof(size_t) >= sizeof(int64_t) at compile time.

>         if(ins > UINT64_MAX) // Really?
>            ~~~ ^ ~~~~~~~~~~

Yeah, really … I'm putting checks vor _very_ unlikely errors in there;-)
Let's see how I disarm those without making things uglier.

> src/out123.c:864:6: warning: format specifies type 'unsigned long' but

OK, these are easy. I fixed them in trunk.


Alrighty then,

Thomas

Re: [mpg123-devel] [mpg123-users] mpg123 1.26rc2 released

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

Thanks for testing!

Am Sat, 9 May 2020 13:05:16 +0200
schrieb Martin Guy <mar...@gm...>: 

> mpg123: error while loading shared libraries: libsyn123.so.0: cannot
> open shared object file: No such file or directory
> then I ran "ldconfig" as root and it worked fine.

That's a bit peculiar. When I install a build into /dev/shm/test … I
get this bit:

libtool: install: /usr/bin/install -c src/libsyn123/.libs/libsyn123.so.0.1.0 /dev/shm/test/lib/libsyn123.so.0.1.0
libtool: install: (cd /dev/shm/test/lib && { ln -s -f libsyn123.so.0.1.0 libsyn123.so.0 || { rm -f libsyn123.so.0 && ln -s libsyn123.so.0.1.0 libsyn123.so.0; }; })
libtool: install: (cd /dev/shm/test/lib && { ln -s -f libsyn123.so.0.1.0 libsyn123.so || { rm -f libsyn123.so && ln -s libsyn123.so.0.1.0 libsyn123.so; }; })
libtool: install: /usr/bin/install -c src/libsyn123/.libs/libsyn123.lai /dev/shm/test/lib/libsyn123.la
libtool: finish: PATH="/media/thomas/handtasche/thomas/bin:/home/thomas/bin:/home/thomas/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/sbin" ldconfig -n /dev/shm/test/lib
----------------------------------------------------------------------

It installs libsyn123.so.0.1.0 and calls ldconfig on the directory,
also creating those symlinks mpg123 needs:

$ldd /dev/shm/test/bin/mpg123
	linux-vdso.so.1 (0x00007fffb017b000)
	libmpg123.so.0 => /dev/shm/test/lib/libmpg123.so.0 (0x00007efc2d3e8000)
	libout123.so.0 => /dev/shm/test/lib/libout123.so.0 (0x00007efc2d1d8000)
	libsyn123.so.0 => /dev/shm/test/lib/libsyn123.so.0 (0x00007efc2cf8c000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007efc2cbee000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efc2c7fd000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007efc2c5f9000)
	/lib64/ld-linux-x86-64.so.2 (0x00007efc2d874000)

I wonder if there's anything wrong if the install process … do you
actually miss the libsyn123.so.0 name (but have the others)
in /usr/local/lib (or the actual lib subdir if you have a multiarch
system) before running ldconfig yourself?


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.26rc2 released

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

Dear people not indifferent to happenings around the mpg123 project,

a proper new release of mpg123 near. Tonight, I release a second
release candidate (the first one was iterated over before it could go
public) for you all to chew on and spit back bugs that stick between
the teeth. I wish to turn this into the proper release of mpg123 1.26.0
at end of May.

Get the release candidate from

	http://mpg123.org/download/mpg123-1.26rc2.tar.bz2
	http://mpg123.org/download/mpg123-1.26rc2.tar.bz2.sig

and report your success to the devel list or mai...@mp..., or
the bug tracker if you got something really serious.

And this is it:

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. 

I don't intend such big releases becoming the norm. Actually, things really
should slow down for a decoder for a format that is old enough to have
all related patents expired. The existence of libsyn123 is justified by
the ability to re-use code written for the libout123 demonstrator
program, and by the wish to avoid people using the awful-sounding NtoM
decoder if they don't really, really want that. Meanwhile, libout123 was
justified by enabling code reuse from the main mpg123 application.

I hope I run out of justifications to add more libraries to the mpg123
umbrella. Well … there's that idea to get something combining
libsndfile and libmpg123 … or the former just adds MP3 support,
finally.


Alrighty then,

Thomas

Re: [mpg123-devel] Add CLR library to Windows prebuilt binaries.

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

Am Tue, 21 Jan 2020 15:29:24 +0100
schrieb Federico Di Marco <fe...@gm...>: 

> From the libmpg123 web site, I gathered that Patrick and JonY are
> responsible for creating the Windows binaries. How can I reach any of
> them to include in their windows binaries also the CLR library of
> mpg123 ?

Posting to this list is a good start;-) They're not always available to
reply immediately, though (life, business …). Have a bit of patience.
You can also generally try #mpg123 on freenode IRC.

Are you talking about the result of ports/MSVC++/2008clr? Right now,
we're distributing only what results under MinGW using
windows-builds.sh. There is no MSVC involved. Do you have trouble
building it yourself? I'd imagine so, as the port is rather dated now
and surely misses some updates.


Arighty then,

Thomas

[mpg123-devel] Add CLR library to Windows prebuilt binaries.

[Federico Di M. <fe...@gm...>]

Hi to everybody,

>From the libmpg123 web site, I gathered that Patrick and JonY are
responsible for creating the Windows binaries. How can I reach any of
them to include in their windows binaries also the CLR library of
mpg123 ?

Federico

Re: [mpg123-devel] Upcoming changes in dependency library logic in mpg123 build

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

Sorry for taking so long … the quest for the new mpg123 release is
endless … I integrated the patch for OS/2 now.


Alrighty then,

Thomas

Re: [mpg123-devel] Upcoming changes in dependency library logic in mpg123 build

[Reino W. <rwi...@xs...>]

On 2019-11-03T20:04:36+0100, Thomas Orgis <tho...@or...> wrote:

> Thanks for testing! About the trailing spaces … not sure if it is worth
> it to invest extra scripting to trim those. Do they have any effect?

Don't bother. I just thought I'd mention it.
Afaik they don't do any harm.

-- Reino

Re: [mpg123-devel] Upcoming changes in dependency library logic in mpg123 build

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

Am Sun, 3 Nov 2019 19:25:01 +0100
schrieb Reino Wijnsma <rwi...@xs...>: 

> I compiled libopenmpt with this latest mpg123 snapshot and finally FFmpeg.
> I haven't encountered any errors and the FFmpeg binary works perfectly.
> Thanks.

Thanks for testing! About the trailing spaces … not sure if it is worth
it to invest extra scripting to trim those. Do they have any effect?


Alrighty then,

Thomas

Re: [mpg123-devel] Upcoming changes in dependency library logic in mpg123 build

[Reino W. <rwi...@xs...>]

On 2019-11-01T09:22:33+0100, Thomas Orgis <tho...@or...> wrote:
> a long time ago it was reported that linking to libmpg123 on Windows
> using the provided libmpg123.pc file is troublesome because libs
> libmpg123 depends upon were not recorded there.
That was this message: https://sourceforge.net/p/mpg123/mailman/message/36243120/.

> So I reorganized the linking in the mpg123 build files and introduced
> Libs.private lines in the .pc files.
> [...]
> I only tested on Linux, so someone confirming that things work properly
> on Windows would be nice, especially checking if -lshlwapi appears in
> Libs.private for libmpg123. The current snapshot contains the changes
> already.
'libmpg123.pc':
Libs.private: -lm -lshlwapi
                           ^1 trailing space

'libout123.pc':
Libs.private: -lm -lshlwapi 
                           ^^2 trailing spaces

'libsyn123.pc':
Libs.private: -lm

I compiled libopenmpt with this latest mpg123 snapshot and finally FFmpeg.
I haven't encountered any errors and the FFmpeg binary works perfectly.
Thanks.

-- Reino

Re: [mpg123-devel] Upcoming changes in dependency library logic in mpg123 build

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

On 11/03/19 03:36 AM, Thomas Orgis wrote:
> Am Fri, 1 Nov 2019 20:29:36 -0700
> schrieb Dave Yeo <dav...@gm...>:
>
>> Using this configure line, (all one line)
>> --enable-modules=no --with-default-audio=os2 --enable-ipv6=no
>> --with-cpu=x86 --with-cpu=sse  --prefix=h:/tmp/mpg123 LIBS=-lcx
>> "LDFLAGS=-Zomf -Zhigh-mem -Zbin-files -Zmap" "CPPFLAGS=-idirafter
>> k:/usr/include/os2tk45" CFLAGS=-std=c99
>>
>> and the attached patch, and running autoreconf -sfi, the build succeeded
>
> Any particular reason for not stuffing some of this into defaults in
> configure.ac? Btw., --with-cpu=x86 and --with-cpu=sse don't go together.
> Do both work individually?

Some of it could be stuffed into configure.ac.
What is the recommended cpu flags for x86? Likely from Pentium II to the 
latest Ryzen.
I'll test them individually this evening.

>
> Should there simply be a check for -lcx on os/2 … some logic to decide for
> -Zomf and friends? Or can we just hardcode the lot on platform
> detection as there is no other currently active OS/2-like config that
> needs different flags?

Should be a test for -lcx, -Zomf is required for using -lmpmm, the 
others are optional. I'll see about what can be put in configure.ac. The 
  need to search the toolkits (OS/2 SDK) headers for os2me.h after the 
GCC ones to avoid picking up the wrong headers may be the most difficult.
>
>> and produced a working mpg123.exe, mpg1230.dll, along with untested
>
> 1230.dll does look a bit funny. I guess that's the way …

It's an attempt by libtool to version the DLL and since we're limited to 
8.3 DLL names...
Dave

Re: [mpg123-devel] Question for output module jack, connect to specific ports

[Thomas B. <to...@tr...>]

On 2019-11-03 08:50, Thomas Orgis wrote:
> Am Sun, 03 Nov 2019 05:35:04 +0100
> schrieb Thomas Brand <to...@tr...>:
> 
>> Looking at libout123/modules/jack.c it hints at that this is possible
>> ("wishlist"). However I have had no luck in setting ports so far and
>> didn't find more information in the man page.
> 
> Indeed, that's only documented in the source. You need to look at
> connect_jack_ports(). It is using the device name as comma-separated
> port list.
> 
>> I've tried -o jack, myclient:port1, myclient:port2 and several
>> variations with and without ", nothing worked so far.
> 
> -o jack -a myclient:port1,myclient:port2
> 
> That should be it. It would be sensible if --list-modules or something
> gave you a hint about the special forms the output device name can
> take. So far we have only
> 
>  -a <d> --audiodevice <d>  select audio device (depending on chosen 
> module)
> 
> as long help. The ‘depending on module’ part is the hint …
> 

Thanks for the help, this works flawlessly.

A short addition in man1/mpg123.1 and man1/out123.1 would be good, 
something along

-o
...
Also see option -a.

-a
...
For output module 'jack', a comma separated list of ports (usually two) 
can be provided in place of the audio device list.
Example: mpg123 -o jack, -a <aclient:port_L>,<aclient_port_R> ...

I suggest it helps to discover this useful feature better for JACK 
users.

Thanks again + best regards
Thomas

Re: [mpg123-devel] Upcoming changes in dependency library logic in mpg123 build

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

Am Fri, 1 Nov 2019 20:29:36 -0700
schrieb Dave Yeo <dav...@gm...>: 

> Using this configure line, (all one line)
> --enable-modules=no --with-default-audio=os2 --enable-ipv6=no 
> --with-cpu=x86 --with-cpu=sse  --prefix=h:/tmp/mpg123 LIBS=-lcx 
> "LDFLAGS=-Zomf -Zhigh-mem -Zbin-files -Zmap" "CPPFLAGS=-idirafter 
> k:/usr/include/os2tk45" CFLAGS=-std=c99
> 
> and the attached patch, and running autoreconf -sfi, the build succeeded 

Any particular reason for not stuffing some of this into defaults in
configure.ac? Btw., --with-cpu=x86 and --with-cpu=sse don't go together.
Do both work individually?

Should there simply be a check for -lcx on os/2 … some logic to decide for
-Zomf and friends? Or can we just hardcode the lot on platform
detection as there is no other currently active OS/2-like config that
needs different flags?

> and produced a working mpg123.exe, mpg1230.dll, along with untested 

1230.dll does look a bit funny. I guess that's the way …


Alrighty then,

Thomas

Re: [mpg123-devel] Question for output module jack, connect to specific ports

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

Am Sun, 03 Nov 2019 05:35:04 +0100
schrieb Thomas Brand <to...@tr...>: 

> Looking at libout123/modules/jack.c it hints at that this is possible 
> ("wishlist"). However I have had no luck in setting ports so far and 
> didn't find more information in the man page.

Indeed, that's only documented in the source. You need to look at
connect_jack_ports(). It is using the device name as comma-separated
port list.

> I've tried -o jack, myclient:port1, myclient:port2 and several 
> variations with and without ", nothing worked so far.

-o jack -a myclient:port1,myclient:port2

That should be it. It would be sensible if --list-modules or something
gave you a hint about the special forms the output device name can
take. So far we have only

 -a <d> --audiodevice <d>  select audio device (depending on chosen module)

as long help. The ‘depending on module’ part is the hint …


Alrighty then,

Thomas

[mpg123-devel] Question for output module jack, connect to specific ports

[Thomas B. <to...@tr...>]

Hi,

when using '-o jack' as output module with mpg123, I think to remember 
that there was a way to define the ports to connect to.

Looking at libout123/modules/jack.c it hints at that this is possible 
("wishlist"). However I have had no luck in setting ports so far and 
didn't find more information in the man page.

I've tried -o jack, myclient:port1, myclient:port2 and several 
variations with and without ", nothing worked so far.

How would I define the port names?

Greetings
Thomas

Re: [mpg123-devel] Upcoming changes in dependency library logic in mpg123 build

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

On 11/01/19 01:22 AM, Thomas Orgis wrote:
> I only tested on Linux, so someone confirming that things work properly
> on Windows would be nice, especially checking if -lshlwapi appears in
> Libs.private for libmpg123. The current snapshot contains the changes
> already. Wouldn't be bad if there'd be a sign of life from our fringe
> platforms, too (OS/2?).

Using this configure line, (all one line)
--enable-modules=no --with-default-audio=os2 --enable-ipv6=no 
--with-cpu=x86 --with-cpu=sse  --prefix=h:/tmp/mpg123 LIBS=-lcx 
"LDFLAGS=-Zomf -Zhigh-mem -Zbin-files -Zmap" "CPPFLAGS=-idirafter 
k:/usr/include/os2tk45" CFLAGS=-std=c99

and the attached patch, and running autoreconf -sfi, the build succeeded 
and produced a working mpg123.exe, mpg1230.dll, along with untested 
mpg123-id3dump.exe mpg123-strip.exe out123.exe out1230.dll syn1230.dll.
For the first time in ages, using the os2 module sounds really good.
The only lib in Libs.private is -lm. libm is an empty lib here only kept 
for compatibility.
This is tested on the latest ArcaOS, an OEM version of OS/2 in active 
development (arcanoae.com)
To do, add o_binary in a few places as -Zbin-files can be flakey in 
forcing binary mode. Likely other assembly files where as will puke on 
the .section directive.
Note that libc (EMX) got replaced years back with a mostly compatible 
one (kLIBC) and the old multimedia package doesn't really work so 
directly using the OS/2 toolkit for the multimedia support.
Libcx is some libc extensions, I needed to add it to configure.ac to 
prevent some missing mmap symbols.
Thanks
Dave

[mpg123-devel] Upcoming changes in dependency library logic in mpg123 build

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

Hi folks,

a long time ago it was reported that linking to libmpg123 on Windows
using the provided libmpg123.pc file is troublesome because libs
libmpg123 depends upon were not recorded there.

Also, I noticed that we link libmpg123 with -ldl, which is not
necessary and thus bad practice.

So I reorganized the linking in the mpg123 build files and introduced
Libs.private lines in the .pc files. This is not perfect, but I put the
focus on

a) preventing unnecessary library dependencies for libs we build,
b) ensuring that all necessary libs are mentioned in Libs.private.

I only tested on Linux, so someone confirming that things work properly
on Windows would be nice, especially checking if -lshlwapi appears in
Libs.private for libmpg123. The current snapshot contains the changes
already. Wouldn't be bad if there'd be a sign of life from our fringe
platforms, too (OS/2?).


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.25.13 released

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

Hi,

there is another bugfix release. I really want to get the proper new
release out with lots of other fixes/improvements you (if anyone;-) are
waiting for. But this one here is a proper crash that just has to get
fixed also in distros.

1.25.13
-------

This is a bugfix release solely for bug 280 in the parser:

- libmpg123
-- Reset the flag for having a frame to decode before trying to
   parse a new one. This prevents very unkind behaviour (crashes)
   when combinging mpg123_scan() with decoding later on for damaged
   streams that have a mixture of different MPEG versions.

Stay tuned for 1.26.0 …


Alrighty then,

Thomas

[mpg123-devel] Any suggestions about upcoming libsyn123 as part of mpg123 1.26, especially the resampler?

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

Hi mpg123 folks,

while there will be another bugfix release of 1.25.x soon, I am working
hard to create a release candidate for 1.26. It adds a number of
things, among those another library to accompany libmpg123 and
libout123, being created out of out123's recently aquired feature to
generate some test signals (see out123 --longhelp | grep wave).

This library is called libsyn123 and collects some trivial and
not-too-trivial code for generating signals and conversion between audio
formats. It can generate signals (multiplied oscillators, noise, a
Geiger Counter simulator for fun), convert encodings and mix channels …
and one could have stopped there. Some simple loops and macros for the
messy handling of differing encodings. After all, I do _not_ intend to
take on libsox or ffmpeg. Any extreme overlap in functionality is
accidental. My aim is to have some functionality available for mpg123
and out123 in re-usable manner, as a collection of functions that do
not impose much on the way you write your client application. Also I
want everything audio-related you need to build an MPEG audio player
shipped with the mpg123 package. You add your UI and network code, with
all those other dependencies.

I have to admit that some motivation to pack code into libsyn123 comes
from another project of mine that uses libmpg123 and has its own
version of that nearly-trivial conversion and mixing code. I intend to
merge that, dropping code from the other project while enriching what
out123 can do to bring your raw audio from any format to your output
device in any other format. Adding an external dependency for that is
no option.

Also, usage of libsyn123 might enable us to drop bloated functionality
from libmpg123 that does not really cover MPEG decoding in some
uncertain future, while keeping the mpg123 application intact.

A simple example is the dithering. If you want high quality output, you
should get 32 or 24 bit data from libmpg123 and possibly apply dithering
afterwards. This feature should be dropped from libmpg123
(generic_dither and i586_dither decoders) and mpg123 should use
libsyn123's dithering instead, which is based on what libmpg123 has.

One feature that is causing quite some hurt is the NtoM resampler in
libmpg123. Unsuspecting people should not use that. It's an ugly hack
without any filtering. That it is being used is a testament to how
little audio theory matters to most people in practice;-)

There is a resampler now in libsyn123 that is used by out123 when
--rate and --inputrate parameters differ or a --speed is given.
Besides the desire to avoid any external dependency, the rationale for
yet another resampler is a different approach I wanted to take.

I want to have things simple for the user, and predictable. Usual
resamplers have a lot if internal magic that involves some buffering
(to fill filter windows, for FFT), decoupling the user from the
relation between input sample count and output sample count at the
instant of feeding a buffer. I wanted to see what one can do to improve
on the simple interpolation approach while still avoiding opaque
latency from internal buffering.

Let me quote myself from the syn123 header:

/** Set up the resampler.
 *
 *  This works independent of the signal generators. You can combine
 *  syn123_setup_resample() with syn123_setup_geiger(), for example.
 *
 *  People can get worked up a lot about differing algorithms for resampling,
 *  while many folks can actually bear the simple drop/repeat method and most
 *  probably do not bother about the distortions from linear resampling.
 *  A testament to this is that in the 18 years of me maintaining mpg123, I
 *  got bugged about the missing dithering and on subtle bias in shuffling
 *  a playlist, but people seem to insist on using the NtoM resampoler inside
 *  libmpg123, despite me warning about its horrible consequences for audio
 *  quality. It is a plain drop-sample implementation. The only good things to
 *  say about it is that it is cheap and is embedded with the sample-accurate
 *  decoder so that you do not have to worry about offsets in terms of input
 *  and output samples.
 *
 *  Anyhow, this is my take on a reasonably good and efficient resampler that is
 *  neither the best-sounding, nor the fastest in terms of CPU time, but gets
 *  by without significant latency. It needs far less computation than usual
 *  high-quality windowed-sinc resampling (libsamplerate), but cannot beat
 *  libsoxr with its FFT-based approach. The less stringent dirty mode (using
 *  only a 72 dB lowpass filter, in practice still close to CD-DA quality)
 *  comes quite close, though.
 *
 *  The selling point is that it produces output samples as soon as you start
 *  feeding, without any buffering of future samples to fill a window for the
 *  FIR filter or the Fourier transform. It employs IIR filters for low-passing,
 *  possibly in multiple stages for decimation, and optimized interpolation
 *  formulas using up to 6 points. These formulas, based on research by
 *  Olli Niemitalo using using Differential Evolution, are what enables a
 *  dynamic range of 108 dB, well above 16 bit CD-DA quality. Simple
 *  cubic splines after low-passing distort up to around -40 dB in my tests.
 *
 *  There is some effective signal delay well below 10 samples. The impulse
 *  response is about 3 samples late, so this is well inside the realm of
 *  (nonlinear) phase shift. The phase distortion looks bad on paper but does
 *  not matter much in the intended domain of application: the final change in
 *  sampling rate before playback on audio hardware, the last filter that is
 *  applied before the sound hits the speakers (or all the other filters
 *  implemented in your audio harware, that you can choose to be ignorant
 *  about). Use better resamplers for mixing in the studio. Use better
 *  resamplers for converting files on disk. For live playback, consider this
 *  one because it is good enough, fast enough, cheap enough.
 *
 *  Note that if you call this function repeatedly, the internal history
 *  is only cleared if you change anything besides the sampling rates. If
 *  only the rates change, the state of the resampler is kept to enable
 *  you to continue on prior data. This means you can vary the resampling
 *  ratio during operation, somewhat smoothly depending on your buffer size.
 *
 *  Also note that even on identical input and output rates, the resampler
 *  will apply the full filtering as for any ratio close to that, including
 *  oversampling. No special shortcuts.
 *
 *  A returned error guarantees that the internal resampler setup has
 *  been cleared (frees a little bit of memory). You can provide zero
 *  inrate, outrate, and channel count at the same time to that effect
 *  without an error message being produced (but still SYN123_BAD_FMT
 *  being returned).
 *
 *  \param sh mandatory handle
 *  \param inrate input sample rate (nominator of ratio)
 *  \param outrate output sample rate (denominator of ratio)
 *  \param channels number of interleaved channels
 *  \param dirty Enable (!= 0) the dirty mode for even more 'good enough'
 *  resampling with less computing time. Offers -72 dB low pass attentuation,
 *  worst-case distortion around that, too, and 85% worst-case bandwidth.
 *  With this set to zero, the normal mode is used, offering at least 108 dB
 *  dynamic range and worst-case bandwidth above 84%.
 *  \param smooth Enable (!=0) extra code smoothing the resampler response to
 *  on-the-fly changes of sampling rate ratio. This involves keeping
 *  some per-stage history to bootstrap additional decimation filters and the
 *  changed final lowpass/interpolation.
 *  \return success code
 */

I envision a future where libmpg123's internal resampling is replaced
by libsyn123 functionality. But maybe, since I spent quite some thought
on resampling algrithms now, I'll rather work out a way to properly
resample inside the decoder while we got data in Fourier space anyway.
The minimal latency property does not really help when we work with
overlapping windows in MPEG frames to begin with. This would be a
killer feature for playing 44100 Hz files in today's world of 48000 Hz
playback devices.

Anyhow, please have a look at the specification of the libsyn123 API at 

	http://www.mpg123.org/api/group__syn123__api.shtml

An overview of the functions, the names hopefully indicating scope:

struct syn123_struct;
const char* syn123_strerror
syn123_handle* syn123_new
void syn123_del
int syn123_dither
size_t syn123_read
int syn123_setup_waves
int syn123_query_waves
const char* syn123_wave_name
int syn123_wave_id
int syn123_setup_sweep
int syn123_setup_pink
int syn123_setup_white
int syn123_setup_geiger
int syn123_setup_silence
int syn123_conv
double syn123_db2lin
double syn123_lin2db
int syn123_amp
size_t syn123_clip
size_t syn123_soft_clip
void syn123_interleave
void syn123_deinterleave
void syn123_mono2many
int syn123_mixenc
int syn123_mix
int syn123_setup_filter
int syn123_query_filter
void syn123_drop_filter
int syn123_filter
int syn123_setup_resample
long syn123_resample_maxrate
size_t syn123_resample_count
size_t syn123_resample_history
size_t syn123_resample_incount
size_t syn123_resample_maxincount
ssize_t syn123_resample_expect
ssize_t syn123_resample_inexpect
off_t syn123_resample_total
off_t syn123_resample_intotal
size_t syn123_resample
void syn123_swap_bytes
void syn123_host2le
void syn123_host2be
void syn123_le2host
void syn123_be2host

I invite everyone to give comments on API design, to test things …
suggest improvements. Also, the added parameters to out123 could
perhaps benefit from some more consistent naming scheme.

Well, I'll leave you now with my impression of a cricket chirping,
followed by the last survivors in the nuclear wasteland looking for
hope …

src/out123-with-modules --inputrate 44100 --rate 48000 \
  --wave-freq 9394,27,3 --wave-pat sine,pulse,pulse \
  --preamp -6 --seconds 3

src/out123-with-modules --source geiger --preamp -12 --genbuffer 0


Alrighty then,

Thomas

PS: Can someone give me hints on reasonable pulseaudio configuration
that not dwarfs anything I do with mpg123 or out123 in CPU time for
whatever computations pulseaudio has to do? I used to fret about the
default resampling mode of the ALSA dmix plugin using more CPU time
than mpg123 decoding MPEG audio. Things did not get that much with
pulse. Sure, machines are fast nowadays … but it seems a bit futile
optimizing audio code when cycles are wasted down the chain anyway.
Pulse is around 9% CPU time for me regardless of out123 producing 48000
Hz or some other rate (itself using around 1.5% or 3% depening on
resampling or not, CPU at 800 MHz).

Re: [mpg123-devel] Porting to WIndows/ARM64

[Kevin J. <inv...@ya...>]

 Hi Jon,
Thanks for the rapid response.
> You can probably start by configuring mpg123 to use the non-asm generic
> decoder. The win32 part should be the same on ARM.

   
   - 
That is where I'm starting (i.e. non-asm decoder). I think that the auto-vectorization optimization in Visual C/C++ may do a decent job of generating NEON code for ARM64.
> Unfortunately, I don't have an ARM system to test it out on.   
   -    

I do have an ARM64 test device available.


Best regards,
Kevin Jones
    On Tuesday, September 10, 2019, 03:44:33 a.m. PDT, JonY <10...@gm...> wrote:  
 
 On 9/9/19 9:20 PM, Kevin Jones via mpg123-devel wrote:
> Hi All,
> I am currently porting libmpg123 to Windows/ARM64. From the libmpg123 web site, I gathered that Patrick and JonY are responsible for creating the Windows binaries. How can I reach either of them to include the modifications to create the Windows/ARM64 binary?
> 
> Best regards,
> Kevin Jones
> 
> 

You can probably start by configuring mpg123 to use the non-asm generic
decoder. The win32 part should be the same on ARM.

Unfortunately, I don't have an ARM system to test it out on.
_______________________________________________
mpg123-devel mailing list
mpg...@li...
https://lists.sourceforge.net/lists/listinfo/mpg123-devel
  

Re: [mpg123-devel] Porting to WIndows/ARM64

[JonY <10...@gm...>]

On 9/9/19 9:20 PM, Kevin Jones via mpg123-devel wrote:
> Hi All,
> I am currently porting libmpg123 to Windows/ARM64. From the libmpg123 web site, I gathered that Patrick and JonY are responsible for creating the Windows binaries. How can I reach either of them to include the modifications to create the Windows/ARM64 binary?
> 
> Best regards,
> Kevin Jones
> 
> 

You can probably start by configuring mpg123 to use the non-asm generic
decoder. The win32 part should be the same on ARM.

Unfortunately, I don't have an ARM system to test it out on.