Hello Mr. Arbona - I've been reading all sorts of documents with your name on them recently, including SLAA469, which I used as a guide in configuring the AIC3254 in "ASI Slave Mode" (see Figure 4, page 4). Can you sign my copy of "How digital filters affect analog audio signal levels" and "Design and Configuration Guide for the TLV320AIC3204 and TLV320AIC3254 Audio Codecs?"
Regarding my loopback issues: Yes, both digital loopback AND a physical loopback (in which a jumper is used between DOUT and DIN on the EVM) work, and the signals between the CODEC and the radio are clean. As a result of seeing this behavior on the CODEC side, I've been spending a lot of time on the radio side, but I felt a need to rule out other possibilities. The AIC3254 is something of a black box to me, and so I didn't know if, in default mode, there is any interplay between the ADC and DAC processing blocks that would somehow interfere with data looped back via the Audio Interface. Your reply indicates that this is not the case - okay, that helps me rule out that possibility.
Since this is the audio converters forum I won't go into much detail on the radio here, but I have complete control over the Blueooth module (which is, essentially, a TI part...the MSP430BT5190) via HCI commands.
Section 4.5.3 of TI document SWRS121B (Bluetooth and Dual Mode Controller) does a pretty good job of describing the radio's CODEC interface.
I've been testing the PCM interface in various modes with dummy data (including using a bread-boarded microcontroller rig to output table data to generate BCLK, WCLK, and DOUT) and, basically, what I put in is what I get out, except when CVSD compression is used. CVSD, as far as I know, is lossy and exhibits "bit jitter" when fed a constant input, and I'm seeing jitter in the least significant bits, but I don't know what is "usual, reasonable, and customary." I can also see this jitter when I power down the analog blocks of the CODEC - which results in the Audio Interface continuously outputting the last ADC value via DOUT (the jitter is seen on DIN).
Can you confirm that the CODEC output is 16-bit two's complement? The scope trace looks like this is the case, but I need new glasses.
At the moment, my situation is this:
With digital loopback I can can hear the clear tone that is injected, but via wireless loopback I hear a sound that seems to have a component that tracks the original tone (which I vary using a signal generator), but it is garbled like something heard in a bad 1950's sci-fi movie.
I will go back and work through tests using mu-law and A-law encoding to see if that makes a difference and run through any other configurations that I can think of. I may also switch to I2S to see if that makes any difference.
Please leave this thread open for a few days while I plow through this stuff and I will get back to you with the results.
Thanks for responding to my post.
Regards,
Tim
Note: the CODEC and radio interface is configured for 16 bit data with a one clock cycle fsync and a data offset of one. Only channel 1 (left) is being processed by the radios. BCLK is continuous. This is what is programmed and what is seen (though, unlike this drawing, Channel 2 is flatlined):
