Home of the Squeezebox™ & Transporter® network music players.
Page 5 of 8 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 77
  1. #41
    Senior Member
    Join Date
    Jan 2017
    Posts
    156
    Quote Originally Posted by bpa View Post
    The strange thing is that within the MP3 audio frame header, the sample rate of the audio stream is specified.
    The HDMI output device should be opened with the rate found in the MP3 frame.

    Can you confirm the hardware which is running PCP - what version of a Pi hardware so that maybe others can test ?
    What model of Marantz - with HDMI there is negotiation as to what rates are supported by HDMI device.
    Yeah, the log shows that it does not find the sample rate and maybe guesses it from the first data....

    It is a RasPi Model 3B with Marantz SR 6013, JiveLite on official 7'' touchscreen, LMS 8.1 and SqueezeLite updated to current version:

    Code:
    piCorePlayer | piCorePlayer v6.1.0 | www v0009 | linux 4.19.122-pcpCore_v7 | piCore v10.3pCP | Squeezelite v1.9.9-1386-pCP
    The thing I am really confused about is that with flac or aac, 48 kHz rates are no problem. So as data out to the HDMI is PCM anyway, the Marantz should not notice whether it was mp3 or aac or flac originally.
    Last edited by schup011; 2021-08-02 at 04:06.

  2. #42
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,748
    Quote Originally Posted by schup011 View Post
    Yeah, the log shows that it does not find the sample rate and maybe guesses it from the first data....
    to save time - can you which post/log this is shown. MP3 frame are invalid without sample rate and cannot be decoded. It cannot be guessed.

    The thing I am really confused about is that with flac or aac, 48 kHz rates are no problem. So as data out to the HDMI is PCM anyway, the Marantz should not notice whether it was mp3 or aac or flac originally.
    The HDMI interface is an ALSA interface to squeezelite. Depending on the HDMI interface capabilities and the ALSA device opened - the ALSA can resample streams which are incompatible.
    The interface expects PCMs frames and also when opening the ALSA device parameters about the PCM stream such as sample size (e.g. 16bit, 24bit), channels and how fast to play the frames.
    For some reason after decoding MP3 frames, squeezelite decides to open the ALSA device with 44.1khz and not 48kHz. 48kHz MP3 is unusual and so perhaps there is a bug where the 48kHz gets "lost".

    A squeezelite bug should be replicable and so show up on other systems.

  3. #43
    Senior Member
    Join Date
    Jan 2017
    Posts
    156

    LMS logs

    Here is how LMS reacts for the two different streams (mp3 codec not excluded in Squeezelite). Looks weird.

    First, on 14:07:44, the "problematic" mp3 stream was requested. Then after a few seconds, it played, but too slow.
    Second, on 14:08:05, the aac stream of the same radio was requested. After a few seconds it played ok.

    server.log-4.txt

    Also here, something looks not really ok. Many iterative checks of how to transcode....

  4. #44
    Senior Member
    Join Date
    Jan 2017
    Posts
    156
    Quote Originally Posted by bpa View Post
    to save time - can you which post/log this is shown. MP3 frame are invalid without sample rate and cannot be decoded. It cannot be guessed.
    Have a look at post #36.

    Quote Originally Posted by bpa View Post
    For some reason after decoding MP3 frames, squeezelite decides to open the ALSA device with 44.1khz and not 48kHz. 48kHz MP3 is unusual and so perhaps there is a bug where the 48kHz gets "lost".
    I know only 48 kHz radio streams, regardless whether mp3 or aac. In my music library, of course, there are only mp3 with 44.1 kHz (CD rips).
    Last edited by schup011; 2021-08-02 at 05:47.

  5. #45
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,748
    Quote Originally Posted by schup011 View Post
    Have a look at post #36.
    I think that may be "Normal".

    MP3 audio data is made up of many frames. Each frame has a header (indicated by a unique byte sequence - 0xFF, 0xF? I think) which have details of the stream and then the audio data.

    MP3 Files will always start with a header.
    MP3 stream are continuous so when players "joins" the broadcast - it could be in the middle of the audio data part but player doesn't know stream or file. So decoder will look at first few bytes which is likely to NOT be a header so decoder will fail and so decoder will then skip data by looking for 0xFF, 0xF? sequence to find next MP3 header & frame.

  6. #46
    Senior Member
    Join Date
    Jan 2017
    Posts
    156
    Here is the same as in post #36, but with a 48 kHz mp3 file, instead of a stream:

    Code:
    [16:06:18.255587] codec_open:264 codec open: 'm'
    [16:06:18.255618] codec_open:281 closing codec: 'f'
    [16:06:18.255860] connect_socket:164 connecting to 192.168.0.161:9000
    [16:06:18.256142] stream_sock:600 header: GET /stream.mp3?player=b8:27:eb:74:ea:41 HTTP/1.0
    
    
    [16:06:18.256176] sendSTAT:195 STAT: STMc
    [16:06:18.256260] process_strm:384 set fade mode: 0, channels: 0, invert: 0
    [16:06:18.257108] process:528 audg
    [16:06:18.257152] process_audg:440 audg gainL: 3328 gainR: 3328 adjust: 0
    [16:06:18.257182] set_volume:233 setting internal gain left: 65536 right: 65536
    [16:06:18.288231] stream_thread:331 headers: len: 491
    HTTP/1.1 200 OK
    Server: Logitech Media Server (8.1.1 - 1610364019)
    Connection: close
    Content-Type: audio/mpeg
    Set-Cookie: Squeezebox-albumView=; path=/
    Set-Cookie: Squeezebox-expandPlayerControl=true; path=/
    Set-Cookie: Squeezebox-expanded-MY_MUSIC=1; path=/
    Set-Cookie: Squeezebox-expanded-FAVORITES=1; path=/
    Set-Cookie: Squeezebox-expanded-PLUGINS=1; path=/
    Set-Cookie: Squeezebox-expanded-PLUGIN_MY_APPS_MODULE_NAME=1; path=/
    Set-Cookie: Squeezebox-expanded-RADIO=1; path=/
    
    
    [16:06:18.288349] sendRESP:226 RESP
    [16:06:18.405621] mad_decode:235 mad_frame_decode error: bad main_data_begin pointer
    [16:06:18.407177] mad_decode:247 setting track_start
    [16:06:18.407262] mad_decode:276 gapless: skipping 529 frames at start
    [16:06:19.400020] sendSTAT:195 STAT: STMt
    [16:06:20.400647] sendSTAT:195 STAT: STMt
    [16:06:21.002235] process:528 strm
    [16:06:21.002322] process_strm:280 strm command t
    [16:06:21.002357] sendSTAT:195 STAT: STMt
    [16:06:22.003548] sendSTAT:195 STAT: STMt
    [16:06:23.004889] sendSTAT:195 STAT: STMt
    [16:06:24.005577] sendSTAT:195 STAT: STMt
    [16:06:25.006909] sendSTAT:195 STAT: STMt
    [16:06:26.001616] process:528 strm
    [16:06:26.001706] process_strm:280 strm command t
    [16:06:26.001740] sendSTAT:195 STAT: STMt
    [16:06:27.002940] sendSTAT:195 STAT: STMt
    [16:06:27.096859] _output_frames:153 track start sample rate: 44100 replay_gain: 0
    Maybe, LMS - before that - does strange things with the data and corrupts them somehow - see post #43.
    Last edited by schup011; 2021-08-02 at 07:59.

  7. #47
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,748
    Quote Originally Posted by schup011 View Post
    Maybe, LMS - before that - does strange things with the data and corrupts them somehow - see post #43.
    The log looks OK to me - except for

    [21-08-02 14:07:49.5340] Slim::Player::Source::_readNextChunk (314) Sending 12246 bytes of silence.
    This is odd because IIRC (needs to check) the silence samples LMS uses is encoded into 44.1Khz (file silence.mp3 or lbrsilence.mp3)?

    Have you asked LMS to insert a delay (aka silence) through the "audio startup time" setting ?

    edit:

    Silence played fast or slow should make no difference but this is a weird problem so must consider everything.

  8. #48
    Senior Member
    Join Date
    Jan 2017
    Posts
    156

    Seems we have understood the problem

    Quote Originally Posted by bpa View Post
    The log looks OK to me - except for


    This is odd because IIRC (needs to check) the silence samples LMS uses is encoded into 44.1Khz (file silence.mp3 or lbrsilence.mp3)?

    Have you asked LMS to insert a delay (aka silence) through the "audio startup time" setting ?

    edit:

    Silence played fast or slow should make no difference but this is a weird problem so must consider everything.
    You are my hero!

    It was the silence. I had entered it because sometimes my Marantz was a little late in starting. I set it to zero - and everything is playing ok.

    So it seems that we have tracked down the problem. I think it could be reproduced now with adding the "Audio startup time" to 1s.

    Of course would be great to have it working also with the silence. So either LMS must modify the silence header for the final sample rate or resend the header when the silence is over, or Squeezelite be fixed to recognize the "on-the-fly" sample rate change.

    Who can fix this?
    Last edited by schup011; 2021-08-02 at 09:26.

  9. #49
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,748
    Quote Originally Posted by schup011 View Post
    You are my hero!

    It was the silence. I had entered it because sometimes my Marantz was a little late in starting. I set it to zero - and everything is playing ok.

    So it seems that we have tracked down the problem. I think it could be reproduced now with adding the "Audio startup time" to 1s.
    Great that problem has been tracked down. It is an old feature which clearly is not used much and possible some of recent development have introduced an incompatibility.

    Of course would be great to have it working also with the silence. So either LMS must modify the silence header for the final sample rate or resend the header when the silence is over, or Squeezelite be fixed to recognize the "on-the-fly" sample rate change.

    Who can fix this?
    Michael would certainly co-ordinate as necessary.
    Next step is diagnose what has been broken - perhaps it has been broken for a long time.
    Philippe made a lot of "streaming audio" changes for 8.* so I'm guessing he'll check to see if some of his changes cause the problem.

  10. #50
    Senior Member
    Join Date
    Jan 2017
    Posts
    156
    It's really funny and I wonder why I haven't noticed that before. I just always wondered why there were some jumps and left out music.

    And I only realized that something is wrong when I listened to a live performance of "Tristan und Isolde" with my favourite tenor Jonas Kaufmann. I thought: "Oh my, he is not in a good shape today, his voice sounds so extremely deep". Then I checked my recording from DVB-S and everything was normal...

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •