mpg123 - audio too fast -r, --rate option ignored

[radiohead319]

I've been using mpg123 to pipe an internet radio feed into toolame and then the mux.  It works, but the audio too fast, and frequent audio drop-outs.  The cause is obviously because the incoming stream is 44.1kHz, while Toolame clocks it out at 48kHz.   However the weird thing is that the -r option is getting ignored.  I can set the integer value after -r to any number, or remove the option all together and the audio does not change - still too fast and drop-outs.   Yet this is a copy-paste of the same command line that Clarkerz uses for his mux, and on his version the audio is the correct speed without dropouts!

Why?

Any ideas/pointers please?

I'm doing this on Ubuntu 14.04 on a laptop.

[Clarkerz]

Just a thought Glyn stick the output to a wav file rather than stdout and then make sure it is saving at 48Khz and stereo if not add --stereo  after the 48000

mpg123 -r 48000 -w test.wav http://streamname/mount

[radiohead319]

I already tried the --stereo option - didn't help.  But good idea to try wav and see what its outputting.  Pretty sure it will be a fast wav file!

[Rash]

The header of your source stream:

MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo

Makes me think you're encoding a 44.1 kHz source, and not resampling to 48 kHz. So it will sound 'fast' and intermittent.

R.

On 27 Mar 2015, at 15:31, radiohead319 <glyn.m....@googlemail.com> wrote:

MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo

[Clarkerz]

Hi Glyn,

I was trying to find your post where you were getting a core dump using' toolame -V -s 48 -m s -b 192 http://stream:port tcp://192.168.1.12:7001' however I think you might just have mailed it to me and not posted it.

Anyway, it appears that if the vlc flag (-V) in toolame on my dreaded Pi2's set then it works OK. I though I'd check it both my x64 machines running the same version of toolame (Jen's latest package) and ran a core dump when I tried the alsa:// option - however it also did a core dump using the above command as well so ironically both my Pi2's work fine, but both my x64's coredump with any input from vlc.

Also I have finally concluded that the UCA202 fails on the Pi2's after a few hours with ecasound however the x64 machines go and (currently at 2M samples and counting!)

I've attached it (removed the shout server URL/name) and it appears to be exactly the same as your error.

I think it's something to do with the plugin cache:

Bothx64 machines which fail :

[0x1e411e8] main libvlc debug: loading plugins cache file /usr/lib/vlc/plugins/plugins.dat
[0x1e411e8] main libvlc warning: This doesn't look like a valid plugins cache
[0x1e411e8] main libvlc debug: recursively browsing `/usr/lib/vlc/plugins'
[0x1e411e8] main libvlc debug: saving plugins cache /usr/lib/vlc/plugins/plugins.dat
[0x1e411e8] main libvlc debug: plug-ins loaded: 399 modules
[0x1e411e8] main libvlc debug: translation test: code is "C"
[0x1e411e8] main libvlc debug: CPU has capabilities MMX MMXEXT SSE SSE2 SSE3 SSSE3 FPU

Both Pi2's that work have this (with no cache error):

[0x18c2120] main libvlc debug: loading plugins cache file /usr/lib/vlc/plugins/plugins.dat
[0x18c2120] main libvlc debug: recursively browsing `/usr/lib/vlc/plugins'
[0x18c2120] main libvlc debug: saving plugins cache /usr/lib/vlc/plugins/plugins.dat
[0x18c2120] main libvlc debug: plug-ins loaded: 397 modules
[0x18c2120] main libvlc debug: translation test: code is "C"
[0x18c2120] main libvlc debug: CPU has capabilities ARM_NEON FPU
[0x1a09340] main input debug: Creating an input for 'http://sc6.radiocaroline.net:8040'
VLC launched.
[0x76100788] main stream output debug: using sout chain=`transcode{acodec=s16l,samplerate=48000}:smem{audio-postrender-callback=87261,audio-prerender-callback=87221}'
[0x76100788] main stream output debug: stream=`smem'
[0x76100ac0] main stream out debug: looking for sout stream module matching "smem": 21 candidates

I also had a look at the different complied  options and there were three extra options on the x64 which fails, crystalhd, sse and mmx, but not sure that ahs any relevance. (see attached xls). Will still need to sue the Pi2s for now. :(

[radiohead319]

Seeing as I can't get the vlc toolame running, I've reverted to the mgg123 pipe method and done a little troble-shooting.   The command stram I'm using is:

mpg123 -r 48000 -s http://sc6.radiocaroline.net:8040/ |toolame -s 48 -m s -b 128 /dev/stdin tcp://192.168.1.75:7001

If I save the mpg123 into a wav file, it results in correct audio - normal speed, and no dropouts.  BUT it is a 16 bit 44.1kHz file - so apparently it seems mpg123 is not resampling it to 48kHz??   I think that's the problem - because whatever I set the -r figure to, it makes no difference.

So I think my question now is - "can anyone think why mpg123 would be ignoring the -r option in my command?

Thanks, Glyn

[Dennis Wynes]

What happens if you force stereo with --stereo combined with -r

[radiohead319]

Thanks Dennis.
Foolishly I had [previously assumed the -s option did same as --stereo!

Anyway when I add --stereo it breaks the command - it just returns to command prompt after a short delay.  I've tried adding the --stereo ant varios points in the mpg123 part of the command....

[Dennis Wynes]

What if you Increase the verbosity of mpg123 with -vvv and toolame with -t 2 and instead of /dev/stdin use just a hyphen - and see what you get. I would use -r 48 --stereo together.

ps I'm winging it here from a low level of knowledge so if it's bollox apologies in advance. ;-)

[Glyn Roylance]

Oh Dennis, you've spoilt the illusion now, I thought you were one of those Linux greybeards!

I tried all those suggestions, and also set the toolame to joint stereo, but audio still fast.....

It's a bit weird, becuse the line "Input File : '/dev/stdin'   48.0 kHz" suggests to me that mpg123 has done its job and transcoded the 44.1 stream into 48.  But I may well be wrong on that.   Yet when I set mpg to output a wav file it is 44.1, ignoring the 48000 option.

abc@ABC:~/DAB/DAB3$ mpg123 -r 48000 --stereo -s -v http://sc6.radiocaroline.net:8040/ |toolame -s 48 -m j -b 128 -t 2 /dev/stdin tcp://192.168.1.75:7001
Reading from stdin
Remember to set samplerate with '-s'.
--------------------------------------------
Input File : '/dev/stdin'   48.0 kHz
Output File: 'tcp://192.168.1.75:7001'
128 kbps MPEG-1 Layer II j-stereo Psy model 1
[De-emph:Off    Copyright:No    Original:No    CRC:On]
[Padding:Normal    Byte-swap:Off    Chanswap:Off    DAB:On]
ATH adjustment 0.000000
--------------------------------------------
encode_init: using tablenum 0 with sblimit 27
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3.
Version 0.3.2-1 (2012/03/25). Written and copyrights by Joe Drew,
now maintained by Nanakos Chrysostomos and others.
Uses code from various people. See 'README' for more!
THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!

Directory: http:
Playing MPEG stream from sc6.radiocaroline.net ...
MPEG 1.0, Layer: III, Freq: 44100, mode: Joint-Stereo, modext: 2, BPF : 2560
Channels: 2, copyright: No, original: No, CRC: No, emphasis: 0.
Bitrate: 128 Kbits/s, Extension value: 2
Audio: 1:1 conversion, rate: 44100, encoding: signed 16 bit, channels: 2
^C                                                                           
[0:58] Decoding of sc6.radiocaroline.net finished.

--
You received this message because you are subscribed to the Google Groups "mmbtools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clarkerz]

Glyn, best you bin that laptop and come and grab one of these Dell Poweredges. It all works on these! :)

[Clarkerz]

Glyn,

Have set you up a 48Khz 16bit 128Kb/s test stream - Just to see if this works anything:  http://stream.severnfm.com:8000/test  (clutching at straws time for me now :) ) Its just one Abba song repeating (who doesn't like Abba!!??

Let me know if this works.

Cheers

Andy

On Saturday, 11 April 2015 17:51:46 UTC+1, radiohead319 wrote:

[Glyn Roylance]

Well it gets stranger Andy!

When I try that it says "MPEG 1.0 layer I, 121 kbit/s, 44100 Hz stereo" (strange if it is a 48kHz stream) - but actually it sounds the right speed (if anything a little slow, but that's probably my imagination!)

Interestingly if I remove the -r 48000 part of the command it crashes the mux and I need to reinstate that option and restart the mux to get audio back.

What's the name of the game?

Glyn

[Matthias Brändli]

On 12. 04. 15 10:43, Glyn Roylance wrote:
> Interestingly if I remove the -r 48000 part of the command it crashes
> the mux and I need to reinstate that option and restart the mux to get
> audio back.

Now you got my attention ! :-D

It crashes odr-dabmux or the encoder ?



On my system, both

mpg123 -r 48000 --stereo -s -v http://sc6.radiocaroline.net:8040/ |

aplay -f dat

and

mpg123 -r 44100 --stereo -s -v http://sc6.radiocaroline.net:8040/ |
aplay -f cd

sound right, but other combinations are too fast or too slow. That's
probably a fairly safe way to check what the sample rate of your mpg123
output is.

mpb

[Matthias Brändli]

Hi,

I had a look at your XLS comparison. The differing options are
CPU-specific extensions, that do exist on x86 and x86_64, but not on
ARM. So that's no surprise it changes. (Except crystalhd, no idea what
this is but it doesn't sound important ;-) )

Your VLC output seems ok (except for the usage of the ugly_resampler
instead of the better libsamplerate one).

It's been quite some time since I didn't do a test on ARM anymore. I
will wake up my Raspi again, do all the updates and and try the VLC
input there.

mpb

On 28. 03. 15 16:07, Clarkerz wrote:
> Hi Glyn,
>
> I was trying to find your post where you were getting a core dump using'
> toolame -V -s 48 -m s -b 192 http://stream:port tcp://192.168.1.12:7001'
> however I think you might just have mailed it to me and not posted it.
>
> Anyway, it appears that if the vlc flag (-V) in toolame on my dreaded
> Pi2's set then it works OK. I though I'd check it both my x64 machines
> running the same version of toolame (Jen's latest package) and ran a
> core dump when I tried the alsa:// option - however it also did a core
> dump using the above command as well so ironically both my Pi2's work
> fine, but both my x64's coredump with any input from vlc.
>
> Also I have finally concluded that the UCA202 fails on the Pi2's after a
> few hours with ecasound however the x64 machines go and (currently at 2M
> samples and counting!)
>
> I've attached it (removed the shout server URL/name) and it appears to
> be exactly the same as your error.
>
> I think it's something to do with the plugin cache:
>
> Bothx64 machines which fail :
>
> [0x1e411e8] main libvlc debug: loading plugins cache file
> /usr/lib/vlc/plugins/plugins.dat

> [0x1e411e8] main libvlc warning: *This doesn't look like a valid plugins
> cache*

> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com

> <mailto:crc-mmbtools...@googlegroups.com>.

[Glyn Roylance]

I'll give your command options a go in a minute Matthias.

Re:  the crash.  It's not a crash as such - but nevertheless not an ideal behaviour.  If I remove the -r 48000 option, then run the command, I only get a very faint audio that is "choppy" - a bit like a very distant AM station at night.   Then if I re-insert the -r 48000 option, it continues with the naff audio.  But if I stop the mux and restart it (leaving mpg/toolame running), then normal audio is restored.   Some kind of synch issue maybe?

I guess no-one is stupid enough to run mpg123 without a -r option, so they won't have experienced this!

Glyn

[Glyn Roylance]

Just tried both of your command lines Matthias - both sound the same - too fast and occasional audio dropout.  (I also got the choppy audio problem swapping from Andy's stream, so had to restart the mux)

It's not massively too fast, so it needs to be a song or presenter you know to tell.  But definitely too fast and high pitch.

I'm not sure if it means anything, but with either command it reports "Audio: 1:1 conversion, rate: 44100, encoding: signed 16 bit, channels: 2".  Surely with the first command it should say 48000 and a conversion of 1:1.088 ?

Glyn

On 12 April 2015 at 09:57, Matthias Brändli <matthias...@mpb.li> wrote:

[Matthias Brändli]

So it could be a mis-alignment in the multiplexer.

I'll check if there is some state (a buffer or something) in ODR-DabMux
that could cause this.

mpb

On 12. 04. 15 12:08, Glyn Roylance wrote:
> I'll give your command options a go in a minute Matthias.
>
> Re: the crash. It's not a crash as such - but nevertheless not an
> ideal behaviour. If I remove the -r 48000 option, then run the command,
> I only get a very faint audio that is "choppy" - a bit like a very
> distant AM station at night. Then if I re-insert the -r 48000 option,
> it continues with the naff audio. But if I stop the mux and restart it
> (leaving mpg/toolame running), then normal audio is restored. Some
> kind of synch issue maybe?
>
> I guess no-one is stupid enough to run mpg123 without a -r option, so
> they won't have experienced this!
>
> Glyn
>
> On 12 April 2015 at 09:57, Matthias Brändli <matthias...@mpb.li

> <mailto:matthias...@mpb.li>> wrote:
>
> On 12. 04. 15 10:43, Glyn Roylance wrote:
> > Interestingly if I remove the -r 48000 part of the command it crashes
> > the mux and I need to reinstate that option and restart the mux to get
> > audio back.
>
> Now you got my attention ! :-D
>
> It crashes odr-dabmux or the encoder ?
>
>
>
> On my system, both
>
> mpg123 -r 48000 --stereo -s -v http://sc6.radiocaroline.net:8040/ |
> aplay -f dat
>
> and
>
> mpg123 -r 44100 --stereo -s -v http://sc6.radiocaroline.net:8040/ |
> aplay -f cd
>
> sound right, but other combinations are too fast or too slow. That's
> probably a fairly safe way to check what the sample rate of your mpg123
> output is.
>
> mpb
>
> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to crc-mmbtools...@googlegroups.com

> <mailto:crc-mmbtools%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com

> <mailto:crc-mmbtools...@googlegroups.com>.