[alsa-devel] Audio routing in the tlv320aic3104
I've managed to get a hacky, fragile config working, in the sense that it sends my tlv320aic3104 samples from speaker-test, and the clocks and data all look good on the oscilloscope, and it ping-pongs between the left and right channel.
But it's outputting the signal on the HPLOUT/HPROUT pins, not the L&R Line Out pins.
My DTS has this:
fragment@3 { target = <&ocp>; __overlay__ { sound { compatible = "ti,da830-evm-audio"; ti,model = "DA830 EVM"; ti,audio-codec = <&tlv320aic3x>; ti,mcasp-controller = <&mcasp0>; ti,codec-clock-rate = <12000000>; ti,audio-routing = "Line Out", "LLOUT", "Line Out", "RLOUT"; }; }; };
The original had:
"Headphone Jack", "HPLOUT", "Headphone Jack", "HPROUT", "LINE1L", "Line In", "LINE1R", "Line In";
I also have an asound.state file I got from the Audio Cape:
https://raw.githubusercontent.com/CircuitCo/BeagleBone-Audio/files/asound.st...
I don't really know how to interpret that file. One resource online said it held the current state of the system. I guess that suggests I should play with amixer. But how does the DTS routing come into play?
Thanks,
Sent from my iPhone
On Oct 7, 2015, at 4:12 AM, Rick Mann rmann@latencyzero.com wrote:
I've managed to get a hacky, fragile config working, in the sense that it sends my tlv320aic3104 samples from speaker-test, and the clocks and data all look good on the oscilloscope, and it ping-pongs between the left and right channel.
But it's outputting the signal on the HPLOUT/HPROUT pins, not the L&R Line Out pins.
My DTS has this:
fragment@3 { target = <&ocp>; __overlay__ { sound { compatible = "ti,da830-evm-audio"; ti,model = "DA830 EVM"; ti,audio-codec = <&tlv320aic3x>; ti,mcasp-controller = <&mcasp0>; ti,codec-clock-rate = <12000000>; ti,audio-routing = "Line Out", "LLOUT", "Line Out", "RLOUT"; }; }; };
The original had:
"Headphone Jack", "HPLOUT", "Headphone Jack", "HPROUT", "LINE1L", "Line In", "LINE1R", "Line In";
I also have an asound.state file I got from the Audio Cape:
https://raw.githubusercontent.com/CircuitCo/BeagleBone-Audio/files/asound.st...
I don't really know how to interpret that file. One resource online said it held the current state of the system. I guess that suggests I should play with amixer. But how does the DTS routing come into play?
Thanks,
Check for the routing in the davinci-evm.c file. It has other routes, I kind of recall it says some outputs are not connected. You might have to edit routs there too.
-- Rick Mann rmann@latencyzero.com
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Oct 7, 2015, at 05:52, Caleb Crome caleb@crome.org wrote:
Sent from my iPhone
On Oct 7, 2015, at 4:12 AM, Rick Mann rmann@latencyzero.com wrote:
I've managed to get a hacky, fragile config working, in the sense that it sends my tlv320aic3104 samples from speaker-test, and the clocks and data all look good on the oscilloscope, and it ping-pongs between the left and right channel.
But it's outputting the signal on the HPLOUT/HPROUT pins, not the L&R Line Out pins.
My DTS has this:
fragment@3 { target = <&ocp>; __overlay__ { sound { compatible = "ti,da830-evm-audio"; ti,model = "DA830 EVM"; ti,audio-codec = <&tlv320aic3x>; ti,mcasp-controller = <&mcasp0>; ti,codec-clock-rate = <12000000>; ti,audio-routing = "Line Out", "LLOUT", "Line Out", "RLOUT"; }; }; };
The original had:
"Headphone Jack", "HPLOUT", "Headphone Jack", "HPROUT", "LINE1L", "Line In", "LINE1R", "Line In";
I also have an asound.state file I got from the Audio Cape:
https://raw.githubusercontent.com/CircuitCo/BeagleBone-Audio/files/asound.st...
I don't really know how to interpret that file. One resource online said it held the current state of the system. I guess that suggests I should play with amixer. But how does the DTS routing come into play?
Thanks,
Check for the routing in the davinci-evm.c file. It has other routes, I kind of recall it says some outputs are not connected. You might have to edit routs there too.
Actually I was able to use amixer to switch the DAC muxes to the right setting, and the signal routed to the right place. I think it's the first time in three weeks that the first thing I tried actually worked as expected.
But I had hoped ALSA would enable only that route given the DTS; perhaps it's the asound.state file I downloaded that forced its hand the wrong way; I'll try that experiment later.
At least now I can populate the remaining parts on the board to see if they work, too.
I still am far from complete with the Linux config (need to get it working in 4.x, need to get my enable GPIOs working automatically, etc.), but I can finally make real progress.
Thanks!
Woo!
On Wed, Oct 7, 2015 at 11:15 AM, Rick Mann rmann@latencyzero.com wrote:
On Oct 7, 2015, at 05:52, Caleb Crome caleb@crome.org wrote:
Sent from my iPhone
On Oct 7, 2015, at 4:12 AM, Rick Mann rmann@latencyzero.com wrote:
I've managed to get a hacky, fragile config working, in the sense that
it sends my tlv320aic3104 samples from speaker-test, and the clocks and data all look good on the oscilloscope, and it ping-pongs between the left and right channel.
But it's outputting the signal on the HPLOUT/HPROUT pins, not the L&R
Line Out pins.
My DTS has this:
fragment@3 { target = <&ocp>; __overlay__ { sound { compatible = "ti,da830-evm-audio"; ti,model = "DA830 EVM"; ti,audio-codec = <&tlv320aic3x>; ti,mcasp-controller = <&mcasp0>; ti,codec-clock-rate = <12000000>; ti,audio-routing = "Line Out", "LLOUT", "Line Out", "RLOUT"; }; }; };
The original had:
"Headphone Jack", "HPLOUT", "Headphone Jack", "HPROUT", "LINE1L", "Line In", "LINE1R", "Line In";
I also have an asound.state file I got from the Audio Cape:
https://raw.githubusercontent.com/CircuitCo/BeagleBone-Audio/files/asound.st...
I don't really know how to interpret that file. One resource online
said it held the current state of the system. I guess that suggests I should play with amixer. But how does the DTS routing come into play?
Thanks,
Check for the routing in the davinci-evm.c file. It has other routes,
I kind of recall it says some outputs are not connected. You might have to edit routs there too.
Actually I was able to use amixer to switch the DAC muxes to the right setting, and the signal routed to the right place. I think it's the first time in three weeks that the first thing I tried actually worked as expected.
But I had hoped ALSA would enable only that route given the DTS; perhaps it's the asound.state file I downloaded that forced its hand the wrong way; I'll try that experiment later.
At least now I can populate the remaining parts on the board to see if they work, too.
I still am far from complete with the Linux config (need to get it working in 4.x, need to get my enable GPIOs working automatically, etc.), but I can finally make real progress.
Thanks! _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (2)
-
Caleb Crome -
Rick Mann