You should be seeing a 12MHz MCLK coming from the BBB when properly configured and running speaker-test.
Without this the TLV will never be able to generate BCLK and WCLK and RX/TX the audio data. -Jesse On Mon, Sep 28, 2015 at 1:20 AM, Rick Mann <[email protected]> wrote: > > > On Sep 28, 2015, at 01:03 , Jesse Cobra <[email protected]> wrote: > > > > > Ah. The DT overlay is configuring McASP for IIS, but not the TLV? > Where is the TLV's configuration set? > > > > In the TLV audio driver. The driver is setting the codec to 2 channel > TDM. Which really is the same thing as i2s which is always 2 channels > anyways. TDM can be much more channels if you want. Anyways. > > I saw in the code where it was setting it, but it's based on a "fmt" value > that gets passed in from somewhere. Anyway, you're saying it doesn't really > matter, so I'll ignore that particular discrepancy for now. > > > > I don't have a proper IIS analyzer, but I probed the pins with an > oscilloscope, and they never change state. > > > > You do not need anything special for audio data, it is pretty slow > anyways. So a few simple questions. > > > > 1. Does the default audio cape work with whatever software you are > running on your BBB? > > I don't have a working audio cape; I've never been able to buy one (no one > seems to have the Rev B in stock). I did just now try using the > BB-BONE-AUDI-02-00A0.dts overlay. I get the exact same behavior. > > > 2. Check MCLK, BLCK, WCLK and the i2s/TDM RX/TX data with your scope > with the default audio cape, what do you get? > > 3. Then with your audio cape check MCLK, BLCK, WCLK and the i2s/TDM > RX/TX data with your scope again. What is the result? > > Just DC 0V on MCLK, BCLK, WCLK, DIN, DOUT. The I2C bus definitely has > traffic. > > -- > Rick > > > > > Last I worked on a custom audio cape for BBB I started with a working > regular audio cape and went from that with a break out board: > > > > > https://dl.dropboxusercontent.com/u/82765462/LPAX/IMG_20150928_010158676.jpg > > > > -Jesse > > > > On Mon, Sep 28, 2015 at 12:18 AM, Rick Mann <[email protected]> > wrote: > > Thanks for the response, Jesse! > > > > > On Sep 27, 2015, at 23:09 , Jesse Cobra <[email protected]> wrote: > > > > > > B) the I2C commands to the CODEC set DSP mode, not IIS mode > > > > > > Because the default codec is doing 2 channel TDM, not 2 channel i2s. > > > > Ah. The DT overlay is configuring McASP for IIS, but not the TLV? Where > is the TLV's configuration set? > > > > > A) the McASP pins never do anything > > > > > You have looked at the pins on an analyzer? > > > > I don't have a proper IIS analyzer, but I probed the pins with an > oscilloscope, and they never change state. > > > > > > > > > > On Sun, Sep 27, 2015 at 10:12 PM, Rick Mann <[email protected]> > wrote: > > > I built a cape using the same codec as the BB Audio Cape Rev B > (tlv320aic3104) =, and wired it up the same way to reduce the amount of > Linux configuration I'd have to do to get it to work. I finally have it > communicating over the i2c bus, and both the codec and the alsa sound card > seem to be (mostly) properly configured in the device tree overlay ( > https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PRU.dts > ). > > > > > > But the McASP part of the interface still seems to do nothing. Looking > at the pins with an oscilloscope, nothing comes out. I *think* I'm at a > point where my ALSA configuration is wrong, but I'm not sure. > > > > > > Lending further credence to the ALSA config culprit theory is the fact > that the i2c commands to configure the codec seem to be incorrect. In > particular, when I run "speaker-test", the i2c commands that get sent to > the codec set it up for DSP mode, not IIS/I2S mode. The DT overlay calls > for IIS mode. > > > > > > Other parts of the DT overlay seem to be working very well. Linux > enables the power regulators for the CODEC via a GPIO, and takes it out of > reset via another GPIO before communicating with it. I watched the I2C > traffic with an I2C protocol analyzer, and it looks solid (you can see it > here. The first part is the cape enumeration, the codec comms start at > transaction 49: http://pastebin.com/2VFPVBbq). > > > > > > On my board, I've got the differential line out L&R going to an > on-board audio power amp. I haven't routed any of the other outputs (or > inputs) from the CODEC. > > > > > > Anyone got any insight as to why > > > > > > A) the McASP pins never do anything > > > B) the I2C commands to the CODEC set DSP mode, not IIS mode > > > > > > Thanks! > > > > > > -- > > > Rick Mann > > > [email protected] > > > > > > > > > -- > > > For more options, visit http://beagleboard.org/discuss > > > --- > > > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > -- > > > For more options, visit http://beagleboard.org/discuss > > > --- > > > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > Rick Mann > > [email protected] > > > > > > > > > -- > Rick Mann > [email protected] > > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
