16-bits low audio output

[LMN128]

Hi Sameer, I have a problem with audio output. I would like to use 16 bits resolution, but it sounds with very low volume in compare 24 bit. I uses same data (i suppose proper) in follow examples:

16-bits: hdmi #(.VIDEO_ID_CODE(17), .VIDEO_REFRESH_RATE(50), .AUDIO_RATE(48000), .AUDIO_BIT_WIDTH(16)) hdmi(.clk_pixel_x10(clk_tmds), .clk_pixel(clk_pixel), .clk_audio(audio_clk), .rgb(rgb), .audio_sample_word('{{audio_l}, {audio_r}}), .tmds_p(data_p), .tmds_clock_p(clk_p), .tmds_n(data_n), .tmds_clock_n(clk_n), .cx(cx), .cy(cy));

24-bits: hdmi #(.VIDEO_ID_CODE(17), .VIDEO_REFRESH_RATE(50), .AUDIO_RATE(48000), .AUDIO_BIT_WIDTH(24)) hdmi(.clk_pixel_x10(clk_tmds), .clk_pixel(clk_pixel), .clk_audio(audio_clk), .rgb(rgb), .audio_sample_word('{{audio_l,8'b0}, {audio_r,8'b0}}), .tmds_p(data_p), .tmds_clock_p(clk_p), .tmds_n(data_n), .tmds_clock_n(clk_n), .cx(cx), .cy(cy)); 24bits sounds good, but 16bit not. Thanks for help.

[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: