[alsa-devel] Noise in tlv320aic3104-based audio system
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.
Dear Rick Mann,
On Thu, Oct 29, 2015 at 8:59 AM, Rick Mann rmann@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.
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. - 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. - 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.
Best regards, Benoît
On Oct 29, 2015, at 14:21 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Thu, Oct 29, 2015 at 8:59 AM, Rick Mann rmann@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/...
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.
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.
- 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/167...
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/c7ee146f2b88da17fd4e61b0a1a6707c91...
- 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. I used speaker-test to generate a 500 Hz sine wave, but the noise on the differential line out seems to eclipse the signal; at least, I haven't really been able to see the sine wave, despite hearing a pretty clear 500 Hz tone from the speakers (albeit with the hiss).
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.
On Thu, Oct 29, 2015 at 2:56 PM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 14:21 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Thu, Oct 29, 2015 at 8:59 AM, Rick Mann rmann@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.
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).
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).
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.
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?
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.
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.
- 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#1671425I 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/5d01938dcd952557d2afHere'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.
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 :-)
-Caleb
Thanks, Caleb, answers below:
On Oct 29, 2015, at 16:08 , Caleb Crome caleb@crome.org wrote:
On Thu, Oct 29, 2015 at 2:56 PM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 14:21 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Thu, Oct 29, 2015 at 8:59 AM, Rick Mann rmann@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/68747470733a2f2f6661726d312e737461746963666c69636b722e636f6d2f3637382f32313431393631383237305f303233336331643566355f682e6a7067FYI, 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.
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#1671425I 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/5d01938dcd952557d2afHere'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 :-)
:-)
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.
Thanks for taking a look at this, Caleb, I appreciate it.
On Thu, Oct 29, 2015 at 4:40 PM, Rick Mann rmann@latencyzero.com wrote:
Thanks, Caleb, answers below:
On Oct 29, 2015, at 16:08 , Caleb Crome caleb@crome.org wrote:
On Thu, Oct 29, 2015 at 2:56 PM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 14:21 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Thu, Oct 29, 2015 at 8:59 AM, Rick Mann rmann@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/68747470733a2f2f6661726d312e737461746963666c69636b722e636f6d2f3637382f32313431393631383237305f303233336331643566355f682e6a7067FYI, 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.
Yeah, but your layout looked okay. I wouldn't expect any serious audio issues. EMI is a different story -- the dual ground planes kill EMI compatibility.
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.
Okay, I see it now. That should be okay I think. Not perfect (i.e. under the codec), but fine.
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.
yeah, but as it is, looks good enough.
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.
I'd be interested in the results of shorting these out. I don't expect it to be your problem, but I suspect they are unnecessary.
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
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.
Ah, I'll take a look..
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.
No, it's not too sad, that's how it's supposed to work :-) . It's just the nature of sigma-delta conversion. The key is that none (or very little) of that noise should be in the audible band.
- 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?
Yep, in mountain view :-) Just send me a direct email and we can set up a lunch debug.
Thanks for taking a look at this, Caleb, I appreciate it.
No problem, -Caleb
Dear Rick Mann,
On Fri, Oct 30, 2015 at 12:40 AM, Rick Mann rmann@latencyzero.com wrote:
Thanks, Caleb, answers below:
On Oct 29, 2015, at 16:08 , Caleb Crome caleb@crome.org wrote:
On Thu, Oct 29, 2015 at 2:56 PM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 14:21 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Thu, Oct 29, 2015 at 8:59 AM, Rick Mann rmann@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/68747470733a2f2f6661726d312e737461746963666c69636b722e636f6d2f3637382f32313431393631383237305f303233336331643566355f682e6a7067FYI, 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#1671425I 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/5d01938dcd952557d2afHere'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.
Best regards, Benoît
On Fri, Oct 30, 2015 at 1:18 AM, Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Fri, Oct 30, 2015 at 12:40 AM, Rick Mann rmann@latencyzero.com wrote:
Thanks, Caleb, answers below:
On Oct 29, 2015, at 16:08 , Caleb Crome caleb@crome.org wrote:
On Thu, Oct 29, 2015 at 2:56 PM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 14:21 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Thu, Oct 29, 2015 at 8:59 AM, Rick Mann rmann@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/68747470733a2f2f6661726d312e737461746963666c69636b722e636f6d2f3637382f32313431393631383237305f303233336331643566355f682e6a7067FYI, 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#1671425I 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/5d01938dcd952557d2afHere'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
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?
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.
On Thu, Oct 29, 2015 at 05:38:03PM -0700, Rick Mann wrote:
... 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)?
Yes, that's the way it is usually done; delete the file, somehow avoid it being written on shutdown, then on next boot whatever the driver and hardware has as a default will be used. Many drivers will use what the hardware has in registers. If the system firmware hasn't touched those registers, then you should have chip reset values. If the chip is specified without reset values, you'll have unpredictable values. Exciting times ensue.
On Oct 29, 2015, at 17:53 , James Cameron quozl@laptop.org wrote:
On Thu, Oct 29, 2015 at 05:38:03PM -0700, Rick Mann wrote:
... 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)?
Yes, that's the way it is usually done; delete the file, somehow avoid it being written on shutdown, then on next boot whatever the driver and hardware has as a default will be used. Many drivers will use what the hardware has in registers. If the system firmware hasn't touched those registers, then you should have chip reset values. If the chip is specified without reset values, you'll have unpredictable values. Exciting times ensue.
Thanks James...Cameron? Whoa. ;-)
I think what I'll do is reboot, delete the file, then load the overlay which will add the device to the device tree (it's not there after boot).
I might delete the file, reboot, delete it again? Dunno. We'll see.
Thanks for the confirmation that it works this way.
Sent from my iPhone
On Oct 29, 2015, at 5:38 PM, Rick Mann rmann@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@latencyzero.com
On Oct 29, 2015, at 20:43 , Caleb Crome caleb@crome.org wrote:
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:-)
I've zeroed out everything I could find. Nothing had an effect until I got to the DAC muxes, at which point the behavior gets really weird. Changing those gets me to left or right output, but never both again until I reset the CODEC.
None of this affected the hiss.
Dear Rick Mann,
On Fri, Oct 30, 2015 at 6:45 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 20:43 , Caleb Crome caleb@crome.org wrote:
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:-)
I've zeroed out everything I could find. Nothing had an effect until I got to the DAC muxes, at which point the behavior gets really weird. Changing those gets me to left or right output, but never both again until I reset the CODEC.
None of this affected the hiss.
Can you try `alsactl restore` with this asound.state? https://gist.github.com/bthebaudeau/e00492ebf0309f8dbace
TI's diagram in the data sheet is missing a few things. Some paths are also wrong. The description of the registers is right however, so it is the reference. I have used extensively a similar setup with an older kernel, and it works fine.
Best regards, Benoît
On Oct 30, 2015, at 03:03, Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Fri, Oct 30, 2015 at 6:45 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 20:43 , Caleb Crome caleb@crome.org wrote:
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:-)
I've zeroed out everything I could find. Nothing had an effect until I got to the DAC muxes, at which point the behavior gets really weird. Changing those gets me to left or right output, but never both again until I reset the CODEC.
None of this affected the hiss.
Can you try `alsactl restore` with this asound.state? https://gist.github.com/bthebaudeau/e00492ebf0309f8dbace
TI's diagram in the data sheet is missing a few things. Some paths are also wrong. The description of the registers is right however, so it is the reference. I have used extensively a similar setup with an older kernel, and it works fine.
Best regards, Benoît
Thank you, Benoît. I'm out of town until Sunday night, will try it then. Thanks for confirming the errors in the data sheet.
On Fri, Oct 30, 2015 at 3:03 AM, Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Fri, Oct 30, 2015 at 6:45 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 20:43 , Caleb Crome caleb@crome.org wrote:
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:-)
I've zeroed out everything I could find. Nothing had an effect until I got to the DAC muxes, at which point the behavior gets really weird. Changing those gets me to left or right output, but never both again until I reset the CODEC.
None of this affected the hiss.
Can you try `alsactl restore` with this asound.state? https://gist.github.com/bthebaudeau/e00492ebf0309f8dbace
TI's diagram in the data sheet is missing a few things. Some paths are also wrong. The description of the registers is right however, so it is the reference. I have used extensively a similar setup with an older kernel, and it works fine.
Hey, that's great to know. I guess I haven't gone over every register and compared to the drawing. Thanks for the info. -caleb
On Fri, Oct 30, 2015 at 7:11 PM, Caleb Crome caleb@crome.org wrote:
On Fri, Oct 30, 2015 at 3:03 AM, Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Fri, Oct 30, 2015 at 6:45 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 20:43 , Caleb Crome caleb@crome.org wrote:
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:-)
I've zeroed out everything I could find. Nothing had an effect until I got to the DAC muxes, at which point the behavior gets really weird. Changing those gets me to left or right output, but never both again until I reset the CODEC.
None of this affected the hiss.
Can you try `alsactl restore` with this asound.state? https://gist.github.com/bthebaudeau/e00492ebf0309f8dbace
TI's diagram in the data sheet is missing a few things. Some paths are also wrong. The description of the registers is right however, so it is the reference. I have used extensively a similar setup with an older kernel, and it works fine.
Hey, that's great to know. I guess I haven't gone over every register and compared to the drawing. Thanks for the info.
You're welcome. As an example, if you follow the paths after the upper outputs of the DAC_L/R switches on the diagram, you will see that DAC_L1 can be connected to the LEFT_LO mixer, but that DAC_R1 cannot be connected to the RIGHT_LO mixer, which does not make sense as confirmed by the figure 22 in 10.3.6 (also see the description of the register 41 in the page 0): http://www.ti.com/lit/ds/symlink/tlv320aic3104.pdf
This chapter also recommends to bypass the line out mixers (using DAC_L3 and DAC_R3) for the use case discussed in this thread in order to get higher-quality output performance and lower-power operation (same in 10.3.7 with DAC_L2 and DAC_R2 for HP out), which contradicts the advice given on E2E. That's why I have used DAC_L1 and DAC_R1 in my asound.state, to match E2E, but whichever is the best, the difference should not be audible with regular speakers I think.
Best regards, Benoît
On Oct 30, 2015, at 03:03 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Fri, Oct 30, 2015 at 6:45 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 20:43 , Caleb Crome caleb@crome.org wrote:
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:-)
I've zeroed out everything I could find. Nothing had an effect until I got to the DAC muxes, at which point the behavior gets really weird. Changing those gets me to left or right output, but never both again until I reset the CODEC.
None of this affected the hiss.
Can you try `alsactl restore` with this asound.state? https://gist.github.com/bthebaudeau/e00492ebf0309f8dbace
TI's diagram in the data sheet is missing a few things. Some paths are also wrong. The description of the registers is right however, so it is the reference. I have used extensively a similar setup with an older kernel, and it works fine.
Benoît, it might be beneficial if you commented on my e2e post to indicate some of the missing paths you mentioned. Luis said he'd notify someone at TI (presumably) about the error in the diagram, but he may not know to add missing paths, as well.
Or let me know which ones are missing and I'll add that.
Thanks!
Dear Rick Mann,
On Mon, Nov 2, 2015 at 8:50 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 30, 2015, at 03:03 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Fri, Oct 30, 2015 at 6:45 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 20:43 , Caleb Crome caleb@crome.org wrote:
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:-)
I've zeroed out everything I could find. Nothing had an effect until I got to the DAC muxes, at which point the behavior gets really weird. Changing those gets me to left or right output, but never both again until I reset the CODEC.
None of this affected the hiss.
Can you try `alsactl restore` with this asound.state? https://gist.github.com/bthebaudeau/e00492ebf0309f8dbace
TI's diagram in the data sheet is missing a few things. Some paths are also wrong. The description of the registers is right however, so it is the reference. I have used extensively a similar setup with an older kernel, and it works fine.
Benoît, it might be beneficial if you commented on my e2e post to indicate some of the missing paths you mentioned. Luis said he'd notify someone at TI (presumably) about the error in the diagram, but he may not know to add missing paths, as well.
Or let me know which ones are missing and I'll add that.
I have gone through asound.state to look for inconsistencies with the diagram. All the wrong or missing paths are on DAC_R1, which should just be made symmetrical to DAC_L1. Also, the "external feedback" value of the Right HPCOM Mux is not represented on the diagram (see register 38). There were many other inconsistencies, but because of your DTS (see below).
I had told you in one of my previous posts that there were weird things that should not be present, like the mono controls, and indeed: your DTS is wrong. You should replace compatible = "ti,tlv320aic3x"; with compatible = "ti,tlv320aic3104"; That will remove a lot of N/A controls (1: fix your .dts, 2: restore my asound.state, 3: store it in order to remove extra controls) that may have an effect on your hiss if used: all Mono, Line2, and Mic3 controls. Some Mic2 controls should also appear, which you should disable.
Best regards, Benoît
On Nov 2, 2015, at 13:04 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Mon, Nov 2, 2015 at 8:50 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 30, 2015, at 03:03 , Benoît Thébaudeau benoit.thebaudeau.dev@gmail.com wrote:
Dear Rick Mann,
On Fri, Oct 30, 2015 at 6:45 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 29, 2015, at 20:43 , Caleb Crome caleb@crome.org wrote:
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:-)
I've zeroed out everything I could find. Nothing had an effect until I got to the DAC muxes, at which point the behavior gets really weird. Changing those gets me to left or right output, but never both again until I reset the CODEC.
None of this affected the hiss.
Can you try `alsactl restore` with this asound.state? https://gist.github.com/bthebaudeau/e00492ebf0309f8dbace
TI's diagram in the data sheet is missing a few things. Some paths are also wrong. The description of the registers is right however, so it is the reference. I have used extensively a similar setup with an older kernel, and it works fine.
Benoît, it might be beneficial if you commented on my e2e post to indicate some of the missing paths you mentioned. Luis said he'd notify someone at TI (presumably) about the error in the diagram, but he may not know to add missing paths, as well.
Or let me know which ones are missing and I'll add that.
Thank you,
I have gone through asound.state to look for inconsistencies with the diagram. All the wrong or missing paths are on DAC_R1, which should just be made symmetrical to DAC_L1. Also, the "external feedback" value of the Right HPCOM Mux is not represented on the diagram (see register 38). There were many other inconsistencies, but because of your DTS (see below).
I had told you in one of my previous posts that there were weird things that should not be present, like the mono controls, and indeed: your DTS is wrong. You should replace compatible = "ti,tlv320aic3x"; with compatible = "ti,tlv320aic3104";
I'll try this, but it took me a long time to get the DTS to do the right thing at all. In fact, one of my problems to solve soon is getting it all to work in a 4.1 kernel (currently I'm using 3.8). In 4.1, the problem I run into is the MCLK isn't getting set correctly (it generates a 24 MHz clock instead of a 12 MHz clock).
I feel like I originally tried "ti,tlv320aic3104" and that didn't work. However, I will try it again tonight.
That will remove a lot of N/A controls (1: fix your .dts, 2: restore my asound.state, 3: store it in order to remove extra controls) that may have an effect on your hiss if used: all Mono, Line2, and Mic3 controls. Some Mic2 controls should also appear, which you should disable.
Thank you, that makes sense. I appreciate it.
participants (4)
-
Benoît Thébaudeau -
Caleb Crome -
James Cameron -
Rick Mann