Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28
  1. #21
    Senior Member
    Join Date
    Jul 2008
    Posts
    195
    This is interesting reading!

  2. #22
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,541
    Quote Originally Posted by philippe_44 View Post
    The order is significant, this is why I added the option « preferred native ». The rule checker checks rules by looking for a match starting with first codec in the list and so on

    LMS is ignorant of type of codecs at that level. All what matters in the rule checker is the first match that fulfills all the requirements. It can be or not an identity rule, it does not matter.
    .
    .
    .
    Which makes an array of all commonly supported codecs when there is a sync group, otherwise it's the list of codecs returned in the HELO message
    Thanks - I had missed out that the order became significant.

    For squeezelite the order of codecs is changed by using the "-c" option and then including all the codecs required in the desired order.

    AFAICT older versions (e.g. 1.8.*) of squeezelite do not keep the order as specified in the "-c" option. So users who wish to use a specific codec order should use an up to date to version of squeezelite. Not sure how up to date is the Debian squeezelite package.

  3. #23
    Senior Member
    Join Date
    Aug 2006
    Location
    Cleveland, Ohio
    Posts
    130
    Quote Originally Posted by philippe_44 View Post
    Not exactly, the rule matcher builds an array of acceptable matches in the following text format "$type-$checkFormat-$player-$clientid", where $type is the source codec and $checkformat is each codec of the HELO message and $player is player model and $clientid is the MAC. In other words, if source is 'alc' and codecs in HELO are 'mp3,flc,alc' (note the order) and player is 'squeezelite' and mac is '00:01:02:03:04:05', it will do an array with
    Code:
    alc-mp3-squeezelite-00:01:02:03:04:05
    alc-mp3-*-00:01:02:03:04:05
    alc-mp3-squeezelite-*
    alc-mp3-transcode-* (if transcode is enabled)
    alc-mp3-*-*
    alc-flc-squeezelite-00:01:02:03:04:05
    alc-flc-*-00:01:02:03:04:05
    alc-flc-squeezelite-*
    alc-flc-*-*
    alc-flc-transcode-* (if transcode is enabled)
    alc-alc-squeezelite-00:01:02:03:04:05
    alc-alc-*-00:01:02:03:04:05
    alc-alc-squeezelite-*
    alc-alc-*-*
    alc-alc-transcode-* (if transcode is enabled)
    There is a detail with forcing transcode that can be placed it at the top. But then that array is looked in order and compared to "existing rules" which are made from the combination of custom-convert.conf and convert.conf (and a few others, but let's put that aside). These "existing rules" are a hash whose keys are, for example, "alc-flc-squeezelite-*" - these keys are the first line of every rule you wrote in the *.conf files, just with a '-' between each token. It's normally built once when LMS starts.

    So you can see that if the key exists, then the rule matches can now look at the rule details and see if it works with all the desired perks (for example the rule might only work for files, or the rule can not allow goodies likes seeking). If there is no key in the hash, we move to the next element in the array, if there is a key and all perks are satisfied, this is our rule!

    Now, custom-convert takes precedence because when it populates the "existing rules" hash, it overwrites any existing key/rule that other .conf files have set before (I've modified that a bit to allow multiple rules for a given combination, but that's beyond the scope of this discussion)

    No. When "prefer native...." all what is done is taking the list of codecs and place the source codec at the top (if it exists of course)!. As a result, the array of possibilities will start with the source codec, so your array becomes
    Code:
    alc-alc-squeezelite-00:01:02:03:04:05
    alc-alc-*-00:01:02:03:04:05
    alc-alc-squeezelite-*
    alc-alc-*-*
    alc-alc-transcode-* (if transcode is enabled)
    alc-mp3-squeezelite-00:01:02:03:04:05
    alc-mp3-*-00:01:02:03:04:05
    alc-mp3-squeezelite-*
    alc-mp3-transcode-* (if transcode is enabled)
    alc-mp3-*-*
    alc-flc-squeezelite-00:01:02:03:04:05
    alc-flc-*-00:01:02:03:04:05
    alc-flc-squeezelite-*
    alc-flc-*-*
    alc-flc-transcode-* (if transcode is enabled)
    This is fantastic. Thanks. Your explanation makes the process very clear. Understanding that the convert.conf entries are really hash key/value pairs and how they are ordered was, for me, the critical bit. Knowing that the order is defined by the sequence of codecs as returned by the player was also, er, key.

    My initial roadblock was thinking of this as more like a firewall ruleset when it doesn't act that way at all.

  4. #24
    Very interesting, thanks for all the explanations.
    I run a custom-convert.conf for room equalization, and full understanding of the inner workings of LMS is always interesting.

    If I may ask a question (slightly OT, apologies):

    Quote Originally Posted by philippe_44 View Post
    LMS sees that source is "alc". It then reads the list of codecs the player is supporting which is "alc,aac,ogg,ops,ogf,flc,aif,pcm,mp3" for squeezelite-esp32 (unless PolyVection has changed it) and then starts rules matching.
    What was the rationale of choosing such order? I would expect that in a modern device, all lossless compressed formats would come first, then lossless uncompressed, and finally lossy formats.

  5. #25
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,541
    Quote Originally Posted by scala View Post
    Very interesting, thanks for all the explanations.
    I run a custom-convert.conf for room equalization, and full understanding of the inner workings of LMS is always interesting.

    If I may ask a question (slightly OT, apologies):



    What was the rationale of choosing such order? I would expect that in a modern device, all lossless compressed formats would come first, then lossless uncompressed, and finally lossy formats.
    Philippe will probably give a better answer. But as I see it, normally there are rules first for native (alc-alc) and then transcoding flac, pcm and MP3.

    alc,aac,ogg,ops,ogf,flc,aif,pcm,mp3

    So if source is alc and alc native is available - native alc will be chosen. If native is not available then transcoding to flc will be next and so on for pcm and MP3.
    So if source is flac and flac native is available - native flac will be chosen. If native flc is not available then transcoding to pcm and then MP3.

  6. #26
    I see, considering the standard LMS transcoding rules it makes sense. Thanks.

  7. #27
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,189
    Quote Originally Posted by scala View Post
    I see, considering the standard LMS transcoding rules it makes sense. Thanks.
    Also, the reason my I added that option to try the source format first was because the order can never be always right. I had that issue with my bridges, long before I was capable to understand the way rules matcher works.

    For example, if you have « pcm,flc » then it’s good because when playing pcm it will go unmodified but if you send a flac file, as there is a simple rule « flc pcm », then it will be converted to pcm. If you chose the other order reform codecs, then you have the reverse problem.

    I thought initially there was a magic order and that LMS was preferring lossless but there is no such thing. There is only the codec order, the rules (and their order) and the options (can resample, can use stdin, can seek).
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  8. #28
    In other words (if I understood correctly) there is no "perfect" rule for transcoding, just a reasonably (very) good compromise. As usual, in fact.

Posting Permissions

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