[mpg123-users] Please test new network code in/out of mpg123 (now with HTTPS support)!

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

Hi mpg123 afficionados,

we finally managed to get mpg123 to support https:// as well as http://
streams by boldly preparing to remove any networking code inside mpg123
itself. We intend to just keep the ICY header communication to get the
metadata interval from Shoutcast servers.

On unixy platforms where fork+exec is available, that means starting
instances of wget or curl (whichever is available at runtime or chosen
via mpg123 --network <backend>) to do the actual network stuff. I like
to keep actual use of those libraries, especially the TLS parts, out of
my binaries if there is no good reason to do it otherwise.

The implicit pipe buffer in that is a bonus — the kernel gives us some
input buffering for network streams, something which mpg123 lacked
before. There is still no fancy work trying to adjust for audio clock
skew (do other simple clients do that?) … so it basically should work
like before, just without us having to maintain a custom implementation
of IPv4, IPv6 host lookup and HTTP protocol handling.

On Windows, you got currently two bindings to choose from at build
time: wininet and winhttp. If your testing does not show any advantage
of winhttp, that one might go, as both are universally available on
that platform.

Since this is quite a dramatic change and involved some rearrangement
of I/O code paths, I call everyone to test things. On Unix/Linux,
please grab the current

	https://mpg123.org/snapshot

and build it with

./configure --with-network=internal

for the old code, and

./configure --with-network=exec

for the new code that executes wget or curl. You can enforce one of
them at runtime with mpg123 --network <wget/curl>. The idea is that
plain HTTP streams and playlists should still work like before, plus
now also the option of HTTPS streams. Especially long-time radio use
should be tested … whoever knows what might lurk, if some different
command line options should be passed on.


On Windows, JonY was so kind to provide a set of binaries for each
network option:

- 64 bit: http://mpg123.org/download/win64/20220509022201/
- 32 bit: http://mpg123.org/download/win32/20220509022201/

Each comes in the flavours internal (the old code), winhttp, and
wininet. Does the new stuff work fine? Is there any difference between
the two system library options?

Please do tell us! After some feedback, this is intended to ship as
1.30.0. We'll switch the default build to the external networking, but
likely will keep the old code there to resort to. In 1.31.0, it shall
be removed completely, ending an era of ad-hoc HTTP talking and custom
host communication code in a program that was just supposed to
demonstrate an audio decompressor.


Alrighty then,

Thomas

PS: There's also a number of other notable changes … like you now being
able to pipe from stdin and still use the terminal. Testing that is
also appreciated, see the NEWS file in the distribution.