Using a real (and different/simpler) audio codec on TX2

A ha! Thank you for the pointer regarding fsync-width - that was the cause of the write failure (that is, it went away when I reconfigured fsync-width to 1, and I now see data). I hadn’t noticed/paid attention to that line before (I assume I just commented it out when I copied it from some other Tegra codec file) and hadn’t realized its importance because I was thinking of that line as “LR clock” rather than fsync.

I now see reasonable-ish looking data on those lines, though I realize now it’s less reasonable than I thought when I first took these measurements.

Attachments:

  • bclk-fsync-1.jpg
  • bclk-fsync-2.jpg
  • bclk-fsync-3.jpg

These have BCLK on top, fsync/lrclk on the bottom, at various time-bases and trigger settings (triggering on bclk for the first two, on fsync for the third I think).

Note picture 2 - it shows that with fsync-width = <1>, the output fsync signal stays high for two full periods of the bclk signal. This contradicts what I expected based on the WM8731 datasheet figure 29: that in “DSP-A” mode I should see LRCLK/FSYNC high for 1 period of BCLK, followed by n bits of left data and n bits of right data, one bit per period of BCLK.

This would explain, however, why I still heard nothing aside from a few pops/clicks from probing, despite seeing what looked at first like reasonable signals on the scope.

  • bclk-data.jpg
  • data.jpg

These pictures show the data line: first triggered by the BCLK signal, and subsequently on the data line on its own. A little hard to see on the first one, but there is a trace for “data” on both high and low, and on the second it’s quite clear that data is toggling high-low at a reliable clocked timing though not in a simple fixed on-off - that is, it looks like data, I think.

I have no particular attachment to DSP-A mode: it seemed like the most flexible and usable mode between the Tegra and the codec. (The codec supports I2S mode, right and left justified mode, as well as DSP-A and DSP-B). We’re only using “simple” 16-bit 44.1k or 48k audio. The codec driver configures itself from whatever I put in the device-tree as the mode (which is why I assumed the same behavior from the Tegra side of the link, presumably), so I can change that at will, if there’s a reason to prefer another mode.

Why is it showing 2 bit clocks of fsync when fsync-width is explicitly 1? Is it adding 1 to the value somewhere?

Would I use 16 for fsync-width if using, e.g., I2S mode? or 17 since the wm8731 figure shows at least n + 1 bit clocks (actually shows 1 + n + 2 - perhaps it only pays attention to the 16 MSB? This behavior was explicitly specified for the DSP mode, which is why I picked it over I2S mode.) for the left channel? Unfortunately “fsync-width” does not seem to be a very common term on the Internet even without quotes: about half of it is about file systems, then there are a few audio codecs and other Tegra forum posts…