Hi All,
We are using sgtl5000 audio codec from the freescale with the colibri imx6 processor, we are using the existing machine and codec driver available in kernel 3.10.17 of yocto 1.7.2.
Im using gstreamer to create an rtp connection beetwen my computer and my board. And it is working normally using this configurations below:
Capture: MIC
Headphone: LINE IN
changed using alsamixer. And it is working very well.
When we change:
Capture from MIC to LINE_IN
I start to listen the audio that im speaking from my computer mic, even with my hardware is without mic and headphone;
We used as reference for device tree changes from the imx6 colibri board device tree file.
Drivers:
sound/soc/fsl/imx-sgtl5000.c
sound/soc/codecs/sgtl5000.c
Device tree changes:
sound { /* Read related .txt file in Documentation for binding */
compatible = "fsl,imx6sl-alba-sgtl5000",
"fsl,imx-audio-sgtl5000";
model = "imx6sl-alba-sgtl5000";
ssi-controller = <&ssi2>;
audio-codec = <&codec>;
audio-routing =
"MIC_IN", "Mic Jack",
"Headphone Jack", "HP_OUT";
mux-int-port = <2>;
mux-ext-port = <3>;
};
Im thinking that this issue is related with audio-routing, but i don't know where can i change to fix this audio returning.
Someone can help me ? Any hint will be very helpfully !!
Thanks.
art
We made some tests using the IMX53 QSB with original kernel from NXP:
Kernel: 2.6.35.3-1129-g691c08a
root@freescale ~$ gst-launch-0.10 --version
gst-launch-0.10 version 0.10.28
GStreamer 0.10.28
Link:
PC - connected to speaker and microfone (headset)
IMX53 - Only speaker (headphone)
Both are connected to the same LAN, We use the same script that we posted.
When the alsamixer is configured to Line IN, the echo appears.
Best Regards,
Caio Pereira
Hello, My name is Raul I'm FAE on Toradex Brazil.
I'm also trying to help Caio in this issue.
Our Colibri Modules are pin compatible so, we have some other modules with with different codecs.
I did the same test using the Colibri T20 that uses the Wolfson WM9715L Audio Controller.
In this case I didn't see the cross talking. So its help as to double check that is not a carrier board issue.
I also did a quick test with mainline kernel. To do it I used the Apalis iMX6 because this is the most update one we have inside main line kernel and use the same codec as Colibri iMX6. In this case the issue was exactly the same.
I did all this tests about tree weeks ago, so if there is any question let me know. I will keep following this topic.
Thanks all.
art
I work together with alledpaiva, today we was testing the sgtl500's i2c registers.
When you change parameters from AlsaMixer Headphone Mux and Capture Mux , we have only changes in 2 registers:
Reg 0x24 - CHIP_ANA_CTRL
Reg 0x30 - CHIP_ANA_POWER
The Reg 0x0A - CHIP_SSS_CTRL is fixed in 0x0010.
Changes on Capture Mux
MIC_IN -> Reg 0x24 -> 0x0060
LINE_IN -> Reg 0x24 -> 0x0064 |
Change on Headphone Mux and Capture Mux = Line_IN
DAC-> Reg 0x24 -> 0x0024 | Reg 0x30 --> 0x5260
LINE_IN -> Reg 0x24 -> 0x0064 | Reg 0x30 --> 0x5270
Change on Headphone Mux and Capture Mux = MIC_IN
DAC-> Reg 0x24 -> 0x0020 | Reg 0x30 --> 0x5260
LINE_IN -> Reg 0x24 -> 0x0060 | Reg 0x30 --> 0x5270
Analysing the SGTL5000 Datasheet the SSS_CTRL configured to 0x10 should not have return.
Our suspect is there's some hardware problem (crosstalk) or if is there a bad Audio Switch configuration (after this tests with i2c I supposed that there's is no problem with audio switch).
Thank you.
Best Regards,
Caio Pereira
To be honest, I have no idea where the hardware crosstalk can come from. My suspect is that the loopback occurs somewhere on the software side. As far as I understand, you use your Colibri board for full-duplex audio streaming between the board and host PC over Ethernet. Is it so? Please confirm. What software do you use on the board side for audio streaming? Please specify. Also, to further separate the software problem from the hardware one, please provide the separate dumps of SGTL5000 registers for Normal and Loopback cases.
Best Regards,
Artur
Artur,
Yes, we're using the colibri board for a voice over ip conversation, we're using the gstreamer in our software to provide the audio encoding and udp/tcp transport.
Gstreamer 1.0 - v. 1.4.2
Linux Kernel - 3.10.17
Alsa
Pulseaudio V5.0
We were testing using with pulseaudio and without pulseaudio (only alsa) we had the same results.
To avoid the echo we need to use the pulseaudio with the aec echo cancelling enabled.
When we start a voice conversation with Capture_MUX = Mic, the audio is normal, during the conversation we configure (using alsamixer) the Capture_MUX to LINE_IN and the echo starts.
Monitoring the sgtl5000 register, only the regs 0x24 and 0x30 changes.
"When you change parameters from AlsaMixer Headphone Mux and Capture Mux , we have only changes in 2 registers:
Reg 0x24 - CHIP_ANA_CTRL
Reg 0x30 - CHIP_ANA_POWER"
Do you have some suggestion to test and isolate this softwares?
Thank you very much.
Best Regards,
Caio Pereira
What exactly the Gstreamer command line is on the board side and on the PC side? Try to use the pure Gstreamer without Alsamixer and any other audio software running.
Artur
Artur,
Gstreamer Command Line
We are using this script (gstreamer-call.sh) to provide the voice call.
We utilize this script in pc and in the imx6 board
pc
./gstreamer-call.sh imx6board_ip start
imx6 board
./gstreamer-call.sh pc_ip start
-------- start of script ----------------
#!/bin/sh
#
# change this to send the RTP data and RTCP to another host
IPDEST=$1
case "$2" in
start)
echo "Starting gstlaunch"
gst-launch-1.0 -v \
autoaudiosrc \
! alawenc ! rtppcmapay ! queue ! udpsink port=4000 host=$IPDEST &
gst-launch-1.0 -v udpsrc caps="application/x-rtp,media=(string)audio,clock-rate=(int)8000,encoding-name=(string)PCMA" port=4000 \
! queue ! rtppcmadepay ! alawdec ! audioconvert ! audioresample ! \
autoaudiosink \
&
;;
stop)
echo "Stopping gstlaunch"
killall gst-launch-1.0
;;
*)
echo "Usage: $0 <ipaddress> start|stop"
exit 1
;;
esac
-------- end of script ----------------
We tested a different types gstreamer's pipes, this script is our base reference.
Artur Petukhov escreveu:
What exactly the Gstreamer command line is on the board side and on the PC side? Try to use the pure Gstreamer without Alsamixer and any other audio software running.
Artur
When you say to "try to use the pure gstreamer without alsamixer" did you mean: To configure the codec using a pure C code to maniupulate the codec i2c?
Do you have some command line example to test?
Thank you
Best Regards,
Caio Pereira
Today we tested the sgtl5000 using IMX.53 Quick Start Board with Yocto 2.0 (kernel 4.1.13-fslc+ge55a6a9) and we got the same result.
The eco is lower than our test with Colibri IMX.6.
The regmap:
root@imx53qsb:/sys/kernel/debug/regmap/1-000a# cat registers
000: a011
002: 0063
004: 0023
006: 01b0
00a: 0010
00e: 0200
010: 3c3c
014: 015f
020: 0000
022: 0000
024: 0026
026: 0068
028: 01f0
02a: 0003
02c: 0320
02e: 0404
030: 17bb
032: 98ea
034: 0000
036: 0017
03a: 0000
03c: 0000
100: 0000
102: 0000
104: 0040
106: 051f
108: 0000
10a: 0040
10c: 0000
10e: 0000
110: 0000
116: 002f
118: 002f
11a: 002f
11c: 002f
11e: 002f
120: 8000
122: 0000
124: 0510
126: 1473
128: 0028
12a: 0050
12c: 0000
12e: 0000
130: 0000
132: 0000
134: 0000
136: 0000
138: 0000
13a: 0000
Best Regards,
Caio Pereira
Most likely, you get some loopback configuration on your Colibri board side. First, try to change the 'Headphone' parameter from LINE_IN to something else when you're changing the 'Capture' parameter to LINE_IN in Alsamixer.
Have a great day,
Artur
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hey Artur!! First of all, Thanks for the hint!
We already did this changes! 'Headphone mux' is fixed to DAC because the audio we only have HP_OUT to listen the audio (Colibri board side).
And the result found was:
-> Using MIC we have no ECHO.
-> Using LINE_IN we have a loud ECHO ! (I think that it can be some type of loopback (audio routing), because we have tested on our hardware keeping the LINE_IN opened, and the audio was still returning! ) wich makes us think that STL5000 is returning!
But we read the i2c register (kernel Debug) and we think (by reading SGTL5000 Datasheet) that it is correct.
Please provide the complete dump of the SGTL5000 registers to make me able to check it deeper.
Artur
Artur,
To get these information, I ran gstreamer (on PC and Colibri Board) and with this alsamixer configuration below (Colibri side):
i've got this data:
root@colibri-imx6:~# cat /sys/kernel/debug/regmap/1-000a/name
sgtl5000
root@colibri-imx6:~# cat /sys/kernel/debug/regmap/1-000a/registers
000: a011
002: 0063
004: 000b
006: 01b0
00a: 0010
00e: 0200
010: 3c3c
014: 015f
020: 01dd
022: 0808
024: 0024
026: 0008
028: 0120
02a: 0000
02c: 0322
02e: 0404
030: 57fb
032: 8312
034: 0008
036: 0017
03a: 0000
03c: 0000
100: 0000
102: 0000
104: 0040
106: 051f
108: 0000
10a: 0040
10c: 0000
10e: 0000
110: 0000
116: 002f
118: 002f
11a: 002f
11c: 002f
11e: 002f
120: 8000
122: 0000
124: 0510
126: 1473
128: 0028
12a: 0050
12c: 0000
12e: 0000
130: 0000
132: 0000
134: 0000
136: 0000
138: 0000
13a: 0000
Is this information that you ask me to get ? There is some other way to get this information ?
OBS.: If I turn down the level of Headpone or PCM the level of returning is lower too.
Best Regards,
Alled.