Home of the Squeezebox™ & Transporter® network music players.
Page 6 of 6 FirstFirst ... 456
Results 51 to 57 of 57

Thread: 1.fm?

  1. #51
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,789
    Quote Originally Posted by mrw View Post
    I'm impressed that you were able to something with it.

    So, perhaps appropriate if the problem is a "basically OK but occasionally glitched" incoming remote AAC stream, but not particularly appropriate if it is just fundamentally duff (or MP3...).

    With the basic problem fixed, you have the freedom to do whatever you think may be most practicable/expedient/useful/time to move on/whatever you feel.
    Turns out the sample.m4a file in the ffmpeg ticket has the audio at the beginning of the file so can't be played native, so that file is no good for testing. When I optimized the file using mp4file or ffmpeg to move the atoms to the beginning it plays fine as the process "fixes/hides" the sync errors. You have to have MPEG-4 leading audio disabled in LMS file types as well for the test.

    I did some digging into the sync vs bits error logging between the stock and community firmware. The API has changed for sync error handling from the original proprietary fdk aac and the current android version 2.0.1 I'm using. Both the AAC_DEC_TRANSPORT_SYNC_ERROR and AAC_DEC_NOT_ENOUGH_BITS API errors are to be handled by reading more of the stream. In squeezeplay I tried checking for the SYNC error before BITS but the api still returns the BITS error for the 1.fm stream. I suspect if it wasn't for the segfault we wouldn't have even noticed.

    I did discover that I used the wrong return code for the SYNC error checking, which I've changed. Now I need to find a file/stream that triggers the error.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  2. #52
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    749
    Quote Originally Posted by ralphy View Post
    Now I need to find a file/stream that triggers the error.
    I've conjured up a file that contains plenty of errors, and have attached it. It is a plain '.aac' file, which I have constructed by downloading 40 seconds or so from a remote stream, and specifying that icy metadata should be included. So it is reasonably full of "duff data".

    I play that file by dropping it into my music folder, and browsing for it in the Squeezeplay BMF menu.

    Findings:

    On the standard Radio firmware we appear to have solid playback. Surprisingly, only one 'sync error' is reported, although I expected to see many more. I don't know why we don't.

    On the Community version we get, as expected, a reboot.

    So, I don't know that this particular "stream with duff data" is necessarily a good sample for robustness testing, but it might be educational to see how your revised decoder fares with it.


    I've attached logs.
    Attached Files Attached Files

  3. #53
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,789
    Quote Originally Posted by mrw View Post
    I've conjured up a file that contains plenty of errors, and have attached it. It is a plain '.aac' file, which I have constructed by downloading 40 seconds or so from a remote stream, and specifying that icy metadata should be included. So it is reasonably full of "duff data".

    I play that file by dropping it into my music folder, and browsing for it in the Squeezeplay BMF menu.

    Findings:

    On the standard Radio firmware we appear to have solid playback. Surprisingly, only one 'sync error' is reported, although I expected to see many more. I don't know why we don't.

    On the Community version we get, as expected, a reboot.

    So, I don't know that this particular "stream with duff data" is necessarily a good sample for robustness testing, but it might be educational to see how your revised decoder fares with it.


    I've attached logs.
    Thanks for the test file. To avoid reflashing devices too often, I've been comparing behaviour of the CF on the radio vs stock on my touch.

    With the change I posted earlier, the community firmware no longer crashes, however, it also doesn't even try to play the file on the radio, the mp4 parser throws an error and moves on to the next file in the queue, or stops if it's the only track.

    Code:
    Jan 30 14:05:04 squeezeplay: ERROR  audio.codec - mp4_open:697 premature end of stream
    Jan 30 14:05:04 squeezeplay: DEBUG  audio.decode - Playback.lua:320 status DECODE UNDERRUN
    Interestingly, I also get the exact same behaviour on the touch running the last logitech 7.8.0 r16754 build, the only difference is that the stock firmware keeps playing silence instead of stopping with only one file in the queue.

    Code:
    Jan 31 08:52:21 squeezeplay: ERROR  audio.codec - mp4_open:697 premature end of stream
    Jan 31 08:52:21 squeezeplay: DEBUG  audio.decode - Playback.lua:320 status DECODE UNDERRUN
    The are no sync errors reported on either device for that file.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  4. #54
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    749
    Quote Originally Posted by ralphy View Post
    Interestingly, I also get the exact same behaviour on the touch running the last logitech 7.8.0 r16754 build, the only difference is that the stock firmware keeps playing silence instead of stopping with only one file in the queue.

    Code:
    Jan 31 08:52:21 squeezeplay: ERROR  audio.codec - mp4_open:697 premature end of stream
    Jan 31 08:52:21 squeezeplay: DEBUG  audio.decode - Playback.lua:320 status DECODE UNDERRUN
    Questions:

    Why does your stock firmware behave differently to my stock firmware ?
    Why is your stock firmware trying to open an 'mp4' file ? The test file is not an 'mp4' file.

    What are you seeing in place of my stock firmware log here ?
    Code:
    Jan 30 14:57:08 squeezeplay: DEBUG  audio.decode - decode_start:703 decode_start
    Jan 30 14:57:08 squeezeplay: INFO   audio.decode - decode_start_handler:279 init decoder aac
    ...
    Jan 30 14:57:08 squeezeplay: DEBUG  audio.codec - src/decode_aac.c:473 decode_aac_start(2)

    My tests are with LMS 8.01. Have there been changes in aac/mp4 handling since then that might be influencing what the device has been told about the stream ?

    It's disappointing. I thought I had an "easy" test file, but I suspect that LMS/other factor is getting in the way. Without that out of the way, it will be difficult to draw any conclusions. My goal was to easily deliver a 'duff' aac stream. It seems that that is a failure on your set up, for some reason.

    Edit: I've just re-run the test on Logitech Media Server Version: 8.1.1 - 1610364019, the latest available.
    I get the same result as I did before. Which seems to rule out LMS as the source of the problem.
    Last edited by mrw; 2021-01-31 at 09:15.

  5. #55
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,789
    Quote Originally Posted by mrw View Post
    Questions:

    Why does your stock firmware behave differently to my stock firmware ?
    Why is your stock firmware trying to open an 'mp4' file ? The test file is not an 'mp4' file.

    What are you seeing in place of my stock firmware log here ?
    Code:
    Jan 30 14:57:08 squeezeplay: DEBUG  audio.decode - decode_start:703 decode_start
    Jan 30 14:57:08 squeezeplay: INFO   audio.decode - decode_start_handler:279 init decoder aac
    ...
    Jan 30 14:57:08 squeezeplay: DEBUG  audio.codec - src/decode_aac.c:473 decode_aac_start(2)

    My tests are with LMS 8.01. Have there been changes in aac/mp4 handling since then that might be influencing what the device has been told about the stream ?

    It's disappointing. I thought I had an "easy" test file, but I suspect that LMS/other factor is getting in the way. Without that out of the way, it will be difficult to draw any conclusions. My goal was to easily deliver a 'duff' aac stream. It seems that that is a failure on your set up, for some reason.

    Edit: I've just re-run the test on Logitech Media Server Version: 8.1.1 - 1610364019, the latest available.
    I get the same result as I did before. Which seems to rule out LMS as the source of the problem.
    Because when I copied the classicfm.aac file to my test system I stupidly changed the extension to m4a. Sorry about that.

    I'm running v8.2.0, git-91db8512b from yesterday on my test system.

    I've rerun the test and can confirm that I get 37 sync errors but the file plays...with a few "blips" in the audio. I also get concealing corrupted frames messages, which the stock firmware doesn't report or appear to have similiar.

    At least I can't find anything.
    Code:
    strings jive | grep -i conc
    lua_concat
    _Z22CConcealment_SetParamsP14CConcealParamsiiiii
    _Z18CConcealment_ApplyP16CConcealmentInfoP22CAacDecoderChannelInfoih
    prvBasePlusReconCoefficients
    _Z18GetConcealmentInfoi
    _Z27CConcealment_SetAttenuationP14CConcealParamsPsS1_
    _Z27CConcealment_InitCommonDataP14CConcealParams
    _Z19FreeConcealmentInfoPP16CConcealmentInfo
    auReconCoefficentsHighRate_Dec
    chexReconCh
    _Z28CConcealment_InitChannelDataP16CConcealmentInfoP14CConcealParamsi
    concatenate
    CONCAT
    __concat
    %s:%d Not enough bytes. Couldn't get error concealment.
    %s:%d can't set conceal method (%x)
    It's great to be able to confirm that the sync error code handles works.

    I've attached the full log file from the CF radio test.
    Attached Files Attached Files
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  6. #56
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    749
    Quote Originally Posted by ralphy View Post
    Because when I copied the classicfm.aac file to my test system ...
    Ha ! An 'other factor'. I might not have owned up to that.

    Quote Originally Posted by ralphy View Post
    I've rerun the test and can confirm that I get 37 sync errors but the file plays...with a few "blips" in the audio.
    There are 41 icy-metadata chunks in the file. So that might make sense. I was surprised that the stock firmware only reported one sync error, and appeared to play without blips. Perhaps the stock firmware is just "better" at gliding over corrupted incoming data and avoiding the problem in the first place.

    Quote Originally Posted by ralphy View Post
    I also get concealing corrupted frames messages, which the stock firmware doesn't report or appear to have similiar.
    This is beyond my knowledge level. I see no more than you. I used to have an object dump (from readelf, I think) of the symbols, but I threw it away. A session with ghidra might reveal more if you really wanted to know, but the thought does not really fill me with enthusiasm, and it is, perhaps, of academic interest only.

    Quote Originally Posted by ralphy View Post
    It's great to be able to confirm that the sync error code handles works.
    I think you can be very pleased with the result.

    I guess the decoder element is just seeing a lot more of the errors than it would in the 'stock' firmware. Chasing that down seems to me to be a real labour of love. Given that all incoming stream data is somewhat protected by way of being delivered by TCP, and can reasonably be assumed to come from a competent server, I think that you may have done enough.

    Unless another hiccup should arrive out of the blue ....

  7. #57
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,789
    Quote Originally Posted by mrw View Post
    This is beyond my knowledge level. I see no more than you. I used to have an object dump (from readelf, I think) of the symbols, but I threw it away. A session with ghidra might reveal more if you really wanted to know, but the thought does not really fill me with enthusiasm, and it is, perhaps, of academic interest only.

    I think you can be very pleased with the result.
    I did my fair share of looking at disassembly code with objdump -d of the official jive binary when I was building the decoder code.

    Thanks. I am happy with the results and really don't think more investigations are required. The message is only printed at the log warn level and above, so it's not displayed with the default info level.

    Quote Originally Posted by mrw View Post
    I guess the decoder element is just seeing a lot more of the errors than it would in the 'stock' firmware. Chasing that down seems to me to be a real labour of love. Given that all incoming stream data is somewhat protected by way of being delivered by TCP, and can reasonably be assumed to come from a competent server, I think that you may have done enough.

    Unless another hiccup should arrive out of the blue ....
    Agreed.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

Posting Permissions

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