Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

test new audio codec revision #12

Open
1 of 7 tasks
EvanKrall opened this issue Jul 7, 2021 · 11 comments
Open
1 of 7 tasks

test new audio codec revision #12

EvanKrall opened this issue Jul 7, 2021 · 11 comments

Comments

@EvanKrall
Copy link
Owner

EvanKrall commented Jul 7, 2021 •
edited
Loading

Refer back to my project log about testing the last codec revision.

  • update dts file
  • Bodge line out lines to amplifiers
  • write i2c script
  • test headphone detection
  • test audio playback through headphones
  • test audio playback through speakers
  • Check that codec gpio pin is toggling audio switch
@EvanKrall
Copy link
Owner Author

Some fun with the dtoverlay: https://www.raspberrypi.org/forums/viewtopic.php?p=1914969#p1914969

Today's task is to figure out why I'm not getting audio output. I can see i2s data being sent by the pi, and the headphone pins jump to some nonzero DC offset (which is odd... the whole point of switching to this codec was to get ground-centered headphone output.)

I think my plan here is to look at the datasheet, figure out what registers need to be set to what value to get output on HPL/HPR or LOL/LOR, and then see which settings in alsamixer affect those registers.

@EvanKrall
Copy link
Owner Author

I think I forgot to connect ring2/GND_sense to ground.

@EvanKrall
Copy link
Owner Author

I should rearrange the decoupling caps to put a 10uF near pin 39 (DVDD_CP).

@EvanKrall
Copy link
Owner Author

oh, boo, the tlv320aic32x4 driver doesn't seem to know how to configure the charge pump in the 3206.

@EvanKrall
Copy link
Owner Author

boo, it also doesn't seem to know how to configure the headset detection feature, page 0 reg 67. (2.11.1 Headset Detection in https://www.ti.com/lit/an/slaa463b/slaa463b.pdf)

@EvanKrall
Copy link
Owner Author

Various registers to check:

  • page 0 reg 4: xxxx0x11: MCLK or BCLK is PLL input; PLL clock is CODEC_CLKIN.
  • page 0 reg 5: 1xxxxxxx: PLL is powered up
  • page 0 reg 0x1b: 00xx00xx: i2s interface, bclk and wclk are inputs.
  • page 0 reg 0x1d: xxx0xxxx: 0: No Loopback (as opposed to 1: Stereo ADC output is routed to Stereo DAC input)
  • page 0 reg 0x25: 110x110x or 101x101x: LDAC/RDAC powered up and either LOL/LOR or HPL/HPR powered up.
  • page 0 reg 0x2a: 00000000
  • page 0 reg 0x2c: 000x00xx: no over-current problems. (Ignore headset insertion)
  • page 0 reg 0x3f: 110101xx: DAC channels powered up, not disabled
  • page 0 reg 0x40: x00000xx: auto mute disabled; neither channel muted
  • page 0 reg 0x41: 0xxxxxxx: gain >= 0db (or at least not super low)
  • page 0 reg 0x42: 0xxxxxxx: gain >= 0db (or at least not super low)
  • page 1 reg 0x01: xxxxxx10 for charge pump (possibly not required)
  • page 1 reg 0x02: xxxx11xx: analog blocks enabled; headphone driver powered up
  • page 1 reg 0x09: xx110000 or xx001100: HPL/HPR are powered up and LOL/LOR/MAL/MAR are powered down, or LOL/LOR are powered up and HPL/HPR/MAL/MAR are powered down.
  • page 1 reg 0x0c: xxxx1000: only left channel DAC is routed to HPL.
  • page 1 reg 0x0d: xxx0100x: only right channel DAC is routed to HPR.
  • page 1 reg 0x0e: xxx01x00: only left channel DAC is routed to LOL.
  • page 1 reg 0x0f: xxxx1x0x: only right channel DAC is routed to LOR.
  • page 1 reg 0x10: x0xxxxxx: HPL not muted.
  • page 1 reg 0x11: x0xxxxxx: HPR not muted
  • page 1 reg 0x12: x0xxxxxx: LOL not muted
  • page 1 reg 0x13: x0xxxxxx: LOR not muted
  • page 1 reg 0x16: x1110010: IN1L to HPL muted
  • page 1 reg 0x17: x1110010: IN1R to HPR muted
  • page 1 reg 0x18: xx101000 (MAL muted)
  • page 1 reg 0x19: xx101000 (MAR muted)
  • page 1 reg 0x3f: 11111111
  • page 1 reg 0x7d: xxx1xxxx: enable ground-centered mode

Experiments:

  • page 0 reg 0x1d: set d5 high: Audio Data in is routed to Audio Data out. See if it sends us valid data back.
  • page 0 reg 0x47: generate a beep on left channel
  • Maybe try configuring MFP5 or MISO or DOUT to pass CLKOUT to see if we have a valid clock internally?

@EvanKrall
Copy link
Owner Author

I finally got audio by setting page 0 reg 0x04 to 0x01 (BCLK is CODEC_CLKIN), among some other settings.

By setting DOUT to CLKOUT, and CDIV_CLKIN to PLL_CLK, I could see that the PLL was not generating a clock.

@EvanKrall
Copy link
Owner Author

with this script, I can get a steady 4xBCLK out of the PLL:

./tlv320aic32x6_set_reg.sh 0 0x04 0x07   # D6=0 low PLL clock range (?); D3..2 = 01 BCLK pin is input to PLL; D1..0 = 11: PLL clock is CODEC_CLKIN

# Page 77 in slaa463b.pdf
# PLL_CLK = (PLL_CLKIN * R * J.D) / P

./tlv320aic32x6_set_reg.sh 0 0x05 0x91  # PLL enabled (D7), configure P (D6..4) = 1 and R (D3..0) = 1 - page 96
./tlv320aic32x6_set_reg.sh 0 0x06 0x04  # PLL parameter J = 4
./tlv320aic32x6_set_reg.sh 0 0x07 0x00; ./tlv320aic32x6_set_reg.sh 0 0x08 0x00  # PLL parameter D = 0

# DOUT is CLKOUT
./tlv320aic32x6_set_reg.sh 0 0x35 0x16
# CLKOUT is PLL
./tlv320aic32x6_set_reg.sh 0 0x19 0x03
# CLKOUT powered up, divider = 1
./tlv320aic32x6_set_reg.sh 0 0x1A 0x81

There's a lot of white noise on the output, but it does work.

@EvanKrall
Copy link
Owner Author

I think I left the headphone connector's ground pin (GND_SENSE) ungrounded. I wonder if this is why it seems to be also swinging around with the output signal, and things seem to get louder when one channel is muted.

@EvanKrall
Copy link
Owner Author

Played around with enabling the charge pump tonight:


#####################################################
# Enabling the charge pump and ground-centered mode #
#####################################################

# To turn on the charge pump circuit, program Page 1, Register 1, D1:0 to “10”. When the charge pump
# circuit is disabled, VNEG acts as a ground terminal, allowing unipolar configuration of the headphone
# amps. By default, the charge pump is disabled.
./tlv320aic32x6_set_reg.sh 1 0x01 0x02  # D1-D0 = 10: Power Up Charge Pump with Internal Oscillator Clock (nom. 8MHz) 

# The switching rate of the charge pump can be controlled
# by Page 1, Register 124, D3:0. Because the charge pump can demand significant inrush currents from the
# supply, it is important to have a capacitor connected in close proximity to the DVdd_CP and DVss_CP
# pins of the device. At 500kHz clock rate this requires approximately a 10μF capacitor. The ESR and ESL
# of the capacitor must be low to allow fast switching currents.
./tlv320aic32x6_set_reg.sh 1 0x7c 0x00  # Charge Pump Clock Divide Control = 64

# The ground-centered mode of operation is enabled by configuring Page 1, Reg 125, D4 after enabling the
# charge-pump.
./tlv320aic32x6_set_reg.sh 1 0x7d 0x13  # Enable Ground Centered Mode for Headphone Drivers; Output Power Rating is 100%; DC Offset Correction for all possible signal routings for HPL and HPR

I'm seeing significant droop on AVDD and DVDD_CP when audio levels get high; I may need to bump the size of the capacitors. In particular, slaa463b says I should have a 10uF cap on DVDD_CP, but I have 0.1uF.

Earlier in the day (when I was not using ground-centered mode), I had compared left and right channels against each other with an XY chart; this showed significant correlation between the two when playing silence. (With an interesting banding pattern which I think is due to dithering applied by the DAC.) I should do this again in ground-centered mode.

I should also try to measure the droop on the various Vcc pins.

@EvanKrall
Copy link
Owner Author

By playing some white noise and looking at the FFT with my oscilloscope, it appears that the frequency response of the output drops off significantly from about 2.4kHz to 2.7kHz. I think I need to take a look at the various user-defined filters (slaa463b, page 44 and onwards).

I'm also still getting a lot of broad-spectrum noise mixed with my output signal. I'd like to get to the bottom of that. Based on how it looks on my scope (quantized), I think it may be added by codec as dithering, to reduce quantization error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@EvanKrall