Hi Peter,
Am 20.09.2014 um 01:34 schrieb Peter Ujfalusi:
Hi,
On 09/19/2014 03:33 PM, Dr. H. Nikolaus Schaller wrote:
Hi, for evaluating if we should or should not finally consider the TWL6040 for the Pyra audio system, I became aware that the PandaBoard ES (also comes with the TWL6040) is capable to connect a single external speaker and drive it with up to 1.5Watts:
http://e2e.ti.com/support/omap/f/849/t/258083.aspx
So it would be possible to connect the speakers planned for the Pyra and play sounds (the OMAP5432EVM has no access to this amplifier).
Yes, omap5-uevm only have line out connected. But the audio path is basically the same towards the HF pins and AUX, there's a switch which takes the audio from the HF path before the AMP to the AUX pins.
Please find attached my panda5.aconf, which sets up the routing for the panda5. Just edit the card name to match with PandaBoardES and load it with alsactl You will have route setup to AUXL and HF, but you need to modify the dts and add this: "Ext Spk", "HFL", "Ext Spk", "HFR",
to the audio-routing of the sound card.
Ok. The Panda-ES already has thin in its setup (arch/arm/boot/dts/omap4-panda-es.dts).
But your aconf did not match the names of the controls. So maybe someone has renamed them in the kernel driver.
I have the GTA04-3.17 Linux running on the Panda ES as well (so we have exactly the same setup as for the OMAP5432EVM except the device tree).
aplayer does something (without complaining). But I don't get sound.
Most likely the amixer settings are not ok (muted).
Here, I have found a recommended setup:
http://www.jotschi.de/Uncategorized/2011/07/01/pandaboard-audiosetup.html
but it does not match the amixer controls of the 3.17 kernel I use.
And
http://www.omappedia.com/wiki/Audio_Drive_Arch#OMAP4.2F5_ASoc_Kernel_audio_d...
wasn't enlightening either because it appears not to be up-to date with 3.17 kernel drivers.
Yeah, they are valid if you have AESS (or ABE) used in your kernel,
What I have is:
root@gta04:~# amixer
...
which you do not have in the kernel. Without AESS support you have the dumb McPDM and twl6040 setup.
Ah, now I think I understand. There are two methods to set up audio.
One is just sending audio to the codec. Like with the TWL4030.
Then, one has amixer controls for the codec.
Or the other option is to use the AESS system giving many more control and functions.
If you want to play audio to the headset, you can play a stereo file and that is fine, but if you want to have audio on the HF/AUX you need to play 4 channel audio: ch1-2 goes to headset ch3-4 will go to HF/AUX
Yes, this is not really good.
But sufficient for testing purposes. Mainly we want to test if the TWL6040 codec plus speakers work sufficiently well.
According to http://www.omappedia.com/wiki/Audio_Drive_Arch#OMAP4.2F5_ASoc_Kernel_audio_d... there appears a different method to test: set the mixer to 'Line-In amp'. Then, the AUX in should be amplified.
I guess this path has been designed that the TWL6040 can be operated stand-alone to drive FM radio signals to the headset and the speakers with the OMAP being completely shut down.
To answer the coming question regarding to AESS/ABE support: git://gitorious.org/omap-audio/linux-audio.git base-bnw/* branches are topic branches next-bnw/ti-audio-next_3.12 ... 3.15 are the merged branches with AESS support working on OMAP4/5 Under the firmware directory there's a firmware (omap_aess-adfw.bin)
Fine!
bnw stands for Brave New World. I started to clean up/rewrite the AESS/ABE code found in 3.8 TI kernel, hence the name.
I did not had time to move to 3.16 and to 3.17 yet, but it is in my plans.
Well, I think we will have 3.18 or 3.19 when the first real Pyra hardware becomes available.
And this is not really a lightweight thing to just pick, since the AESS support has dependency on the yet to be upstreamed ASoC Dynamic Firmware support.
Since I mentioned plans, I'm also planning to move to a new dynamic firmware base when moving to 3.16 or 3.17, but this new core code is not maintained by me, so I need to ask for green light form the guys working with that codebase (and they are not TI guys). Just to be safe. If I did not get green light to use their code in public, I will roll the current code forward.
Yes, it is complicated :(
Yes, I know Kernel development is complicated as soon as you want to get something upstream that works for you.
BR, Nikolaus
Good news!
Using the following script I can get headset output on the PandaES (have not yet tested on the OMAP5432EVM with the same kernel):
amixer -q set "Aux FM" 100% && amixer -q set "Capture" 100% && amixer -q set "Capture Preamplifier" 100% && amixer -q set "AUXL" "on" && amixer -q set "AUXR" "on" && amixer -q set "Analog Left" Off && amixer -q set "Analog Right" Off && amixer -q set "Earphone" 100% && amixer -q set "Handsfree" 100% && amixer -q set "Handsfree Left Playback" "HF DAC" && amixer -q set "Handsfree Right Playback" "HF DAC" && amixer -q set "Headset" 100% && amixer -q set "Headset Left Playback" "HS DAC" && amixer -q set "Headset Right Playback" "HS DAC" && amixer -q set "Headset Power Mode" "High-Performance" && amixer -q set "PLL Selection" "High-Performance" && amixer -q set "Vibra Left Playback" "Audio PDM" && amixer -q set "Vibra Right Playback" "Audio PDM" && aplay -q /usr/share/sounds/alsa/*.wav
What I did not get is Stereo - but that might be an issue of the plug or the sound files.
Unfortunately it makes a big "plop" sound on plug-in or starting aplay. But I am sure that there is a solution since the TWL6040 was developed together with Nokia and they are (were) very experienced with such issues.
Otherwise the sound appears to be clear and crisp (and zero noise if off).
I have also tested with some signal generator software like:
sox -c 4 -n -t wav - synth 10 sine 10-100 | aplay
but that one sounds like there is overmodulation / clipping.
The J6 pins for the speaker also has signals (seen with oscilloscope).
Finally I have preliminarily wired up one of the speakers we have planned for the Pyra and it also emits sounds :)
Again, quality is difficult to estimate since I have no music or real test sounds and the speaker(s) should be within some box and pressed onto some PCB...
But we now have a test setup for evaluating the software / codec / amplifier side.
BR, Nikolaus