ggalt / squeezelite

Automatically exported from code.google.com/p/squeezelite
Other
0 stars 0 forks source link

Incorrect sample rate for shoutcast stations combined with resampling and pipe out = wrong playout speed #103

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
We use vortexbox 2.3 with a custom build of Squeezelite v1.6.4 
(OPTS="-DRESAMPLE -DDSD") to allow sox resampling + pipe out, to do further DSP 
processing using sox, ecasound, ....

With internet radio stations, we notice the playout speed is sometimes 1/4 or 
1/8 of the expected speed. We noticed squeezelite is sometimes recognizing a 
128kpbs mp3 station to have a sample rate of 12000 or 24000 while it should be 
44100. As this generates more samples when upsampling, at the receiving side of 
the pipe, sox and ecasound assume 96k so it plays at 1/2 to 1/4 of the speed as 
it takes 2 to 4 times the time to consume the generated samples by squeezelite.

What steps will reproduce the problem?

The problem only occurs when squeezelite restarts and an internet radio 
stattion was playing, or when changing between stattions. To duplicate, I have 
to restart squeezelite in a loop until the problem appears, as it does not 
always appear. It typical takes several tries before the issue appears:

while true
do
/usr/local/sbin/squeezelite -d all=info -s 127.0.0.1 -o - -a 32 -m 
00:04:20:F8:D4:90 -n EVO -u v -r 96000-96000 | ecasound -q -B:rt -r:80 -b:32 
-f:s32_le,2,96000,i -i:stdin -o:alsaplugin,1,0
sleep 10
killall squeezelite
done

What is the expected output?

I see the stream being detected as 44.1 Khz and correctly upsampled to 96K:

[18:57:41.827017] stream_thread:229 icy meta: len: 64
StreamTitle='Earl Klugh - I Say A Little Prayer';StreamUrl='';
[18:57:42.073508] mad_decode:242 setting track_start
[18:57:42.073649] resample_newstream:186 resampling from 44100 -> 96000
[18:57:42.075129] process_newstream:123 processing: active
[18:57:42.082171] _output_frames:59 start buffer frames: 8131
[18:57:42.082338] _output_frames:144 track start sample rate: 96000 
replay_gain: 0

What do you see instead?

Sometimes it detects the 44.1k stream as 24k or even 12k:

24 khz

[18:59:41.994529] stream_thread:229 icy meta: len: 64
StreamTitle='Jim Tomlinson - Camhinos Cruzados';StreamUrl='';
[18:59:42.249271] mad_decode:242 setting track_start
[18:59:42.249590] resample_newstream:186 resampling from 24000 -> 96000
[18:59:42.250736] process_newstream:123 processing: active
[18:59:42.256420] _output_frames:59 start buffer frames: 6064
[18:59:42.256834] _output_frames:144 track start sample rate: 96000 
replay_gain: 0

12 khz

[19:07:10.044708] stream_thread:229 icy meta: len: 80
StreamTitle='Mark Boling & Keith Brown - Old Devil Moon';StreamUrl='';
[19:07:10.377439] mad_decode:242 setting track_start
[19:07:10.377678] resample_newstream:186 resampling from 12000 -> 96000
[19:07:10.378856] process_newstream:123 processing: active
[19:07:10.395294] _output_frames:59 start buffer frames: 11760
[19:07:10.395443] _output_frames:144 track start sample rate: 96000 
replay_gain: 0

What version of the product are you using? On what operating system?

Squeezelite v1.6.4 on vortexbox 2.3
ecasound v2.9.0
SoX v14.4.1
the issue appears with both sox and ecasound

Please provide any additional information below.

When the stream is incorrectly detected, we also hear a typical MP3 artefact 
before it plays the music slower, as if the firt part of the stream is wrong, 
and by result the correct sample rate is not recognised from shoutcast.

Stream used as tunein in LMS:

TheJazzGroove.com
128kbps CBR, MP3 Radio

URL: http://199.180.72.6/ 

Original issue reported on code.google.com by audioha...@gmail.com on 10 Jun 2015 at 5:37

GoogleCodeExporter commented 9 years ago
Hy, i have the same problem! 
unfortunately I can not help in solving this issue. I am grateful to a solution.
My system:
Odroid U3 with USB-Soundcard behringer u-control uca222

THX

Original comment by seve...@elmecker.net on 21 Jun 2015 at 10:11