mpg123-users — Mailing list for users of mpg123

[mpg123-users] releasing mpg123 1.31.2 (just build fixes)

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

Dear people who eye mpg123,

there is not much to see here, but what there is, is this:

1.31.2
------
- Fix build --with-network=internal only (configure logic error, bug 348).
- Fix OS/2 build with getaddrinfo() (which may support IPv6 eventually, thanks
  to Dave Yeo).

Mpg123 1.31.2 can be fetched from the usual places … but if your build
worked, you do not have much reason to replace it.


Alrighty then,

Thomas

[mpg123-users] mpg123 1.31.1 released (build fix for Illumos)

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

Dear people who take an interest in mpg123,

there is a quick build fix release out now:

1.31.1
------
- Fix largefile aliases for the case of a largefile-insensitive build
  that still does define _FILE_OFFSET_BITS from the outside
  (sys/feature_tests.h on Illumos).

So unless you got a build failure on your setup with 1.30.0, you can
sit that one out.


Alrighty then,

Thomas

[mpg123-users] mpg123 1.31.0 released

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

Dear mpg123-inflicted,

I hereby announce version 1.31.0, which was supposed to be a little
bug-fix release before pondering deeper (actually rather shallow)
API/ABI business, but still brings quite a list of changes:

1.31.0
------

- mpg123:
-- Finally make terminal control work on Windows, for real. Building it
   was broken in 1.30.x.
-- The --control / -C switch will make mpg123 abort now if terminal
   control cannot be enabled.
-- Revert to internal network code for plain HTTP to ensure continued
   support for original shoutcast servers that do not talk proper HTTP.
   External backends are built at the same time and can be enforced using
   --network <backend>.
-- Try-witout-port for internal network code is gone. We do not need to
   keep each ancient hack for specific hosts.
-- Handle redirections independently of the backend behind net123. 
-- Set proxy environment variables when --proxy is specified, for net123
   backends to use.
-- Continue reading for long commands in generic control, avoiding
   unnecessary unfinished command errors.
-- Change error message from 'unknown command' to
   'unknown command with arguments' to avoid confusion why 'help foo'
   is unknown, as opposed to 'help'.
-- Reduce CPU load while just waiting for terminal input
   (thanks to bolshoytoster on github).
-- Condense terminal control help output and excessive vertical whitespace
   in printouts (inspired by Volkmar Klatt).
-- Fix interaction of pause (looping) with buffer, adding --pauseloop
   to set the loop interval.
-- Numeric option arguments are strictly checked now for conversion errors.
   This also catches -devbuffer, which was interpretd as -d 0 before. This
   also applies to out123.
- libout123:
-- Add same interruption handling to out123_write() as to
   unintr_write(), adding EAGAIN to fix bug 342 (thanks to Steffen Nurpmeso)
   for certain ALSA setups.
-- Add --devbuffer support to win32 output and change default to 0.25 seconds.
-- Fix race condition to deadlock on buffer_sync_param() where parameters after
   the command byte got read as more commands. This got triggered easily by
   using the pause key in terminal mode with buffer (which was discouraged
   before because of buffer flushing). Generally, changing parameters with
   active buffer process was dangerous since libout123 entered the scene.
- some build fixes for compiler pickyness
- Disable largefile renames also for non-sensitive POSIX systems
  (in some distant future, the alias symbols could go away, then …
  bug 330).
- Fix Android NDK x86 builds with GLOBAL_VAR_PTR use in assembly (bug 345).

The updated Windows binaries come from a refreshed toolchain and at
least the x86 build has been verified to work on Windows XP with an
Atom CPU in a little netbook from times long gone.

Get it from the usual places indicated on

	http://mpg123.org/download.shtml

and enjoy!


Alrighty then,

Thomas

[mpg123-users] mpg123 1.30.2 released (just a build fix)

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

Hi,

a little maintenance release of mpg123 is out:

1.30.2
------
- Only use EWOULDBLOCK if the macro is defined (FreeBSD misses it for
   _POSIX_SOURCE, bug 339).


No functional changes.


Alrighty then,

Thomas

[mpg123-users] mpg123 1.30.1 released

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

Dear people of mpg123,

here comes another little release with some fixups from the last major
one:

1.30.1
------
- mpg123:
-- Show stderr of network helpers in -vvv mode.
-- Use curl --http0.9, if available, to support shoutcast v1 streams
   without wget (wget not needing such switch, yet).
-- Support file:// URLs for local access as was intended with the last
   release.
-- Give more helpful error message if neither wget nor curl are usable, also
   allow error messages from curl to appear when not --quiet.
-- Update the man page.


Alrighty then,

Thomas

[mpg123-users] mpg123 1.30.0 released

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

Dear all,

finally, the next version of mpg123 is out, with quite a number of
changes on the frontend side. Notable is the enhanced experience for
users of those legacy systems like OS/2 … and Windows;-)

This release finally makes the mpg123 console application support HTTPS
streaming, by ditching the old internal network implementation in
favour of just calling wget or curl (both tried) to do the messy
networking things on forking platforms, and even two possible native
APIs on Windows (winhttp by default, build-time choice).

The second notable addition is terminal control for both Windows and
OS/2. Yes.

1.30.0
------
- build:
-- Use dummy as default module when no other outputs are enabled. This also
   fixes a non-module build with just the dummy (bug 333).
-- Use CMAKE_CURRENT_SOURCE_DIR in CMake build to help nested use (bug 335).
-- some updates for OS/2 support (fixing up stdin playing, for example)
- mpg123:
-- new network backend using external tools/libraries to also support HTTPS
-- old network backend changed to use h_addr_list[0] instead of h_addr
-- terminal control keys now case-sensitive (fixing smal/big pitch controls)
-- additional terminal control keys for simple equalizer control (A/a for bass,
   J/j for mids, N/n for treble, e for reset, E for printout)
-- terminal volume control now in decibel steps and bounded to +/- 60 dB
-- terminal control now also with audio from stdin (bug 338) via
   /dev/tty or ctermid()
-- terminal control also available for OS/2 and Windows platforms
-- re-print tag info on decrease of terminal width for a bit less mess
-- always print an empty line after tag info for cleaner appearance
-- print lyrics also to stderr
-- remote control API v10 with "@P 3" as additonal message on track end
-- also added PROGRESS command as opposite of SILENCE
-- fix some verbosity, tweak help for --icy-interval
-- added --auth-file
-- also obscure argument to --auth for others
-- Cygwin/MinGW: Provide _win32_utf8_wide and _win32_wide_utf8 unconditionally.
   It is needed by the WASAPI plugins, the underlying conversion functions
   should be present since Windows 2000. Fixes WASAPI support on Cygwin.
   Also needed for new network code.
- libout123:
-- pulse: initialize more error codes to avoid bogus error messages
-- os2: considerable fixup for proper writes of full buffers avoiding
   nasty effects from the ... special audio system, more cleanup still
   nice-to-have, but still lacking

See http://mpg123.org/download.shtml to get your fix.


Alrighty then,

Thomas

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

Re: [mpg123-users] mpg123 playlist with spaces not working

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

Am Sun, 20 Feb 2022 14:05:12 -0600
schrieb Will Stites <wil...@uw...>: 

> I´m trying to make a playlist for mpg123 from a directory containing 
> subdirectories. Many of the subdirs and filenames contain spaces. This 
> is using a Raspberry Pi with Raspbian Bullseye, mpg123 1.26.4.
> 
> I made a playlist where each line is an absolute path enclosed in 
> ¨double quotes¨.

Stop right here. Why adding quotes? If you do

$ ls dir/*.mp3 > list.m3u
$ mpg123 -@ list.m3u

it should just work. It reads a full line, including your spaces. There
is no quoting. If you got file names with line ends in them (entirely
possible), you're out of luck. But you really should avoid those, anyway;-)

Adding a #M3U as first line is a nice touch, but a bare list of file
names should work. Oh … maybe you should not name your first file
„#M3U“.


Alrighty then,

Thomas

[mpg123-users] mpg123 playlist with spaces not working

[Will S. <wil...@uw...>]

I´m trying to make a playlist for mpg123 from a directory containing 
subdirectories. Many of the subdirs and filenames contain spaces. This 
is using a Raspberry Pi with Raspbian Bullseye, mpg123 1.26.4.

I made a playlist where each line is an absolute path enclosed in 
¨double quotes¨.  mpg123 seems to stop reading the line at the 1st 
space, and it tells me the file (not really the file, the truncated 
string) doesn't exist. Whereas, mpg123 does just fine with a single 
filespec like this: mpg123 "home/me/path to file/a music file.mp3"  (The 
lines in the playlist were like that.)

I tried escaping all the spaces with backslashes, eg /home/me/path\ to\ 
file/a\ music\ file.mp3. mpg123 tells me it can play the file, and it 
shows me the string it can't play, except all the backslashes have been 
changed to forward slashes, ie /home/me/path/ to/ file/a/ music/ 
file.mp3. I´m not much of a bash expert, but in my thrashing around, I 
got the idea of escaping the spaces with TWO backslashes. mpg123 
replaced each \\  with //.

It does fine with cat /home/me/path\ to\ file/a\ music\ file.mp3 | 
mpg123 -   Not surprising.

I tried putting #M3U as the 1st line of the playlist. That was 
interesting. It skipped over the 1st file with an error message. The 
directory name had 2 spaces and the filename had 1 space. It played the 
2nd file - in that case, the path had no spaces until the filename, 
which contained 1 space.

I can probably figure out how to write a bash script to change all the 
directory and file names to remove the spaces But it seems like there 
must be a way to pass paths full of spaces to mpg123.

[mpg123-users] Any remote control interface users with an opinion on @P 3?

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

Hi,

it has been requested that the remote control interface of mpg123
(mpg123 -R, doc/README.remote) adds a response code "@P 3" on the
natural end of the track, in addition to the generic "@P 0" code.

The current snapshots do that, to appear in the next feature release.

I am trying to be careful here: Is there any client application that
can be upset about this change? Should it be opt-in? Is it trivial and
should just be active?

So far, I just added things to the remote interface and I don't recall
complaints. I do not know how many clients actually parse the response.
Any input from you? You can speak up now, before a release fixes things.


Regards,

Thomas

[mpg123-users] mpg123 1.29.3 released

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

Hi folks,

here are some fixes arriving in mpg123 1.29.3:

1.29.3
------
- libmpg123: Catch more NULL pointer arguments in LFS wrappers
  (most prominently: mpg123_feedseek(), bug 328).
- mpg123:
-- Fix regression that did _not_ enable --remote-err on -s anymore.
-- Fix typos in man page (thanks to Naglis Jonaitis).
-- Drop mixed-up value limits on remote control SEQ command. It is up to you
   if you want to distort your sound.
-- Add note about equalizer frequency bands to man page.
- build: add BUILD_PROGRAMS option to ports/cmake

See https://mpg123.org/download.shtml for links and mirrors.


Alrighty then,

Thomas

Re: [mpg123-users] problem when i play internet radio

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

Am Tue, 26 Oct 2021 13:17:56 +0300
schrieb icehosting via mpg123-users <mpg...@li...>: 

> how i can create a debugging build? i have to do any change before
> configure and make commands?

./configure --enable-debug

enables the debugging messages for the build.

I wouldn't be surprised if the handling of broken network can be
improved.


Alrighty  then,

Thomas

Re: [mpg123-users] problem when i play internet radio

[icehosting <in...@ic...>]

the pc is a raspberry (with no desktop) and run raspbian (debian 10). I
have test it and with debian 11 with the same problem.
The IP is dynamic so every time i remove-plug the cable they
reconfigure the network.
If i unplug the cable for just some minutes the work fine, only if i remove
the cable for some hours i have this problem.
how i can create a debugging build? i have to do any change before
configure and make commands?
Thank you
Christos





On Tue, Oct 26, 2021 at 1:01 PM Thomas Orgis <th...@or...> wrote:

> In theory, the looping should do it. So it hangs waiting for data but does
> not error out. Can you do a debugging build and show the lines printed
> after pulling the cable?
>
> I'm also wondering about timeouts on reconnect for these situations ... or
> rather frenzied failed connection attempts until network is back.
>
> Does you pulling the cable imply the network being de-/reconfigured (like
> on a usual Linux desktop) or is it a static setup that then just has
> timeouts for packets being sent?
>
>
> Alrighty then,
>
> Thomas
> --
> sent from mobile device, trustworthy or not
>

Re: [mpg123-users] problem when i play internet radio

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

In theory, the looping should do it. So it hangs waiting for data but does not error out. Can you do a debugging build and show the lines printed after pulling the cable?

I'm also wondering about timeouts on reconnect for these situations ... or rather frenzied failed connection attempts until network is back.

Does you pulling the cable imply the network being de-/reconfigured (like on a usual Linux desktop) or is it a static setup that then just has timeouts for packets being sent?


Alrighty then,

Thomas

[mpg123-users] problem when i play internet radio

[icehosting <in...@ic...>]

Hello
i want to play a radio station. When the internet stop and come back i want
to continue to stream.
I use this options:
mpg123 --loop -1 http://radiostreamlink:8080/live.mp3

if i unplug the network cable for some seconds or some minutes and put it
back everything is ok, the sound stop and when i plug the cable the sound
start so they work fine.
But if i remove the network cable for hours and i put it back i still not
have sound. The mpg123 still is open (so i can't write a script to start it
when they stopped) however they not connect to the radio station.

Is this a bug? Or the --loop -1 don'y use unlimited tries to connect to the
stream? It is another setting in order t ohave it to work as expected?
Thank you

[mpg123-users] mpg123 1.29.2 released

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

Hi again,

another little bugfix release was due to make a previous improvement
actually active for the framebyframe API:

1.29.2
------
- libmpg123: Fix non-live-decoder safeguard for mpg123_framebyframe_decode()
  (was a no-op in practice, bug 324).


Get it while it's hot. Or later. Whatever suits you;-)


Alrigthy then,

Thomas

[mpg123-users] mpg123 1.29.1 released (fixing a 1.26 regression)

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

Dear mpg123 folks,

there is a new bugfix release of mpg123, available at the usual places:

1.29.1
------
- mpg123:
-- Keep default output encoding of s16 for raw and file outputs
   also with the new resampler. This reverts the unintentional change in
   1.26.0 of switching to f32 for forced output rate unless the NtoM
   resampler is selected. In any case, you should make sure to specify
   your desired --encoding if you depend on it.
-- Catch error in indexing (mpg123_scan() return value was ignored
   before, bug 322).
- mpg123-strip: Lift the resync limit, as it should be to clean up really
  dirty streams.
- mpg123-id3dump: Also lift resync limit for the same reasons.
- libout123: fix reporting of device property flags for buffer
- libmpg123: more safeguarding against attempts to decode if decoder
  setup failed and user ignored the returned error code (bug 322)

If you for some reason are stuck on 1.26.x, I recommend updating at
least to the changes in the 1.26-fixes branch. but of course, the
proper thing is to jump from 1.25.x or anything in between to 1.29.1 to
avoid that little default output encoding surprise with forced rate.


Alrighty then,

Thomas

Re: [mpg123-users] Calling MPG123 from Asterisk, version behavior changed

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

Am Mon, 27 Sep 2021 12:26:42 +0200
schrieb Carlos Oliva <car...@nu...>: 

> The patch provided seems not to be working as expected.
> /usr/bin/mpg123 -q -s -b96 -f 8192 -o wav --mono -r 8000

First: It would help debugging a lot if you exchanged -q for -vvv.

Second: Your peculiar use of the buffer process in connection with a
file or pipe output unmasked the issue of the buffer not reporting back
the device property flags, especially or telling apart live playback
and output to files.

A tiny buffer of 96K when piping output in asterisk. Are you shure that
really adds substantially to the buffering you get in the pipes anyway?

But anyhow, can you test again with the current
https://mpg123.org/snapshot ? It should also fix the default encoding
with -b96.


Alrighty then,

Thomas

Re: [mpg123-users] Calling MPG123 from Asterisk, version behavior changed

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

Am Mon, 13 Sep 2021 16:44:14 +0200
schrieb Carlos Oliva <car...@nu...>: 

> -e s16 do the work, I get the wanted output  in new and old versions.
> 
> I' ll try to submit a patch to Aterisk using the right parameters in
> app_mp3, as you sugested.

I fixed the behaviour in trunk and in the 1.26-fixes branch. Can you
please verify that

	https://mpg123.org/snapshot

behaves like 1.25 for you, defaulting to 16 bit output again for -s?

This is the relevant change, peobably included as a patch in distros
for mpg123 >= 1.26.0:

Index: src/audio.c
===================================================================
--- src/audio.c	(revisión: 4984)
+++ src/audio.c	(revisión: 4985)
@@ -1,3 +1,4 @@
+#define DEBUG
 /*
 	audio: audio output interface
 
@@ -425,6 +426,25 @@
 		{
 			enc1 &= force_fmt;
 			enc2 &= force_fmt;
+		} else
+		{
+			long propflags = 0;
+			out123_getparam_int(ao, OUT123_PROPFLAGS, &propflags);
+			if(!(propflags & OUT123_PROP_LIVE))
+			{
+				fmtcount = out123_formats(ao, NULL, 0, 1, 2, &outfmts);
+				if(fmtcount == 1 && outfmts[0].encoding > 0)
+				{
+					const char *encname = out123_enc_name(outfmts[0].encoding);
+					if(param.verbose > 1)
+						fprintf( stderr, "Note: honouring non-live default encoding of %s\n"
+						,	encname ? encname : "???" );
+					enc1 &= outfmts[0].encoding;
+					enc2 &= outfmts[0].encoding;
+				}
+				free(outfmts);
+				outfmts = NULL;
+			}
 		}
 		mdebug("enc mono=0x%x stereo=0x%x", (unsigned)enc1, (unsigned)enc2);
 		if(!enc1 && !enc2)


Alrighty then,

Thomas

Re: [mpg123-users] Calling MPG123 from Asterisk, version behavior changed

[Carlos O. <car...@nu...>]

Thank you Thomas!

-e s16 do the work, I get the wanted output  in new and old versions.

I' ll try to submit a patch to Aterisk using the right parameters in
app_mp3, as you sugested.

Thanks and regards,

*Carlos Oliva*


El sáb, 11 sept 2021 a las 14:47, Thomas Orgis (<tho...@or...>)
escribió:

> Am Sat, 11 Sep 2021 14:38:24 +0200
> schrieb Thomas Orgis <tho...@or...>:
>
> > At the same time, I am looking into whether it might be good to revert
> > to the old behaviour of s16 stereo as default format for writing to
> > files. 1.25.0 still worked that way. Since stable distros are slower to
> > picking up new versions, some more people could still be surprised.
>
> The change is the enabling of the new resampler by default in 1.26. It
> works
> with floating point numbers instead dropping/repeating samples in the
> decoder. So
>
> mpg123 […] --resample fine > out.raw
>
> will produce f32 output and
>
> mpg123 […] --resample ntom > out.raw
>
> will produce s16 output like before (with horrible but cheap resampling
> quality, which you might not care about for your use case).
>
> I think it is surprising that the choice of sampling rate — worse:
> resampling method — suddenly changes the encoding, although it is
> technically reasonable not to waste time on downconversion to s16
> unless forced to do so. I'll see to make a new release that fixes that.
> Perhaps also will provide some backport patch to push into distros like
> Debian … such errors bug me.
>
> In any case: It makes sense not to rely on this default encoding, so
> use -e s16 if you so desire.
>
>
> Alrighty then,
>
> Thomas
>
>
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users
>

Re: [mpg123-users] Calling MPG123 from Asterisk, version behavior changed

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

Am Sat, 11 Sep 2021 14:38:24 +0200
schrieb Thomas Orgis <tho...@or...>: 

> At the same time, I am looking into whether it might be good to revert
> to the old behaviour of s16 stereo as default format for writing to
> files. 1.25.0 still worked that way. Since stable distros are slower to
> picking up new versions, some more people could still be surprised.

The change is the enabling of the new resampler by default in 1.26. It works
with floating point numbers instead dropping/repeating samples in the
decoder. So

mpg123 […] --resample fine > out.raw

will produce f32 output and

mpg123 […] --resample ntom > out.raw

will produce s16 output like before (with horrible but cheap resampling
quality, which you might not care about for your use case).

I think it is surprising that the choice of sampling rate — worse:
resampling method — suddenly changes the encoding, although it is
technically reasonable not to waste time on downconversion to s16
unless forced to do so. I'll see to make a new release that fixes that.
Perhaps also will provide some backport patch to push into distros like
Debian … such errors bug me.

In any case: It makes sense not to rely on this default encoding, so
use -e s16 if you so desire.


Alrighty then,

Thomas

Re: [mpg123-users] Calling MPG123 from Asterisk, version behavior changed

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

Am Fri, 10 Sep 2021 18:33:32 +0200
schrieb Carlos Oliva <car...@nu...>: 

> Investigating the issue, I discovered that with old versions of mpg123
> everything works. but with Debian package version (1.26.4-1) or las 1.29
> version I always hear noise.

Noise suggests that the sample encoding is different than expected.
> 
> mpg123 -q -s -b 96 -f 8192 --mono -r 8000 http://server.url/file.mp3 >
> out.sln
> 
> using mpg123 version 1.26 or 1.29 I get a file of 424K
> using mpg123 version 1.20.1 I get a file of 212K

So you got a 14-second-track here that should get you

	16 bit × 8000 Hz × 13.6 s = 212K

but you get twice that? I'd assume that mpg123 creates f32 or s32
output, then. Please look at the output without -q and -vv instead.

And yes … newer mpg123 does default to 32 bit float when the output
supports it. Your output is a pipe/file without any preferences. I see
that the current behaviour might be surprising and maybe it needs fixing.

> Is there any command line switch I can use for having the same output than
> in old version? I tried, but I couldn' t find how to make mpg123 work as

In any case, you can specify -e s16 for 16 bit integer encoding. This
works with mpg123 since ages now (I don't remember the exact version it
was introduced, but it was much longer ago than 1.20). When not playing
to a hardware device that prescribes encodings, it is best to be
specific, like with --mono.

Can you communicate that to the Asterisk folks in case they have
defaults that miss this?

At the same time, I am looking into whether it might be good to revert
to the old behaviour of s16 stereo as default format for writing to
files. 1.25.0 still worked that way. Since stable distros are slower to
picking up new versions, some more people could still be surprised.


Alrighty then,

Thomas

[mpg123-users] Calling MPG123 from Asterisk, version behavior changed

[Carlos O. <car...@nu...>]

Hello  MPG123 users:

I'm using mpg123 as MP3 player for Asterisk, using the module app_mp3

Trying to update to Debian BullsEye, I noticed that when I use app_mp3 on
Asterisk I only hear Noise

Investigating the issue, I discovered that with old versions of mpg123
everything works. but with Debian package version (1.26.4-1) or las 1.29
version I always hear noise.

Executing the same commands that asterisk uses and sending stdout to a
file, I discovered that actual versions of MPG123 creates a file with
exactly the double size than the old mpg123 versions.

For example, for a certain MP3 that I get via HTTP and using the same
parameters that asterisk uses:

mpg123 -q -s -b 96 -f 8192 --mono -r 8000 http://server.url/file.mp3 >
out.sln

using mpg123 version 1.26 or 1.29 I get a file of 424K
using mpg123 version 1.20.1 I get a file of 212K

My question is:
Is there any command line switch I can use for having the same output than
in old version? I tried, but I couldn' t find how to make mpg123 work as
old versions.

Many thanks for your help,

*Carlos Oliva*

Re: [mpg123-users] Looping a single track

[Chris S. <ch...@da...>]

Thanks Thomas.

I pulled my existing code which used mpg123_replace_reader_handle() and
mpg123_open_handle() and reassembled it into a standalone test program
similar to those in doc/examples. I finally got it working when I realised
that I had to set MPG123_FORCE_SEEKABLE *before* the handle was opened, and
also use MPG123_DONE to detect the end of the stream and not to rely on the
value of 'done' returned from mpg123_read() being less than the requested
number as an indication that the stream had finished. For reference,
mpg123_to_wav_replaced_io.c doesn't set MPG123_FORCE_SEEKABLE so calls to
lseek_cb() never happen, which caught me out.

Now I just have to migrate the test program back into my application!

My test program is attached if you're interested to see. Please feel free
to add it to the examples in doc/examples if you feel it would be a useful
API demonstration.

Thanks for the help
Regards
Chis


On Tue, 7 Sept 2021 at 15:01, Thomas Orgis <tho...@or...> wrote:

> Am Tue, 7 Sep 2021 13:36:31 +0100
> schrieb Chris Smith <ch...@da...>:
>
> > I've tried replacing the read handler, using open_handle mpg123_read, and
> > tried using feedseek even though I'm not calling mpg123_feed, but I
> > inevitably end up with a "Warning: Encountered more data after announced
> > end of track (frame 582/582). Frankenstein!"
>
> This has less to do with your usage, but with the MPEG file containing
> an Info frame that tells the decoder how much data to expect. Libmpg123
> should continue decoding, but you're confusing it a bit. You got some
> options (without having looked at your example yet, sorry … I'm just
> quickly whipping up a reply, being busy with other stuff) please point
> out where I am going astray):
>
> You could cut out this info frame (tell libmpg123 to ignore it), but
> that would counter your goal of having seamless looping. That same info
> frame contains information to cut out samples that would introduce
> artificial gaps.
>
> > I need to start from scratch I think. So to simplify things for this post
> > and because mpg123_feed feels like the right thing to do,
>
> Usually, no. If you can wrap your head around function pointers, having
> your own callback reader functions is much easier to code and follow.
>
> I think you should just not try to trick libmpg123 into feeding an
> endless ringbuffer of data. Configure your handle read/seek callbacks
> that access the memory, use mpg123_open_handle() to open the track.
> Then, simply seek back to 0 on MPG123_DONE and continue decoding
> (filling up your output buffer).
>
> This way, the gapless decoding is still handled properly
> (encoder/decoder delay and padding being cut) and your loop can play
> seamlessly.
>
> The next best thing, if you don't care about gapless decoding, would be
> to simply implement your read callback with a ringbuffer to keep
> feeding MPEG frames and tell libmpg123 to ignore the info frame
> (flag MPG123_IGNORE_INFOFRAME). Downside here is that you'll have an
> endless position counter in libmpg123 that might and some distant time
> overflow.
>
> The best bet would be not to fool the decoder and just let it seek back
> to 0 on end.
>
>
> Alrighty then,
>
> Thomas
>
>
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users
>

Re: [mpg123-users] Looping a single track

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

Am Tue, 7 Sep 2021 13:36:31 +0100
schrieb Chris Smith <ch...@da...>: 

> I've tried replacing the read handler, using open_handle mpg123_read, and
> tried using feedseek even though I'm not calling mpg123_feed, but I
> inevitably end up with a "Warning: Encountered more data after announced
> end of track (frame 582/582). Frankenstein!"

This has less to do with your usage, but with the MPEG file containing
an Info frame that tells the decoder how much data to expect. Libmpg123
should continue decoding, but you're confusing it a bit. You got some
options (without having looked at your example yet, sorry … I'm just
quickly whipping up a reply, being busy with other stuff) please point
out where I am going astray):

You could cut out this info frame (tell libmpg123 to ignore it), but
that would counter your goal of having seamless looping. That same info
frame contains information to cut out samples that would introduce
artificial gaps.

> I need to start from scratch I think. So to simplify things for this post
> and because mpg123_feed feels like the right thing to do,

Usually, no. If you can wrap your head around function pointers, having
your own callback reader functions is much easier to code and follow.

I think you should just not try to trick libmpg123 into feeding an
endless ringbuffer of data. Configure your handle read/seek callbacks
that access the memory, use mpg123_open_handle() to open the track.
Then, simply seek back to 0 on MPG123_DONE and continue decoding
(filling up your output buffer).

This way, the gapless decoding is still handled properly
(encoder/decoder delay and padding being cut) and your loop can play
seamlessly.

The next best thing, if you don't care about gapless decoding, would be
to simply implement your read callback with a ringbuffer to keep
feeding MPEG frames and tell libmpg123 to ignore the info frame
(flag MPG123_IGNORE_INFOFRAME). Downside here is that you'll have an
endless position counter in libmpg123 that might and some distant time
overflow.

The best bet would be not to fool the decoder and just let it seek back
to 0 on end.


Alrighty then,

Thomas