Hi, I have soldered (well, almost) a speaker adapter test for the Pandaboard so that you can do handsfree-speaker tests (in addition to headphone out tests).
I have taken a spare Pyra V3-PCB so that you can place the speakers into the 3D printed case and use the PCB to contact them. The cable should go through one of the SD slots.
Unfortunately I didn't find a solderable 3.5mm connector to wire up the speaker cable. As soon as I have one (and a test software), we can test the sound quality with the PandaBoard.
Since the CPU is only involved in setting up the mixer values but not in sound processing there should be no difference between PandaBoard and 5432EVM and Pyra (if we take the TWL).
BR, Nikolaus
I have now purchased a 3.5mm connector and first experiences:
1. it is possible to drive the Pyra speakers from the EVM headset out (they don't have full power of course) 2. it looks as if my test sound files were Mono - and therefore I didn't have stereo :) 3. you should "apt-get install sox libsox-fmt-mp3" 4. then it suffices to "play somefile.mp3" 5. well, after setting the mixers - I have my default script here:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=GTA04/root/twl6040;h=4...
Now the sound quality just by listening to some music and voice it is/has: * stereo experience * clear * crisp * high power (you resist to plug earphones into your ears at max. loudness...) * no jitter * no noise * no glitch * slight plopp * at least as good as other good MP3 players I know of (e.g. iPod)
So I would say: the TWL6040 is at least "good". It is definitively not "bad".
What I can't tell from just listening is if it is "very good" or "exceptionally good".
BR, Nikolaus
Am 28.09.2014 um 18:31 schrieb Dr. H. Nikolaus Schaller:
Hi, I have soldered (well, almost) a speaker adapter test for the Pandaboard so that you can do handsfree-speaker tests (in addition to headphone out tests).
<DSC02097.jpeg>
<DSC02098.jpeg>
<DSC02099.jpeg>
I have taken a spare Pyra V3-PCB so that you can place the speakers into the 3D printed case and use the PCB to contact them. The cable should go through one of the SD slots.
Unfortunately I didn't find a solderable 3.5mm connector to wire up the speaker cable. As soon as I have one (and a test software), we can test the sound quality with the PandaBoard.
Since the CPU is only involved in setting up the mixer values but not in sound processing there should be no difference between PandaBoard and 5432EVM and Pyra (if we take the TWL).
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Okay, with the PandaBoard Nikolaus sent me, I was finally able to do some first Audio tests of the TWL6040.
My test setup: I created a file with various frequency tests (single frequencies with increasing volume, a frequency sweep, white, red and pink noise as well as some music samples), played that back using different devices (FocusRite Scarlett, Pandora, PandaBoard) and recorded them (with another FocusRite Scarlett).
First things first: The Amplifier of the PandaBoard is not that good. The more I increase the volume with ALSA, the worse the audio quality gets (it easily distorts). We should try to use our own amplifier for headset / speaker output, I think. Additionally, in the AlsaMixer settings had a switch I could toggle for headset output: Power Saving and High Performance.
Don't even try to use Power Saving. That setting is totally horrible. My guess is that it saves power by changing frequencies and trying to hide things the user can't hear (similar to MP3). But it does it bad enough that I can clearly hear it... and with clean frequency tests, it's even worse. With High Performance setting, the TWL was outputting pretty good audio (as can be seen in the documents).
The PDF document with the result can be downloaded here: http://evildragon.openpandora.org/AudioTest.pdf
And if you would like to analyse / compare the audio files and recording yourself, you can download the package here:
http://evildragon.openpandora.org/AudioTest.zip
All in all I think the TWL6040 is pretty good, but has a lot of settings we should setup as default and hide from the user (like the quality setting). And we should try to use our own amp for the headset / speakers.
Hi, great work!
Am 16.10.2014 um 03:57 schrieb Michael Mrozek EvilDragon@openpandora.org:
Okay, with the PandaBoard Nikolaus sent me, I was finally able to do some first Audio tests of the TWL6040.
My test setup: I created a file with various frequency tests (single frequencies with increasing volume, a frequency sweep, white, red and pink noise as well as some music samples), played that back using different devices (FocusRite Scarlett, Pandora, PandaBoard) and recorded them (with another FocusRite Scarlett).
First things first: The Amplifier of the PandaBoard is not that good. The more I increase the volume with ALSA, the worse the audio quality gets (it easily distorts).
Please can you describe your setup exactly?
What I am missing is some definition which outputs you did use.
Pandora: Line-Out or headset jack? PandaBoard: Headphone or Handsfree Speaker?
This information might be helpful to compare the results with the schematics to find out if it is really the amplifier, i.e. can be improved by using another one.
We should try to use our own amplifier for headset / speaker output, I think. Additionally, in the AlsaMixer settings had a switch I could toggle for headset output: Power Saving and High Performance.
Don't even try to use Power Saving. That setting is totally horrible. My guess is that it saves power by changing frequencies and trying to hide things the user can't hear (similar to MP3). But it does it bad enough that I can clearly hear it... and with clean frequency tests, it's even worse.
from the TWL4030 data sheet:
The stereo headphone path has a low-power (LP) mode operating from a 32-kHz sleep clock to enable over 100 hours of MP3 playback time. Very-high dynamic range of 104 dBA is achieved when using the system clock input and DAC path high-performance (HP) mode. Class-AB headphone drivers provide a 1Vrms output and are ground centered for capless connection to headphone, thus enabling system size and cost reduction. The earpiece driver is a differential class-AB driver with 2Vrms capability to a typical 32-Ω load or 1.4Vrms to a typical 16-Ω load.
This means the LP mode is indeed optimised for MP3 playback, i.e. not better than MP3 :) Technically it uses the 32kHz signal to derive its internal clocks (17/19MHz) and enables only the headset path (everything else on the chip is disabled and the CPU is not required to provide the 19 MHz clock).
So there should be no audible difference. But I remember that Peter mentioned some issue in the driver.
Finally this text confirms that the headset out has an *analog* amplifier (Class AB) with ~100 mW output power.
Once again we gained a little more understanding of the TWL6040 details...
With High Performance setting, the TWL was outputting pretty good audio (as can be seen in the documents).
The PDF document with the result can be downloaded here: http://evildragon.openpandora.org/AudioTest.pdf
And if you would like to analyse / compare the audio files and recording yourself, you can download the package here:
http://evildragon.openpandora.org/AudioTest.zip
All in all I think the TWL6040 is pretty good, but has a lot of settings we should setup as default and hide from the user (like the quality setting).
Indeed.
And we should try to use our own amp for the headset / speakers.
Hm.
The question will be, which one is „our own amp“?
The amp used in the Pandora does not have enough power for the speakers. And if we want to build a small, power-efficient amplifier we should use class D.
BR, Nikolaus
Am Thu, 16 Oct 2014 10:09:25 +0200 hat Dr. H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
First things first: The Amplifier of the PandaBoard is not that good. The more I increase the volume with ALSA, the worse the audio quality gets (it easily distorts).
Please can you describe your setup exactly? What I am missing is some definition which outputs you did use.
Pandora: Line-Out or headset jack?
Pandora: Line-Out
PandaBoard: Headphone or Handsfree Speaker?
PandaBoard: Headphone (the internal port)
I had issues using the one you soldered on top - the peak always was way higher than standard line-out, so even with lowest volume setting, I couldn't record it without distortions.
Might've been an issue with the software setup as well though, I can retest that.
from the TWL4030 data sheet:
The stereo headphone path has a low-power (LP) mode operating from a 32-kHz sleep clock to enable over 100 hours of MP3 playback time. Very-high dynamic range of 104 dBA is achieved when using the system clock input and DAC path high-performance (HP) mode. Class-AB headphone drivers provide a 1Vrms output and are ground centered for capless connection to headphone, thus enabling system size and cost reduction. The earpiece driver is a differential class-AB driver with 2Vrms capability to a typical 32-Ω load or 1.4Vrms to a typical 16-Ω load.
This means the LP mode is indeed optimised for MP3 playback, i.e. not better than MP3 :) Technically it uses the 32kHz signal to derive its internal clocks (17/19MHz) and enables only the headset path (everything else on the chip is disabled and the CPU is not required to provide the 19 MHz clock).
So there should be no audible difference. But I remember that Peter mentioned some issue in the driver.
Finally this text confirms that the headset out has an *analog* amplifier (Class AB) with ~100 mW output power.
Once again we gained a little more understanding of the TWL6040 details...
Well, that low-power mode sounded like MP3 with 128kbps, which is horrible for me ;)
With High Performance setting, the TWL was outputting pretty good audio (as can be seen in the documents).
The PDF document with the result can be downloaded here: http://evildragon.openpandora.org/AudioTest.pdf
And if you would like to analyse / compare the audio files and recording yourself, you can download the package here:
http://evildragon.openpandora.org/AudioTest.zip
All in all I think the TWL6040 is pretty good, but has a lot of settings we should setup as default and hide from the user (like the quality setting).
Indeed.
And we should try to use our own amp for the headset / speakers.
Hm.
The question will be, which one is „our own amp“?
The amp used in the Pandora does not have enough power for the speakers. And if we want to build a small, power-efficient amplifier we should use class D.
BR, Nikolaus
Hi,
Am 17.10.2014 um 14:51 schrieb Michael Mrozek mrozek@openpandora.org:
Am Thu, 16 Oct 2014 10:09:25 +0200 hat Dr. H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
First things first: The Amplifier of the PandaBoard is not that good. The more I increase the volume with ALSA, the worse the audio quality gets (it easily distorts).
Please can you describe your setup exactly? What I am missing is some definition which outputs you did use.
Pandora: Line-Out or headset jack?
Pandora: Line-Out
ok, this is DAC only and excludes the amplifier.
PandaBoard: Headphone or Handsfree Speaker?
PandaBoard: Headphone (the internal port)
ok, this already has a Class-AB amplifier included - and might be the reason why you see more noise.
I think the 5432EVM has a bypass mode to the third 3.5mm jack where the signals are fed out before the handsfree amplifier.
I had issues using the one you soldered on top - the peak always was way higher than standard line-out, so even with lowest volume setting, I couldn't record it without distortions.
That is what I meant with my warnings about measuring a class D amplifer output without proper low-pass filter or load.
This output is capable of driving 600mW - 1W into the new speakers. To make them really loud.
Maybe you can connect the speaker board I have added and the speaker. And then tap the signals arriving at the speaker.
For the records: the TWL6040 is designed for smartphone applications. Therefore it has 3 outputs:
1 earpiece (tiny power) 2 headset (low power) 2 handsfree/music speakers (high power)
Unfortunately not all of them are available on the PandaBoard/5432EVMs for evaluation.
Might've been an issue with the software setup as well though, I can retest that.
from the TWL4030 data sheet:
The stereo headphone path has a low-power (LP) mode operating from a 32-kHz sleep clock to enable over 100 hours of MP3 playback time. Very-high dynamic range of 104 dBA is achieved when using the system clock input and DAC path high-performance (HP) mode. Class-AB headphone drivers provide a 1Vrms output and are ground centered for capless connection to headphone, thus enabling system size and cost reduction. The earpiece driver is a differential class-AB driver with 2Vrms capability to a typical 32-Ω load or 1.4Vrms to a typical 16-Ω load.
This means the LP mode is indeed optimised for MP3 playback, i.e. not better than MP3 :) Technically it uses the 32kHz signal to derive its internal clocks (17/19MHz) and enables only the headset path (everything else on the chip is disabled and the CPU is not required to provide the 19 MHz clock).
So there should be no audible difference. But I remember that Peter mentioned some issue in the driver.
Finally this text confirms that the headset out has an *analog* amplifier (Class AB) with ~100 mW output power.
Once again we gained a little more understanding of the TWL6040 details...
Well, that low-power mode sounded like MP3 with 128kbps, which is horrible for me ;)
Indeed.
BR, Nikolaus
On 10/16/2014 11:09 AM, Dr. H. Nikolaus Schaller wrote:
The stereo headphone path has a low-power (LP) mode operating from a 32-kHz sleep clock to enable over 100 hours of MP3 playback time. Very-high dynamic range of 104 dBA is achieved when using the system clock input and DAC path high-performance (HP) mode. Class-AB headphone drivers provide a 1Vrms output and are ground centered for capless connection to headphone, thus enabling system size and cost reduction. The earpiece driver is a differential class-AB driver with 2Vrms capability to a typical 32-Ω load or 1.4Vrms to a typical 16-Ω load.
This means the LP mode is indeed optimised for MP3 playback, i.e. not better than MP3 :) Technically it uses the 32kHz signal to derive its internal clocks (17/19MHz) and enables only the headset path (everything else on the chip is disabled and the CPU is not required to provide the 19 MHz clock).
So there should be no audible difference. But I remember that Peter mentioned some issue in the driver.
On omap5-uevm the HPPLL is a bit tricky to use. The clock is sourced from OMAP5 and the clock output is gated by default. Can not recall right away, but it is easy to locate the clock pin on the schema and then look it up in the TRM on how to enable the clock (pinctrl for mux and one bit need to be flipped - AFAIK the bit is in the control module somewhere). I think it worth a try to test the HPPLL mode as well for quality. On PandaBoard the HPPLL mode is available by default.
Also note that we have two 'High Performance / Low Power' modes: One for the PLL and one for the Headset. They are different things.
Hi Peter,
Am 18.10.2014 um 10:56 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
On 10/16/2014 11:09 AM, Dr. H. Nikolaus Schaller wrote:
The stereo headphone path has a low-power (LP) mode operating from a 32-kHz sleep clock to enable over 100 hours of MP3 playback time. Very-high dynamic range of 104 dBA is achieved when using the system clock input and DAC path high-performance (HP) mode. Class-AB headphone drivers provide a 1Vrms output and are ground centered for capless connection to headphone, thus enabling system size and cost reduction. The earpiece driver is a differential class-AB driver with 2Vrms capability to a typical 32-Ω load or 1.4Vrms to a typical 16-Ω load.
This means the LP mode is indeed optimised for MP3 playback, i.e. not better than MP3 :) Technically it uses the 32kHz signal to derive its internal clocks (17/19MHz) and enables only the headset path (everything else on the chip is disabled and the CPU is not required to provide the 19 MHz clock).
So there should be no audible difference. But I remember that Peter mentioned some issue in the driver.
On omap5-uevm the HPPLL is a bit tricky to use. The clock is sourced from OMAP5 and the clock output is gated by default. Can not recall right away, but it is easy to locate the clock pin on the schema and then look it up in the TRM on how to enable the clock (pinctrl for mux and one bit need to be flipped
- AFAIK the bit is in the control module somewhere).
Appears to be CONTROL.CONTROL_CKOBUFFER[28] or CKOBUFFER_CLK_EN := 1
Using devmem2 0x4AE0CDB4 w 0x10000000
and a scope at R87 (near OMAP5 heat sink in direction of audio jacks) shows that clock is then enabled.
Next I have to figure out if and how I can set it by Device Tree.
I think it worth a try to test the HPPLL mode as well for quality. On PandaBoard the HPPLL mode is available by default.
Also note that we have two 'High Performance / Low Power' modes: One for the PLL and one for the Headset. They are different things.
— Péter
BR, Nikolaus
Am 23.10.2014 um 18:54 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Hi Peter,
Am 18.10.2014 um 10:56 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
On 10/16/2014 11:09 AM, Dr. H. Nikolaus Schaller wrote:
The stereo headphone path has a low-power (LP) mode operating from a 32-kHz sleep clock to enable over 100 hours of MP3 playback time. Very-high dynamic range of 104 dBA is achieved when using the system clock input and DAC path high-performance (HP) mode. Class-AB headphone drivers provide a 1Vrms output and are ground centered for capless connection to headphone, thus enabling system size and cost reduction. The earpiece driver is a differential class-AB driver with 2Vrms capability to a typical 32-Ω load or 1.4Vrms to a typical 16-Ω load.
This means the LP mode is indeed optimised for MP3 playback, i.e. not better than MP3 :) Technically it uses the 32kHz signal to derive its internal clocks (17/19MHz) and enables only the headset path (everything else on the chip is disabled and the CPU is not required to provide the 19 MHz clock).
So there should be no audible difference. But I remember that Peter mentioned some issue in the driver.
On omap5-uevm the HPPLL is a bit tricky to use. The clock is sourced from OMAP5 and the clock output is gated by default. Can not recall right away, but it is easy to locate the clock pin on the schema and then look it up in the TRM on how to enable the clock (pinctrl for mux and one bit need to be flipped
- AFAIK the bit is in the control module somewhere).
Appears to be CONTROL.CONTROL_CKOBUFFER[28] or CKOBUFFER_CLK_EN := 1
Using devmem2 0x4AE0CDB4 w 0x10000000
and a scope at R87 (near OMAP5 heat sink in direction of audio jacks) shows that clock is then enabled.
Next I have to figure out if and how I can set it by Device Tree.
Ok, my first shot works:
http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f9788bc7a93eef5c2e8e...
But I did not yet test audio.
I think it worth a try to test the HPPLL mode as well for quality. On PandaBoard the HPPLL mode is available by default.
Also note that we have two 'High Performance / Low Power' modes: One for the PLL and one for the Headset. They are different things.
— Péter
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel