Mike Watkins <mike.watkins@...>
Is there a version number we should be looking for where the problem exists (or ceases to exist)? Will be very helpful when supporting others. See below, there may be some specific "parameter" conflict, or who knows even a bug in parameter processing, that could have been causing that. All software has bugs.
One other note - the DRAWS lines need to be inserted in the config.txt before the [pi4] and [all] stuff in the config file.
Not quite - as long as the relevant configuration information is after [all] it will be read, regardless of the Pi model number. But sure, if you included it before the config.txt file format Pi model tag, you can be sure it'll be read. No harm.
Out of curiosity and in an attempt to see what's folklore or not, I've dug into the config.txt documentation out of interest; rather wish I didn't - there's time I won't get back LOL - and discovered a couple things that may not be important but had me curious. Forgive me if I'm covering ground others have already.
Regarding dt_overlay=, from the documentation (https://www.raspberrypi.org/documentation/configuration/device-tree.md) it would appear that dt_overlay= is used to reset "parameters" from conflicting with another overlay that happens to use the same parameter names.
Since there's only one parameter - alsaname - maybe there's a conflict there but doesn't seem likely... but who knows. Commenting out the on board audio interface removes the other alsa device, and that could be why it's helpful for some cases. I used to think Raspberry Pi's were quite identical until I discovered one of my RPi 3's no longer saw its Wireless adapter despite being configured identically to every other one.
Regarding dt_overlay parameter convention:
Maybe I'm missing something but the line:
Seems to be mis-formatted, unless commas are happily being interpreted per the documentation (below). A colon between the driver and first parameter appears to be the documented format. Does it matter? Maybe. Not in my case though, both work. Still, it's probably best that the documented approach be used in case that happy accident, if that's what it is, ends one day.
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: happytimeurdc [happytimeurdc], device 0: bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0 
Subdevice #0: subdevice #0
For the curious, see following.
If you have an overlay that defines some parameters, they can be specified either on subsequent lines like this:
or appended to the overlay line like this:
Note here the use of a colon (
Overlay parameters are only in scope until the next overlay is loaded. In the event of a parameter with the same name being exported by both the overlay and the base, the parameter in the overlay takes precedence; for clarity, it's recommended that you avoid doing this. To expose the parameter exported by the base DTB instead, end the current overlay scope using: