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

[Caleb Crome]

Sent from my iPhone

> On Oct 29, 2015, at 5:38 PM, Rick Mann <rmann at latencyzero.com> wrote:
> 
> Thanks, Benoît,
> 
>> 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.
> 
> I got that file from the CircuitCo Audio Cape (since it uses the same CODEC I use; in fact, I chose my CODEC because that one was known to work). It's entirely possible it's wrong, although I have done a little switching myself.
> 
> As I mentioned in the other post, the tlv320aic3104's datasheet describes a really bizarre (IMHO) set of available routes. I hope the data sheet is wrong, because I don't see a way to route both DACs to their respective Line Outs via the mixers (as suggested by TI), only in bypass.
> 
> A couple weeks ago I did spend a lot of time looking at the driver code (tlv320aic3x.c), trying to understand how it maps routes to register calls, etc. I found I couldn't quite correlate names of things in the driver with names in the asound.state file. Is there a way to generate a default asound.state file? For example, if I delete the file altogether, and then reboot, reload my Device Tree Overlay, and then issue alsactl store, will it create a "clean" asound file with just the right controls (with defaults)? Or must that file be created in parallel by hand?
> 


The data sheets for those aic codecs are pretty good I think.  

Also, routing direct or through a mixer will be a minor difference, not a major one.

It just occurred to me, the noise could easily be coming from a direct input -> output route, bypassing the adc and dac altogether.  Make sure all bypass routes are zeroed out.  The trick is correlating the datasheet routes with the alsa mixer controls that correspond to them .  Enough staring at the aic3x.c files will eventually shed light:-) 




> When I have more time tonight at home I'll see if I can make sense of the relationship between the driver code and the asound.state file.
> 
> Part of where I trip up is that it seems ALSA uses the strings (like "PCM Playback Volume") to match between chip registers and UI. Coming from an Apple background, I would never write code that depended on human-readable strings as identifiers (because you typically want to be able to change or translate them). However, that does seem to be what's going on here.
> 
> Anyway, thanks for the additional explanation, it's very helpful.
> 
> 
> -- 
> Rick Mann
> rmann at latencyzero.com
> 
>