Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 28
  1. #11
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    7,237
    Quote Originally Posted by benh View Post
    Fair question.

    My first answer would be that I didn't see any way to do that with the Polyvection firmware. Not clear that that option is exposed, or at least I haven't heard of how.

    My second answer would be that I kind of like the idea of addressing this issue centrally on the LMS rather than having to change playable format on what will likely be multiple esp32-based players.

    My third answer would be because I'm interested not only in a solution to my issue, but in understanding the system overall. So this is now ALSO about understanding how custom-convert.conf and convert.conf work.
    OK but you seem to have loaded the SqueezeESP32 firmware based on other posts.

    Sent from my Pixel 3a using Tapatalk

  2. #12
    Senior Member
    Join Date
    Aug 2006
    Location
    Cleveland, Ohio
    Posts
    130
    Quote Originally Posted by slartibartfast View Post
    OK but you seem to have loaded the SqueezeESP32 firmware based on other posts.

    Sent from my Pixel 3a using Tapatalk
    That is true. However, I started down this rabbit hole before I did that, so I'm still trying to understand how transcoding configuration works, because I clearly do not, and I want to know.

    I like music. I like learning things. Here, I am doing both, or at least trying.

  3. #13
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    7,237
    Quote Originally Posted by benh View Post
    That is true. However, I started down this rabbit hole before I did that, so I'm still trying to understand how transcoding configuration works, because I clearly do not, and I want to know.

    I like music. I like learning things. Here, I am doing both, or at least trying.
    Good luck, at least you know you have a fall back

    Sent from my Pixel 3a using Tapatalk

  4. #14
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,285
    Quote Originally Posted by benh View Post
    I think I'm confused.

    What I think I heard you say earlier is that if a player asserts that it supports, say, native ALAC decoding, LMS will find the alc alc convert.conf rule, stop there, do nothing since nothing is what is called for, and send ALAC straight to the player.

    I want to change the behavior for a specific esp32 player that asserts that it supports native ALAC decoding. Instead, I want to transcode ALAC to FLAC before sending it to that player, and that player only, no matter what the player says it can handle. I thought that I could create a custom-convert.conf rule for that player that tells it to transcode ALAC to FLAC, hence the rule I reference above.
    AFAIK unless you disable alac native globally, it's difficult. I'll try to explain a bit how it works.

    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.

    So it the rule matcher will look for and "alc xxx" rule where xxx is in the list of codecs, using the order sent by player (unless the "prefer native codec" option is checked, in which case the rule matcher will *always* start with the source code).

    So it starts with any rule "alc alc" and it will start first with custom-convert rules and rules that specify a player model or mac address, that's true. But in your case, it finds and "alc alc" rule (which is the identity rule) that matches and because that rule is not disabled, this is the end of the search. The rule also have criteria if you want to seek, resample, or that apply to different source (Remote, stdIn, File), but that's irrelevant in your case.

    So, if you want a different outcome, you can use one of these options

    - disable alc native support for all players
    - remove alc from codecs supported by DAC32
    - change order of codecs reported by DAC32 (needs recompile)
    - build an "alc alc" rule for your DAC32 (specifiy MAC) that forces resample to 48kHz (e.g.)

    But simply doing an 'alc flc' rule will not do anything because the 'alc alc' general rule will work and prevail
    Last edited by philippe_44; 2021-05-07 at 13:36.
    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

  5. #15
    Senior Member
    Join Date
    Aug 2006
    Location
    Cleveland, Ohio
    Posts
    130
    Quote Originally Posted by philippe_44 View Post
    AFAIK unless you disable alac native globally, it's difficult. I'll try to explain a bit how it works.

    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.

    So it the rule matcher will look for and "alc xxx" rule where xxx is in the list of codecs, using the order sent by player (unless the "prefer native codec" option is checked, in which case the rule matcher will *always* start with the source code).

    So it starts with any rule "alc alc" and it will start first with custom-convert rules and rules that specify a player model or mac address, that's true. But in your case, it finds and "alc alc" rule (which is the identity rule) that matches and because that rule is not disabled, this is the end of the search. The rule also have criteria if you want to seek, resample, or that apply to different source (Remote, stdIn, File), but that's irrelevant in your case.

    So, if you want a different outcome, you can use one of these options

    - disable alc native support for all players
    - remove alc from codecs supported by DAC32
    - change order of codecs reported by DAC32 (needs recompile)
    - build an "alc alc" rule for your DAC32 (specifiy MAC) that forces resample to 48kHz (e.g.)

    But simply doing an 'alc flc' rule will not do anything because the 'alc alc' general rule will work and prevail
    Thank you. I think I understand more now.

    To restate what you said, the order of operations is to match rules based on:

    1. source codec plus player supported codecs, in the order given by the player
    2. It finds first match of source and supported codec and executes, rather than finding most specific match, with the following caveats:
    3. If there is more than one rule matching the source codec plus supported codec, the rule matcher will then inspect player model and MAC address values
    4. If "Prefer native format (decoding on the player) whenever possible" is enabled, it will ignore all of the above and just send source codec natively, assuming the source codec matches any supported player codec. If there is not a native match, it will begin to inspect the rules.

    In my use case, if I create an alc alc rule in custom-convert.conf, it will match that rule first, and stop. It didn't match the alc flc rule because it was looking for an alc alc rule due to alc being the native codec, and alc coming before flc in the supported codec assertion from the player.

    I have tested and confirmed that an alc alc rule in custom-convert.conf matches. Haven't figured out the syntax to resample alc yet, as per your suggestion above.

    So, I think that I could disable native alc alc support globally, write a rule to transcode alc to flc for the DAC32, and then write another rule that matches alc alc as a fall through for every other player. The net effect would be to support native alc codec everywhere but the DAC32. Let me test that...

    Hm. I got the first part of that to work, but now ALL alc is being transcoded to flc. Have to work on that a bit more.

    Again, very helpful. Thanks.

  6. #16
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    7,237
    Quote Originally Posted by benh View Post
    Thank you. I think I understand more now.

    To restate what you said, the order of operations is to match rules based on:

    1. source codec plus player supported codecs, in the order given by the player
    2. It finds first match of source and supported codec and executes, rather than finding most specific match, with the following caveats:
    3. If there is more than one rule matching the source codec plus supported codec, the rule matcher will then inspect player model and MAC address values
    4. If "Prefer native format (decoding on the player) whenever possible" is enabled, it will ignore all of the above and just send source codec natively, assuming the source codec matches any supported player codec. If there is not a native match, it will begin to inspect the rules.

    In my use case, if I create an alc alc rule in custom-convert.conf, it will match that rule first, and stop. It didn't match the alc flc rule because it was looking for an alc alc rule due to alc being the native codec, and alc coming before flc in the supported codec assertion from the player.

    I have tested and confirmed that an alc alc rule in custom-convert.conf matches. Haven't figured out the syntax to resample alc yet, as per your suggestion above.

    So, I think that I could disable native alc alc support globally, write a rule to transcode alc to flc for the DAC32, and then write another rule that matches alc alc as a fall through for every other player. The net effect would be to support native alc codec everywhere but the DAC32. Let me test that...

    Hm. I got the first part of that to work, but now ALL alc is being transcoded to flc. Have to work on that a bit more.

    Again, very helpful. Thanks.
    If ALAC to FLAC transcoding is not CPU intensive then why not just do it globally?

    Sent from my Pixel 3a using Tapatalk

  7. #17
    Senior Member
    Join Date
    Aug 2006
    Location
    Cleveland, Ohio
    Posts
    130
    Quote Originally Posted by slartibartfast View Post
    If ALAC to FLAC transcoding is not CPU intensive then why not just do it globally?

    Sent from my Pixel 3a using Tapatalk
    Because I don't want to.

  8. #18
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,631
    Quote Originally Posted by benh View Post
    1. source codec plus player supported codecs, in the order given by the player
    IIRC Order of codecs in conf or player response is not significant.

    For a given audio source format

    LMS will chose native decode first (i.e no transcoding).

    Then lossless compressed transcode (i.e. Flac) - transcode to flac will be used if audio code nbot suport or audio format needs to be changed (e.g. bitrate resampling).

    Then I think lossless uncompressed (*i.e. PCM)

    Finally transcode to MP3 as expected to support Mp3.

  9. #19
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,285

    Understanding custom-convert.conf

    Quote Originally Posted by bpa View Post
    IIRC Order of codecs in conf or player response is not significant.

    For a given audio source format

    LMS will chose native decode first (i.e no transcoding).

    Then lossless compressed transcode (i.e. Flac) - transcode to flac will be used if audio code nbot suport or audio format needs to be changed (e.g. bitrate resampling).

    Then I think lossless uncompressed (*i.e. PCM)

    Finally transcode to MP3 as expected to support Mp3.
    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.

    This is, in TranscodingHelper.pm, where it happens

    Code:
    	# Build the full list of possible profiles
    	my @profiles = $forceTranscode ? ("$type-$type-transcode-*") : ();
    
    	foreach my $checkFormat (@supportedformats) {
    
    		if ( $clientid && $player ) {
    			push @profiles, (
    				"$type-$checkFormat-$player-$clientid",
    				"$type-$checkFormat-*-$clientid",
    				"$type-$checkFormat-$player-*"
    			);
    		}
    
    		push @profiles, "$type-$checkFormat-*-*";
    
    		if ($type eq $checkFormat && enabledFormat("$type-$checkFormat-*-*") && !$forceTranscode) {
    			push @profiles, "$type-$checkFormat-transcode-*";
    		}
    	}
    
    	# Test each profile in turn
    	PROFILE: foreach (@profiles) {
    		my $instance = 0;
    	INSTANCE:
    		my $profile = $instance ? "$_-$instance" : $_;
    		$instance++;
    		next PROFILE unless exists $commandTable{$profile};
    The supportedFormat is built by the following

    Code:
    sub supportedFormats {
    	my $client = shift;
    	
    	my @supportedformats = ();
    	my %formatcounter    = ();
    
    	my @playergroup = $client->syncGroupActiveMembers();
    
    	foreach my $everyclient (@playergroup) {
    		foreach my $supported ($everyclient->formats()) {
    			$formatcounter{$supported}++;
    		}
    	}
    	
    	foreach my $testformat ($client->formats()) {
    		if (($formatcounter{$testformat} || 0) == @playergroup) {
    			push @supportedformats, $testformat;
    		}
    	}
    	
    	return @supportedformats;
    }
    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
    Last edited by philippe_44; 2021-05-07 at 16:04.
    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

  10. #20
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,285
    Quote Originally Posted by benh View Post
    Thank you. I think I understand more now.

    To restate what you said, the order of operations is to match rules based on:

    1. source codec plus player supported codecs, in the order given by the player
    2. It finds first match of source and supported codec and executes, rather than finding most specific match, with the following caveats:
    3. If there is more than one rule matching the source codec plus supported codec, the rule matcher will then inspect player model and MAC address values
    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)
    4. If "Prefer native format (decoding on the player) whenever possible" is enabled, it will ignore all of the above and just send source codec natively, assuming the source codec matches any supported player codec. If there is not a native match, it will begin to inspect the rules.
    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)
    Last edited by philippe_44; 2021-05-07 at 17:40.
    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

Posting Permissions

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