The audio clock design has multiple problems. First, it is neigh impossible to generate a 32K or a 44K clock. None of the PLLs would go this low. The design in the sample project uses a clock divider made of async logic, which is considered a no-no (and in fact generates justified warnings on Vivado) due to hazards. A flipflop based divider would probably be somewhat better, but not to the point where it would be considered safe.

This problem is than cancelled out by the fact that what the design then does with that signal is then shift it back into the pixel clock domain. Unsafely.

A much better design would have been to accept the audio samples on the pixel clock domain, and have an output "audio_ack" signal that says "I just grabbed a sample", so that the feeding logic can advance to the next sample in sync with the HDMI. This would solve both problems and is a much more robust design.