16-bits low audio output

[hdl-util]

16-bits low audio output

[sameer]

Hi Jan,

That is odd, there is no audio postprocessing being done by the HDMI module. It could be monitor related, or I missed something in the HDMI spec. I will investigate on my FPGA and get back to you.

Glad it is otherwise working out.

[LMN128]

Hi, It is maybe related this issue:
in the module: audio_clock_regeneration_packet
i got this error on row 36: localparam CTS_WIDTH = $clog2(20'(CTS_IDEAL * 1.1));
error:

size casting a real expression violates IEEE 1800 LRM

I use Vivado 2019.2.1

[sameer]

The CTS should not affect this, unless you are hearing jittering in the 16-bit audio that is not in the 24-bit audio. I should have some time to look at this today evening / tomorrow.

[LMN128]

Hi, It is maybe related this issue:
in the module: audio_clock_regeneration_packet
i got this error on row 36: localparam CTS_WIDTH = $clog2(20'(CTS_IDEAL * 1.1));
error:

size casting a real expression violates IEEE 1800 LRM

I use Vivado 2019.2.1

It's "problem" of Vivado. It looks don't like real number in function $clog2, but it didn't resolve issue with low audio output.

[LMN128]

Hi Sameer, look at the picture i attached, please. It's audio output from TV. I used your example of Sawtooth wave generator. The saw tooth is damage. It looks like some samples words or bits of audio are not represented. I hope it helps you.

[sameer]

I've been checking the code dependent on audio bit width but haven't found anything yet. Logically, I think everything is fine. If there is an issue, it is either in the internal audio buffer or the on-the-fly clock regeneration. The internal audio buffer is reset every time an audio packet is sent (every ~2 samples for 48kHz) so it would happen a lot. But I think if either of these were the problem we'd also see it in the 16 bit audio waveform. Could you capture a 16-bit waveform with your oscilloscope?

When using the sawtooth wave generator, did you set the bit width to be the SAME as the audio bit width? i.e.

localparam AUDIO_BIT_WIDTH = 16;
hdmi #(.AUDIO_BIT_WIDTH(AUDIO_BIT_WIDTH)) hdmi ();
sawtooth #(.BIT_WIDTH(AUDIO_BIT_WIDTH)) sawtooth ();

and then for 24-bit

localparam AUDIO_BIT_WIDTH = 24;
hdmi #(.AUDIO_BIT_WIDTH(AUDIO_BIT_WIDTH)) hdmi ();
sawtooth #(.BIT_WIDTH(AUDIO_BIT_WIDTH)) sawtooth ();

What I've checked so far in the code:

• IEC 60958-3: bits 35 down to 32 are correct in channel status
  • 16-bit: 001 0 as expected
  • 24-bit: 101 1 as expected
• Channel status bit order correct and all parameters present
• Sample size in Audio InfoFrame set to "See stream header" (2'd0) as expected in CEA-861-D
• Sample packet header
  • 2-channel layout
  • Aligned frame counter correct
  • First frame of channel status assignment correct
• Sample subpacket
  • Sample word present assignment correct
  • Packet parity correct
  • Right/left channels in correct placement
  • User data bits set to 0 (no user data)
  • Valid bits set to 0 (always valid)
• packet_picker.sv
  • Frame counter correct
  • all ports connected to the sample packet

[sameer]

Updated plots after correcting sawtooth:
16-bit plot:

24-bit plot:
Visible approximation:

Yeah it's definitely quieter. My working theory is that even though it's been set to 16-bit audio, the HDMI sink is actually perceiving the sample as 24-bit audio. The frequency is right, but the dynamic range is MUCH lower. Have to investigate why it's ignoring the 16-bit audio setting in the channel status.

[sameer]

Graphs from my computer for 24-bit sawtooth generated with SoX looks exactly the same as the output from the FPGA:

[sameer]

After fixing the padding, 16-bit is output correctly:

Approximation looks about the same: