NaN appears when changing volume menu item

[grahamwhaley]

It has been reported, and I think I have seen, that changing the sgtl5000 headphone volume via the Volume menu item can show a 'NaN' error (Not-a-Number), which can then hang up and require a reboot.

I think this happens due to some sort of 'race'/sequence issue when first starting up with a blank eeprom. I have a feeling we then boot and load the default values into the RAM based settings, but then still try to load the volume setting from the eeprom, probably thus loading 0xffffffff into a float value, which then comes out as a NaN.

The quick fix is to do a 'factory reset' from the menu system. This then writes the default values to the eeprom, and from then on the volume value loading should work and the NaN problem 'goes away'.

The proper solution is either to:

• not load the volume value from the eeprom if the eeprom does not contain valid data (bad eeprom signature)
• potentially, write the default values to the eeprom on startup if no valid eeprom signature is found. This is a little destructive though, and may require a menu prompt to ask the user if they want the eeprom initialised, which might be a little tricky to code up.

[W7STF]

I'd have to experiment a little here, but the solution could be even more simple than the two alternatives suggested.

I presume people building this project would want to either use the line-out of the Teensy Audio Adapter Board and run that to some tiny amplification circuit to either drive a local speaker or a speaker out jack -or- possibly use the headphones.

If the former, the HdVol parameter setting doesn't matter because it doesn't affect line out from the adapter board. In that case there is no need for persistence for that value.

If the latter, I don't see a real inconvenience by always defaulting the Headphone Volume to 0.0 on controller boot.