[alsa-devel] Noise in tlv320aic3104-based audio system

[Benoît Thébaudeau]

On Fri, Oct 30, 2015 at 1:18 AM, Benoît Thébaudeau
<benoit.thebaudeau.dev at gmail.com> wrote:
> Dear Rick Mann,
>
> On Fri, Oct 30, 2015 at 12:40 AM, Rick Mann <rmann at latencyzero.com> wrote:
>> Thanks, Caleb, answers below:
>>
>>> On Oct 29, 2015, at 16:08 , Caleb Crome <caleb at crome.org> wrote:
>>>
>>> On Thu, Oct 29, 2015 at 2:56 PM, Rick Mann <rmann at latencyzero.com> wrote:
>>>>
>>>>> On Oct 29, 2015, at 14:21 , Benoît Thébaudeau <benoit.thebaudeau.dev at gmail.com> wrote:
>>>>>
>>>>> Dear Rick Mann,
>>>>>
>>>>> On Thu, Oct 29, 2015 at 8:59 AM, Rick Mann <rmann at latencyzero.com> wrote:
>>>>>> I have a custom cape on a Beaglebone Black that uses a tlv320aic3104, connected to a tpa3140d2 audio power amp. I currently manually control the /shudown pins on the two ICs, and just turn them on before doing anything else.
>>>>>>
>>>>>> The system works. But I notice that when I open the output device for writing (via libao), I immediately hear hiss, even before I send any samples to the device. After I close the libao audio device, a few seconds later Linux sends some i2c commands to the tlv320 and it's once again silent.
>>>>>>
>>>>>> The perceived amplitude of this hiss does not seem to be affected by "amixer set PCM <0 - 127>" calls.
>>>>>>
>>>>>> Does anyone have any idea where this noise might be coming from? Is it just thermal or other noise in the routing of audio within the tlv320? Is there some configuration or routing I might be able to change to avoid it? Did I screw up somewhere in my circuit design or layout that only manifests when linux configures the chip for operation?
>>>>>>
>>>>>> Any ideas are appreciated. Thanks.
>>>>
>>>> Thanks Benoit,
>>>>
>>>>> It could be many things, but here are a few ideas:
>>>>> - Make sure that you have followed carefully the data sheets (CODEC +
>>>>> amp) regarding the hardware schematic and layout. IIRC, the TLV has a
>>>>> thermal pad that should be grounded.
>>>>
>>>>> - Make sure that the audio power supplies are clean enough. You can
>>>>> derive them from more general-purpose power supplies if filtering is
>>>>> added. The PCB layout must define a clear audio area, ideally with a
>>>>> plane for the audio power supply on one of the layers. Even better,
>>>>> you can use dedicated low-noise power supplies.
>>>>
>>>> I tried to follow the layout guidelines exactly. It's a four-layer board with a solid ground plane under the analog sections, and it's isolated from the digital ground. Here's a shot of the board:
>>>>
>>>>        https://camo.githubusercontent.com/833bde12303c9607259e486b8b301503dcc69a94/68747470733a2f2f6661726d312e737461746963666c69636b722e636f6d2f3637382f32313431393631383237305f303233336331643566355f682e6a7067
>>>
>>> FYI, Henry Ott's great book (Electromagnetic Compatibility
>>> Engineering) strongly discourages the use of separate digital and
>>> analog ground planes.  On modern mixed signal boards, they don't make
>>> a lot of sense, and IIRC he says something to the effect of, "don't
>>> use a separate ground plane even though manufacturers inexplicably
>>> still recommend them". :-)    They key is physical separation of
>>> analog and digital signals, not separate ground planes.
>>
>> Good to know; I'll get the book. Odd that manufacturers continue to recommend this. In any case, I do believe my digital and analog signals are separate.
>>
>> One thing I didn't do was pour ground flood on the top layer between traces.
>>
>>> That said, which GND plane is your QFN pad connected to?  It looks to
>>> be the analog plane, and where are the two planes connected together
>>> (should be literally under the codec).
>>
>> It's connected to the analog ground. The digital and analog grounds are connected right under the large trace that brings the 14 V to the power amp. It's the short, fat blue trace on top of the fat purple trace. Just below the CODEC.
>>
>>> If the two planes are connected under the codec, then the layout looks
>>> okay.  If they are not connected under the codec, or at least close,
>>> and if you can dig out your ground planes, try soldering a solder
>>> braid between them, jumpering from your QFM pad vias over to your
>>> digital ground with low impedance solder braid (solder wick).
>>
>> I won't be able to do this.
>>
>>> What are L2 and L3 for?  LC filters on power supplies can get nasty if
>>> you're not careful.  In fact, they're almost always nasty on power
>>> supplies because they cause a strong resonance (there are exceptions
>>> of course...).  You can try just shorting them out.
>>>
>>> The vias from your bypass caps (C16, C17) to GND looks pretty high
>>> impedance, using only a single shared via.   Ideally, you should use 2
>>> vias per cap, and thick wires.
>>
>> Ah, good to know. I can make that change on a new rev of the board (I want to add test points, and bring out some of the additional inputs and outputs of the CODEC to make this board a little more generally useful).
>>
>>> But.. even with all those comments, nothing looks horribly wrong.  I
>>> can't tell from the screenshot -- are you 100% sure that every GND on
>>> the analog plane connects to the analog plane?
>>
>> Pretty sure. You can see the individual layers and board photos here: https://www.flickr.com/photos/jetforme/albums/72157658301949316, but I just looked at the layer in my PCB software again, and I don't think I missed any.
>
> I agree with Caleb. There is no obvious hardware issue according to
> what you say. The sound should be clean.
>
>>>> Red is top layer, light blue is the ground plane (second layer), purple is the third layer, and dark blue is the bottom layer.
>>>>
>>>> There are dedicated LDOs for everything, fed from a main 5 V DC-DC converter. The main amplifier power comes from the main power input, which in this instance is a linear constant-current bench supply. It's also heavily LC-filtered, as per the data sheet guidelines.
>>>
>>> Where does it say to LC filter the power supply in the datasheet -- I
>>> didn't see that.
>>
>> I followed the reference board (http://www.ti.com/tool/tpa3140d2pwpevm) design (sorry, conflated the two). The EVM's datasheet has schematics.
>>
>>>> The biggest reason I'm fairly sure it's not the board layout is that the noise is dramatically reduced when the ALSA audio device is not open, even though the ICs are powered and enabled.
>>>
>>> Yeah, but the DAC isn't enabled I believe -- it often gets shut off
>>> even though the chip is enabled.
>>
>> Agreed. Kinda sad the DAC generates so much noise even when receiving no samples.
>>
>>>>
>>>>> - Make sure that all unused CODEC pins are configured as not connected in ALSA.
>>>>> - Make sure that all unused audio paths are disabled. You can use
>>>>> `alsactl store` to dump and check everything.
>>>>
>>>> I'll see what I can see. On the TI e2e forum, it was suggested to ensure the DAC audio path goes through the output mixer, rather than bypassing it, because it acts as a noise filter (diagram in the post).
>>>>
>>>>        http://e2e.ti.com/support/data_converters/audio_converters/f/64/p/465738/1671425#1671425
>>>>
>>>> I don't know what the actual routing is, as I don't understand the ALSA configuration. Here's my asound.state after executing aslactl store:
>>>>
>>>>        https://gist.github.com/JetForMe/5d01938dcd952557d2af
>>>>
>>>> Here's my DTS:
>>>>
>>>>        https://github.com/JetForMe/podtique/blob/c7ee146f2b88da17fd4e61b0a1a6707c91007ef0/bbb/cape/Podtique1/BB-BONE-AUDI-03-00A0.dts#L136-L150
>>>>
>>>>> - If possible, you can also listen to the TLV outputs directly
>>>>> without the amp in order to know if it's caused by the amp or before
>>>>> it in the audio chain.
>>>>
>>>> Hmm, not sure how to listen to them. But like I said, I don't think it's caused by the amp. Once the CODEC is reset by ALSA, the noise stops, even though the amp remains powered.
>>>>
>>>> I tried to look at the output on an oscilloscope, but this has proved challenging.
>>>
>>> Very difficult with a scope.  You can use an LC filter for that, but
>>> even so, there i still a ton of high frequency crud left due to the
>>> sigma delta dacs.  Much better to use a pro audio sound card with pro
>>> audio level balanced inputs like RME Fireface or Lynx.  There are many
>>> others, though I'm only really familiar with the fireface.
>>
>> Haha! That's amusing. I don't have the budget for that, sadly. Are you in the Bay Area? Can I come over?
>>
>>>> I can see signal on the line as soon as the CODEC is configured by ALSA, even before sending it samples. Once the CODEC is reset by ALSA, the signal visible reduces substantially.
>>>
>>> Yep, that's becase the codec itself is turned on/off.  there will be
>>> lots of digital noise up over a few MHz, and it makes viewing with a
>>> scope almost impossible.  Get a pro audio sound card :-)
>>
>> :-)
>
> You can also simply arrange your line output to connect it to external
> amplified speakers. Just take care about the differential thing
> depending on how your on-board amplifier is fed. But you should try
> the software stuff below before spending time on hardware testing.
>
>> I want to try the e2e engineer's suggestion to route the audio through the output mixer, but that doesn't actually seem to be possible to do (you can do it for the HP out, but not the line out). In fact, the diagram is so bizarre as to make me think it's incorrect. For example, you don't seem to be able to route the L&R DAC output to the Line Out L&R mixers, but you can short the L&R DAC outputs together.
>
> Your asound.state doesn't look right. I think that's the issue. You
> can use amixer to fix them one by one. Then, you can save the results
> with `alsactl store`, and you can reload all the changes in a single
> step later with `alsactl restore`.
>
> First, just looking at the audio paths diagram, there are controls
> that seem to be unrelated, e.g. the Mono stuff and the Line2L/R
> differential options. But maybe this diagram is just not accurate
> enough. You can check this in the driver vs. the data sheet. If
> actually unrelated, these controls are just for the other CODECs
> supported by this driver. That shouldn't be the cause of your issue
> anyway.
>
> Switch off or mute all the following controls:
>  - all cross-channel controls: L -> R and R -> L,
>  - all bypass controls,
>  - all Line1L/R, Line2L/R, Mono, HP[L/ROUT/COM], PGA, AGC, ADC controls.
>
> You need to unmute Line DAC Playback Volume.
>
> You need to switch on Left Line Mixer DACL1 Switch and Right Line
> Mixer DACR1 Switch (already done in your asound.state).
>
> You have to switch Left DAC Mux to DAC_L1 and Right DAC Mux to DAC_R1.
> I think that's the main issue.

Or, instead of using amixer, you can just edit the control values in
asound.state then run `alsactl restore` (then `alsactl store` if you
want to automatically refactor the comments in the file according to
the new values). That would be more friendly.

Best regards,
Benoît