philippe_44 wrote: > 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. ------------------------------------------------------------------------ benh's Profile: http://forums.slimdevices.com/member.php?userid=6732 View this thread: http://forums.slimdevices.com/showthread.php?t=114534 _______________________________________________ ripping mailing list ripping@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/ripping
