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).
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.
What I have is:
root@gta04:~# amixer Simple mixer control 'Aux FM',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 7 Front Left: 0 [0%] [-18.00dB] Front Right: 0 [0%] [-18.00dB] Simple mixer control 'Capture',0 Capabilities: cvolume penum Capture channels: Front Left - Front Right Limits: Capture 0 - 4 Front Left: Capture 1 [25%] [12.00dB] Front Right: Capture 1 [25%] [12.00dB] Simple mixer control 'Capture Preamplifier',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 1 Front Left: 1 [100%] [0.00dB] Front Right: 1 [100%] [0.00dB] Simple mixer control 'AUXL',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control 'AUXR',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control 'Analog Left',0 Capabilities: cenum Items: 'Headset Mic' 'Main Mic' 'Aux/FM Left' 'Off' Item0: 'Off' Simple mixer control 'Analog Right',0 Capabilities: cenum Items: 'Headset Mic' 'Sub Mic' 'Aux/FM Right' 'Off' Item0: 'Off' Simple mixer control 'Earphone',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 15 Mono: Playback 0 [0%] [-24.00dB] [off] Simple mixer control 'Handsfree',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 29 Mono: Front Left: Playback 0 [0%] [-52.00dB] Front Right: Playback 0 [0%] [-52.00dB] Simple mixer control 'Handsfree Left Playback',0 Capabilities: enum Items: 'Off' 'HF DAC' 'Line-In amp' Item0: 'Off' Simple mixer control 'Handsfree Right Playback',0 Capabilities: enum Items: 'Off' 'HF DAC' 'Line-In amp' Item0: 'Off' Simple mixer control 'Headset',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 15 Mono: Front Left: Playback 13 [87%] [-4.00dB] Front Right: Playback 13 [87%] [-4.00dB] Simple mixer control 'Headset Left Playback',0 Capabilities: enum Items: 'Off' 'HS DAC' 'Line-In amp' Item0: 'Off' Simple mixer control 'Headset Power Mode',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'Low-Power' Simple mixer control 'Headset Right Playback',0 Capabilities: enum Items: 'Off' 'HS DAC' 'Line-In amp' Item0: 'Off' Simple mixer control 'PLL Selection',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'Low-Power' Simple mixer control 'Vibra Left Playback',0 Capabilities: enum Items: 'Input FF' 'Audio PDM' Item0: 'Input FF' Simple mixer control 'Vibra Right Playback',0 Capabilities: enum Items: 'Input FF' 'Audio PDM' Item0: 'Input FF' root@gta04:~#
So does anyone know a pointer to a simple (command line) setup for the PandaBoard to get sound on the headset jack and the speaker interface (J6) of the PandaBoard ES?
Most likely it should be the same for OMAP5.
BR, Nikolaus
Hi,
On Fri, Sep 19, 2014 at 3:33 PM, Dr. H. Nikolaus Schaller hns@goldelico.com 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).
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).
So you've hit another thing I hate about TWL6040 - it has like a hundred of ALSA controls and is extremely difficult to use as a result.
...
So does anyone know a pointer to a simple (command line) setup for the PandaBoard to get sound on the headset jack and the speaker interface (J6) of the PandaBoard ES?
Most likely it should be the same for OMAP5.
I don't have a PandaBoard, but here's working script for OMAP5 with 3.8 kernel attached, if that helps.
Still it has problems even with that (besides poor quality), like still outputting audio with volume slider set to lowest setting, but at least it works for me.
Am 19.09.2014 um 22:18 schrieb Grazvydas Ignotas:
Hi,
On Fri, Sep 19, 2014 at 3:33 PM, Dr. H. Nikolaus Schaller hns@goldelico.com 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).
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).
So you've hit another thing I hate about TWL6040 - it has like a hundred of ALSA controls and is extremely difficult to use as a result.
18 controls. For speakers, headset, microphone, vibramotor.
...
So does anyone know a pointer to a simple (command line) setup for the PandaBoard to get sound on the headset jack and the speaker interface (J6) of the PandaBoard ES?
Most likely it should be the same for OMAP5.
I don't have a PandaBoard, but here's working script for OMAP5 with 3.8 kernel attached, if that helps.
Yes, it gave me some hints how to make one for the 3.17 kernel. Unfortunately the mixer control names are in constant fluctuations...
Still it has problems even with that (besides poor quality), like still outputting audio with volume slider set to lowest setting, but at least it works for me.
If I read the figures correctly the attenuation can be controlled from -28dB to 6dB for the headphone and -50dB to 6dB in steps.
I think the "perceived loudness" we hear is "double as loud" if the signal energy rises by 10dB. So the earphone can be controlled in a range of 32 dB, i.e. gives a factor 8 in perceived loudness.
This is not enough to nullify any full swing signal waveform... So we have to switch off a channel to really mute it.
Probably this is the reason why the TWL6040 should not be operated stand-alone but in combination with the ABE signal processor on the SoC.
On the other hand - if we want to use the ABE I think we are forced to use the TWL6040 since I am not aware of any other compatible codec.
BR, Nikolaus
On 09/22/2014 07:12 PM, Dr. H. Nikolaus Schaller wrote:
Am 19.09.2014 um 22:18 schrieb Grazvydas Ignotas:
Hi,
On Fri, Sep 19, 2014 at 3:33 PM, Dr. H. Nikolaus Schaller hns@goldelico.com 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).
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).
So you've hit another thing I hate about TWL6040 - it has like a hundred of ALSA controls and is extremely difficult to use as a result.
18 controls. For speakers, headset, microphone, vibramotor.
On a mixer that shows mux switches I get a lot mere, they don't even fit 2 fullhd worth of screen with. Although I'll admit I haven't tried it on 3.17 yet, it's what I had on 3.8.
Still it has problems even with that (besides poor quality), like still outputting audio with volume slider set to lowest setting, but at least it works for me.
If I read the figures correctly the attenuation can be controlled from -28dB to 6dB for the headphone and -50dB to 6dB in steps.
I think the "perceived loudness" we hear is "double as loud" if the signal energy rises by 10dB. So the earphone can be controlled in a range of 32 dB, i.e. gives a factor 8 in perceived loudness.
This is not enough to nullify any full swing signal waveform... So we have to switch off a channel to really mute it.
Probably this is the reason why the TWL6040 should not be operated stand-alone but in combination with the ABE signal processor on the SoC.
And this (+plus the 'plop' problem) effectively means that you'll need a binary blob to have any kind of working audio on Pyra, which sucks.
I know I sound like a broken record, but I don't like this twl6030 solution at all: binary blob, high complexity and difficulty to use even basic features, driver dependencies on frameworks that we may have no permission to use (if I understood Peter correctly).
On the other hand - if we want to use the ABE I think we are forced to use the TWL6040 since I am not aware of any other compatible codec.
Maybe 256fs clock that's coming from twl4030 on pandora could be generated by some dedicated chip. There still seems to be a external clock input pin on OMAP5 called abe_clks that looks similar to mcbsp_clks in use on OMAP3 pandora. According to OMAP5 TRM, MCBSP1 can be clocked by it.
Of course it's risky to try to use something no other board uses, but we did the same with pandora and it worked out in the end..
Grazvydas
On 09/24/2014 10:24 PM, Grazvydas Ignotas wrote:
18 controls. For speakers, headset, microphone, vibramotor.
On a mixer that shows mux switches I get a lot mere, they don't even fit 2 fullhd worth of screen with. Although I'll admit I haven't tried it on 3.17 yet, it's what I had on 3.8.
Yes, you seams to have kernel with AESS/ABE code with the firmware for AESS.
And this (+plus the 'plop' problem) effectively means that you'll need a binary blob to have any kind of working audio on Pyra, which sucks.
I know I sound like a broken record, but I don't like this twl6030 solution at all: binary blob, high complexity and difficulty to use even basic features, driver dependencies on frameworks that we may have no permission to use (if I understood Peter correctly).
Well, I should not say that, but I tend to agree. The audio solution with twl6040 is comlex. It can deliver pretty neat features, but it has it's cost.
On the other hand - if we want to use the ABE I think we are forced to use the TWL6040 since I am not aware of any other compatible codec.
Maybe 256fs clock that's coming from twl4030 on pandora could be generated by some dedicated chip. There still seems to be a external clock input pin on OMAP5 called abe_clks that looks similar to mcbsp_clks in use on OMAP3 pandora. According to OMAP5 TRM, MCBSP1 can be clocked by it.
I know products using OMAP4 with other codec(s) than twl6040 (and AESS is not used by them either). AFAIK we did some counting in the past regarding to available audio connections and you might not have enough to satisfy your needs w/o twl6040. OMAP5 has: 1 x McPDM 1 x DMIC (up to 6 mic) 3 x McBSP, 1 x McASP (4 x serializers, no AFIFO - means it is prone to under/over run)
If you can live with the 3 x McBSP, then you can select whatever codec you want, it should work with it.
The McASP is a bit tricky since I do not even have means to test it, but with a quick look at the registers, I think the davinci-mcasp driver should be able to handle it just fine - in a same way as DRA7, but w/o the FIFO support.
Of course it's risky to try to use something no other board uses, but we did the same with pandora and it worked out in the end..
Am 25.09.2014 um 10:03 schrieb Peter Ujfalusi:
On 09/24/2014 10:24 PM, Grazvydas Ignotas wrote:
18 controls. For speakers, headset, microphone, vibramotor.
On a mixer that shows mux switches I get a lot mere, they don't even fit 2 fullhd worth of screen with. Although I'll admit I haven't tried it on 3.17 yet, it's what I had on 3.8.
Yes, you seams to have kernel with AESS/ABE code with the firmware for AESS.
And this (+plus the 'plop' problem) effectively means that you'll need a binary blob to have any kind of working audio on Pyra, which sucks.
After studying one of the documents we got for the TWL6040 it appears that it should be possible to remove the plop&click (in a system without AESS/ABE) by subtracting some calibration offset that each chip provides and using a specific initialization sequence of DAC and amplifier.
Most likely we need something similar in any system so it is not necessarily something specific to the TWL6040.
I know I sound like a broken record, but I don't like this twl6030 solution at all: binary blob, high complexity and difficulty to use even basic features, driver dependencies on frameworks that we may have no permission to use (if I understood Peter correctly).
Well, I should not say that, but I tend to agree. The audio solution with twl6040 is comlex. It can deliver pretty neat features, but it has it's cost.
IMHO only software cost... Hardware cost is lower wiht TWL6040 than with solutions like OpenPandora (ca. 30 external components instead of 1).
Anyways, if we want non-complex solutions without dependencies we shouldn't build a Pyra at all and stay far away from Linux :)
But this answers only half of the question Notaz has raised:
What about the binary blobs and driver dependencies without permission to use?
On the other hand - if we want to use the ABE I think we are forced to use the TWL6040 since I am not aware of any other compatible codec.
Maybe 256fs clock that's coming from twl4030 on pandora could be generated by some dedicated chip. There still seems to be a external clock input pin on OMAP5 called abe_clks that looks similar to mcbsp_clks in use on OMAP3 pandora. According to OMAP5 TRM, MCBSP1 can be clocked by it.
I know products using OMAP4 with other codec(s) than twl6040 (and AESS is not used by them either). AFAIK we did some counting in the past regarding to available audio connections and you might not have enough to satisfy your needs w/o twl6040. OMAP5 has: 1 x McPDM 1 x DMIC (up to 6 mic) 3 x McBSP, 1 x McASP (4 x serializers, no AFIFO - means it is prone to under/over run)
If I did get the pinmux subtleties right it is even worse: you can't have 1xMcASP and 3xMcBSP in parallel. At most 3 out of 4.
The EVM assigns:
McPDM: TWL6040 McBSP1: BT McBSP2: FM McBSP3: expansion connector (i.e. for external modem)
If you can live with the 3 x McBSP, then you can select whatever codec you want, it should work with it.
That is the issue. We need:
1x for codec (speakers/headset) 1x for 3G/4G modem 1x for digital BT headset 1x for digital FM radio
which one should we leave out?
We can easily serve all of them if the codec for the speakers is the TWL6040.
The McASP is a bit tricky since I do not even have means to test it, but with a quick look at the registers, I think the davinci-mcasp driver should be able to handle it just fine - in a same way as DRA7, but w/o the FIFO support.
For me this looks more complex and risky than copying the circuits of the EVM and taking the existing software. But I am mostly a hardware guy :)
Of course it's risky to try to use something no other board uses, but we did the same with pandora and it worked out in the end..
Well, we should draw decisions based on goals and knowledge, not on lucky experiences :)
@Notaz: What I don't understand is that on one hand you complain about the complexitiy of an existing and apparently working solution. But on the other hand you want to take the risks of a solution that no other board uses. If it doesn't work immediately, we might come up with 10 times complexity to make it work. And might even have to come back to the TWL6040.
BR, Nikolaus
Am Thu, 25 Sep 2014 10:31:18 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
And this (+plus the 'plop' problem) effectively means that you'll need a binary blob to have any kind of working audio on Pyra, which sucks.
After studying one of the documents we got for the TWL6040 it appears that it should be possible to remove the plop&click (in a system without AESS/ABE) by subtracting some calibration offset that each chip provides and using a specific initialization sequence of DAC and amplifier. Most likely we need something similar in any system so it is not necessarily something specific to the TWL6040.
That would be best. I don't want anymore binary blobs as necessary, so if there's a binary blob needed, we need to find another solution.
It's bad enough that we have to use binary blobs for the SGX and Wifi, and probably 3G as well.
But this answers only half of the question Notaz has raised: What about the binary blobs and driver dependencies without permission to use?
I don't want any. What will we do if the codec has some issues with latency or similar? We can't fix it if it's a binary blob, and that was already horrible with the Pandora and Wifi / the SGX.
If you can live with the 3 x McBSP, then you can select whatever codec you want, it should work with it.
That is the issue. We need: 1x for codec (speakers/headset) 1x for 3G/4G modem 1x for digital BT headset 1x for digital FM radio which one should we leave out?
Hm, the Pandora both supports a BT Headset and speakers / headset. How does it work there?
The McASP is a bit tricky since I do not even have means to test it, but with a quick look at the registers, I think the davinci-mcasp driver should be able to handle it just fine - in a same way as DRA7, but w/o the FIFO support.
For me this looks more complex and risky than copying the circuits of the EVM and taking the existing software. But I am mostly a hardware guy :)
Yes, it's more easy in software, and I'm fine with it if there's no closed-source stuff, the audio quality is fine and it can be used withous issues or latency.
Of course it's risky to try to use something no other board uses, but we did the same with pandora and it worked out in the end..
Well, we should draw decisions based on goals and knowledge, not on lucky experiences :)
@Notaz: What I don't understand is that on one hand you complain about the complexitiy of an existing and apparently working solution. But on the other hand you want to take the risks of a solution that no other board uses. If it doesn't work immediately, we might come up with 10 times complexity to make it work. And might even have to come back to the TWL6040.
Complexity doesn't mean we can't do our own stuff. A Burr-Brown DAC connected to the OMAP is no magic thing to code a driver for. Now, if we would use our own 3D hardware and had to code a driver for it, that would be something different, but for a simple DAC...?
Also, using the TWL will probably be more complex than a simple DAC as well. The Pandora is blazing fast (it often feels as fast or even faster than a Cortex A9 Dualcore smartphone!) because we kept it simple.
While designing our own audio set (like on the Pandora) might be more complex in hardware, it could be simpler to use in software than a fully featured chip like the TWL.
We don't want any slowdowns, latencies or higher CPU usage because the audio is more complex than we need.
Hi,
Am 25.09.2014 um 13:08 schrieb Michael Mrozek:
Am Thu, 25 Sep 2014 10:31:18 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
And this (+plus the 'plop' problem) effectively means that you'll need a binary blob to have any kind of working audio on Pyra, which sucks.
After studying one of the documents we got for the TWL6040 it appears that it should be possible to remove the plop&click (in a system without AESS/ABE) by subtracting some calibration offset that each chip provides and using a specific initialization sequence of DAC and amplifier. Most likely we need something similar in any system so it is not necessarily something specific to the TWL6040.
That would be best. I don't want anymore binary blobs as necessary, so if there's a binary blob needed, we need to find another solution.
It's bad enough that we have to use binary blobs for the SGX and Wifi, and probably 3G as well.
But this answers only half of the question Notaz has raised: What about the binary blobs and driver dependencies without permission to use?
I don't want any. What will we do if the codec has some issues with latency or similar? We can't fix it if it's a binary blob, and that was already horrible with the Pandora and Wifi / the SGX.
The question is different: not why we don't want to have them.
But does the TWL6040/AESS need them at all? Are they closed source or not? I don't know yet.
If you can live with the 3 x McBSP, then you can select whatever codec you want, it should work with it.
That is the issue. We need: 1x for codec (speakers/headset) 1x for 3G/4G modem 1x for digital BT headset 1x for digital FM radio which one should we leave out?
Hm, the Pandora both supports a BT Headset and speakers / headset. How does it work there?
1. less McBSP needed 2. enough McBSPs available 3. no 3G/4G
The McASP is a bit tricky since I do not even have means to test it, but with a quick look at the registers, I think the davinci-mcasp driver should be able to handle it just fine - in a same way as DRA7, but w/o the FIFO support.
For me this looks more complex and risky than copying the circuits of the EVM and taking the existing software. But I am mostly a hardware guy :)
Yes, it's more easy in software, and I'm fine with it if there's no closed-source stuff, the audio quality is fine and it can be used withous issues or latency.
Of course it's risky to try to use something no other board uses, but we did the same with pandora and it worked out in the end..
Well, we should draw decisions based on goals and knowledge, not on lucky experiences :)
@Notaz: What I don't understand is that on one hand you complain about the complexitiy of an existing and apparently working solution. But on the other hand you want to take the risks of a solution that no other board uses. If it doesn't work immediately, we might come up with 10 times complexity to make it work. And might even have to come back to the TWL6040.
Complexity doesn't mean we can't do our own stuff. A Burr-Brown DAC connected to the OMAP is no magic thing to code a driver for. Now, if we would use our own 3D hardware and had to code a driver for it, that would be something different, but for a simple DAC...?
Also, using the TWL will probably be more complex than a simple DAC as well.
The TWL is a quite simple DAC. Well, two stereo channels of them. It just has a different audio source interface and amplifiers integrated. And an ADC for microphones and Vibramotor driver. So it looks more complex but it isn't, because it is just 6 chips in one case...
See:
http://www.omappedia.com/images/c/c9/OMAP4_Audio_Phoenix.jpg
and compare (think of these images duplicated for two DAC and two audio amplifiers):
http://www.datasheetlib.com/datasheet/468924/pcm1773_burr-brown.html?page=7#... http://www.datasheetlib.com/datasheet/53150/tpa2016d2_ti-texas-instruments.h...
The Pandora is blazing fast (it often feels as fast or even faster than a Cortex A9 Dualcore smartphone!) because we kept it simple.
This is exactly the argument why we should use ABE/AESS if possible. It is a separate DSP to handle Audio - even if the CPU is shut down.
BTW: using the TWL4030/TPS65950 wouldn't slow down the CPU. The GTA04 uses it without known problems...
Yes, the Nokia N900 didn't use the TWL4030 as well and replaced it by a TLV302AIC34 Codec. I don't know why but it might simply be that the TWL4030 did have bugs the TPS65950 variant has fixed.
While designing our own audio set (like on the Pandora) might be more complex in hardware, it could be simpler to use in software than a fully featured chip like the TWL.
I think Nokia and TI have jointly developed these chips from OMAP1 to OMAP5 with power saving and functionality (audio quality) in mind. And Nokia is not known for bad audio or high power demand or slow devices.
Well, sometimes we just don't know how it was intended to be used. And therefore we don't use it as it was planned. And therefore the audible results may be much worse than the system is from concept. But this is not to blame the chip but our lack of experience.
The additional features the TWL6040 provides are as far as I know: * integrated amplifier and speaker driver * separate channels for headset and speakers * driver for vibramotor and earpiece * ADC for microphone(s) * optimal interface for OMAP5432 * less cost
We don't want any slowdowns, latencies or higher CPU usage because the audio is more complex than we need.
The TWL6040 is a DAC - and does not introduce additional latencies. I wonder where this assumption is coming from?
I think at the moment we are IMHO arguing more on the basis of assumptions and prejudices than knowledge...
This is why I still have on my to-do list to provide a PandaBoard ES based full demo (including one of the speakers). So that you can listen and do measurements.
But such a demo must be carefully set up. Especially if people expect a demo to be better in the first shot than the OpenPandora which had some development time for the audio system... And I have no Pandora to compare and improve the quality until it is better.
BR, Nikolaus
On Thu, Sep 25, 2014 at 3:22 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 25.09.2014 um 13:08 schrieb Michael Mrozek:
Am Thu, 25 Sep 2014 10:31:18 +0200 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
But this answers only half of the question Notaz has raised: What about the binary blobs and driver dependencies without permission to use?
I don't want any. What will we do if the codec has some issues with latency or similar? We can't fix it if it's a binary blob, and that was already horrible with the Pandora and Wifi / the SGX.
The question is different: not why we don't want to have them.
But does the TWL6040/AESS need them at all? Are they closed source or not? I don't know yet.
I'm quite sure AESS does, it's closed source and undocumented, so a binary blob is needed to drive that thing.
If you can live with the 3 x McBSP, then you can select whatever codec you want, it should work with it.
That is the issue. We need: 1x for codec (speakers/headset)
Sure
1x for 3G/4G modem
I thought 3G/4G was just for mobile Internet. From what I read on the forums, not many people are expecting to make calls with pyra, many said to be buying Pyra variant without 3G. I'm sure I never will make calls with my Pyra, there is a phone for that.
1x for digital BT headset
We have that connected on pandora, but it was never used, there is no driver, we don't even know if hardware works. By default bluez is sending audio via UART data link, so nobody ever complained about missing drivers for the mcBSP link.
Do you have BT link on GTA04, is it working? I think this can be safely dropped.
1x for digital FM radio
We don't even know what wifi chip will be used or if it will have FM link. In either case it's not a huge loss, and we can use newer Jorjin chip without FM (if it's finally available).
which one should we leave out?
I think any/all except speakers/headphone can be left out, especially BT.
Hm, the Pandora both supports a BT Headset and speakers / headset. How does it work there?
- less McBSP needed
- enough McBSPs available
- no 3G/4G
The McASP is a bit tricky since I do not even have means to test it, but with a quick look at the registers, I think the davinci-mcasp driver should be able to handle it just fine - in a same way as DRA7, but w/o the FIFO support.
For me this looks more complex and risky than copying the circuits of the EVM and taking the existing software. But I am mostly a hardware guy :)
Yes, it's more easy in software, and I'm fine with it if there's no closed-source stuff, the audio quality is fine and it can be used withous issues or latency.
Of course it's risky to try to use something no other board uses, but we did the same with pandora and it worked out in the end..
Well, we should draw decisions based on goals and knowledge, not on lucky experiences :)
@Notaz: What I don't understand is that on one hand you complain about the complexitiy of an existing and apparently working solution. But on the other hand you want to take the risks of a solution that no other board uses. If it doesn't work immediately, we might come up with 10 times complexity to make it work. And might even have to come back to the TWL6040.
Complexity doesn't mean we can't do our own stuff. A Burr-Brown DAC connected to the OMAP is no magic thing to code a driver for. Now, if we would use our own 3D hardware and had to code a driver for it, that would be something different, but for a simple DAC...?
Also, using the TWL will probably be more complex than a simple DAC as well.
The TWL is a quite simple DAC. Well, two stereo channels of them. It just has a different audio source interface and amplifiers integrated. And an ADC for microphones and Vibramotor driver. So it looks more complex but it isn't, because it is just 6 chips in one case...
Maybe, but the driver regards it as one single chip and that makes it complex. Perhaps multiple drivers for different parts would make the system simpler (divide and conquer), but I'd guess those 6 subchips are strongly related and are not as separate as you portray them here.
[...]
The additional features the TWL6040 provides are as far as I know:
- integrated amplifier and speaker driver
Can that amp drive headphones? Connecting headphones directly to line out does not produce good sound, as seen on OMAP5 EVM.
- separate channels for headset and speakers
Not useful, who'd need to drive different audio through speakers and headphones at the same time? In fact, everyone will expect speakers to just go silent when they connect headphones, as it is on pandora, but now we'll need extra driver to achieve what simple hardware switch used to do.
- driver for vibramotor and earpiece
Not needed features, at least the earpiece thing for sure, IMO..
- ADC for microphone(s)
Mic on pandora is mostly unused..
- optimal interface for OMAP5432
Sounds rather subjective to me.
- less cost
Perhaps, can't comment about that.
We don't want any slowdowns, latencies or higher CPU usage because the audio is more complex than we need.
The TWL6040 is a DAC - and does not introduce additional latencies. I wonder where this assumption is coming from?
But it basically doesn't work without AESS, and that thing is driven by a binary blob and complex multi-layer driver. If there is some problem with the blob, we're screwed (maybe, just maybe Peter would be able to help..).
Granted, if done properly there shouldn't be CPU usage issues, although I wouldn't be surprised if there were latency problems. It's probably tuned for Android's audioflinger which isn't famous for good latency. Yes AESS could probably do things like hardware mixing, but unfortunately things that Linux games use (SDL_mixer or OpenAL-soft and such) can't make use of such things and will just do it all in software, so most AESS features will stay unused all the the time. It's just huge complexity without any benefit compared to dead simple (from software point of view) setup on current pandora.
I think at the moment we are IMHO arguing more on the basis of assumptions and prejudices than knowledge...
The experience of just getting audio working on OMAP5 EVM was enough to get some new phobias for me. Maybe it's just my problem, I don't know, at least I'm not the one who has to make the decision here..
This is why I still have on my to-do list to provide a PandaBoard ES based full demo (including one of the speakers). So that you can listen and do measurements.
But such a demo must be carefully set up. Especially if people expect a demo to be better in the first shot than the OpenPandora which had some development time for the audio system... And I have no Pandora to compare and improve the quality until it is better.
I guess ED should send you one then.
Am 25.09.2014 um 19:16 schrieb Grazvydas Ignotas:
The additional features the TWL6040 provides are as far as I know:
- integrated amplifier and speaker driver
Can that amp drive headphones?
yes.
In fact there are two amplifiers. One for >=16 Ohm headphones and one for >=8 Ohm speakers.
Connecting headphones directly to line out does not produce good sound, as seen on OMAP5 EVM.
Ah, that might explain your experiences.
The EVM has three 3.5mm jacks. One is for Line-IN. One is for Line-OUT. And the third one is for a headset/headphone - optionally with a microphone.
The Line-Out is *not* intended to drive any speaker or headset. It has no low-impedance amplifier and is only intended to drive an external amplifier. The data sheet defines a load resistance of min. 75kOhm.
And although it has differential + and - outputs only the + wire is connected.
So you should connect headsets and speakers to the headset jack. This is connected to the headset driver which can drive min. 16 Ohm and typ. 32 Ohms. This means, you should not connect 8 Ohms speakers to it or the system is run outside of spec.
BR, Nikolaus
Am 25.09.2014 um 19:16 schrieb Grazvydas Ignotas:
1x for 3G/4G modem
I thought 3G/4G was just for mobile Internet. From what I read on the forums, not many people are expecting to make calls with pyra, many said to be buying Pyra variant without 3G. I'm sure I never will make calls with my Pyra, there is a phone for that.
Such a design is always a compromise between people definitively wanting something and not needing everything.
So if you will never make calls it does not mean that there are no people out there who want to (using BT headset or headphone).
Or in other words: I will never play games on the Pyra (because I want to use it as a pocket computer) and therefore don't need any such optimizations like the rotator chip or high-speed LCD or the Nubs. But is that enough reason to leave it out?
I don't think so.
Rather my design guideline is: if we can make something possible we should do it (or someone else will do and have a competitive advantage).
BR, Nikolaus
Am 25.09.2014 um 19:16 schrieb Grazvydas Ignotas:
1x for digital BT headset
We have that connected on pandora, but it was never used, there is no driver, we don't even know if hardware works. By default bluez is sending audio via UART data link, so nobody ever complained about missing drivers for the mcBSP link.
Hm. using UART for transporting sound is introducing a lot of unnecessary load for the CPU and latency...
Do you have BT link on GTA04, is it working?
Yes.
I think this can be safely dropped.
Am Thu, 25 Sep 2014 20:16:10 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
The question is different: not why we don't want to have them. But does the TWL6040/AESS need them at all? Are they closed source or not? I don't know yet.
I'm quite sure AESS does, it's closed source and undocumented, so a binary blob is needed to drive that thing.
Well, that's something we need to check.
Maybe a mixture is possible? If normal audio (for gaming via normal speakers and headphones) works without AESS and binary blob, but 3G/4G and BT Headset needs a binary blob, then I would be fine with that. Those chips need binary blobs anyways.
But I agree that normal operation shouldn't need a binary blob, so normal audio playing, gaming, etc.
1x for 3G/4G modem
I thought 3G/4G was just for mobile Internet. From what I read on the forums, not many people are expecting to make calls with pyra, many said to be buying Pyra variant without 3G. I'm sure I never will make calls with my Pyra, there is a phone for that.
Well, I also won't do phonecalls with it, but I know quite a few people at the GamesCom asked for it. So if easily possible, the sure, but it's not the main priority.
1x for digital BT headset
We have that connected on pandora, but it was never used, there is no driver, we don't even know if hardware works. By default bluez is sending audio via UART data link, so nobody ever complained about missing drivers for the mcBSP link.
The reason not many people use it on the Pandora is simply because it doesn't work properly. I tried it once but didn't get it to work, so that's not a real reason. I agree that gamers won't do it (latency and bad audio quality), but if someone wants to make a phone call, they will probably use a Bluetooth headset for it.
So while not main priority, it would be nice to use.
1x for digital FM radio
We don't even know what wifi chip will be used or if it will have FM link. In either case it's not a huge loss, and we can use newer Jorjin chip without FM (if it's finally available).
Well, that REALLY is low priority, agreed.
which one should we leave out?
I think any/all except speakers/headphone can be left out, especially BT.
If BT works, it would be nice. Streaming music to car radios, using a headset for phone calls would be nice as well.
But as mentioned: Main audio should be simple without binary blobs.
The TWL is a quite simple DAC. Well, two stereo channels of them. It just has a different audio source interface and amplifiers integrated. And an ADC for microphones and Vibramotor driver. So it looks more complex but it isn't, because it is just 6 chips in one case...
Maybe, but the driver regards it as one single chip and that makes it complex. Perhaps multiple drivers for different parts would make the system simpler (divide and conquer), but I'd guess those 6 subchips are strongly related and are not as separate as you portray them here.
Well, what I certainly wouldn't like is tons of audio controls in the mixer. So we need to check upfront whether we can configure the driver to only enable / show what we need.
And even better if we can enable / disable those on the fly, i.e. only show 3G audio control if 3G is enabled, same for BT, etc.
Everything else would be too confusing.
The TWL6040 is a DAC - and does not introduce additional latencies. I wonder where this assumption is coming from?
But it basically doesn't work without AESS, and that thing is driven by a binary blob and complex multi-layer driver. If there is some problem with the blob, we're screwed (maybe, just maybe Peter would be able to help..).
Yep, I don't want binary blobs for the main features as well. That's something we really need to check upfront!
This is why I still have on my to-do list to provide a PandaBoard ES based full demo (including one of the speakers). So that you can listen and do measurements. But such a demo must be carefully set up. Especially if people expect a demo to be better in the first shot than the OpenPandora which had some development time for the audio system... And I have no Pandora to compare and improve the quality until it is better.
I guess ED should send you one then.
I can do that (I thought you had one, but maybe I just planned to send you one).
Here is my suggestion: Right now, we're mostly making assumptions. Maybe the TWL is working fine, maybe it's even worse than we think.
So we should do tests.
As you know, I've got professional audio and video equipment to make proper measurements.
Here's what I'd like to do:
For audio quality:
1. I will create an audio file which includes various tests: Sweep and noise (for testing linearity), some high-end orchestral recordings and some chiptunes (for testing noise and faithful audio reproduction).
2. I will play that file using my video editing suite, the EVM and a Pandora and measure using a professional frequency analyzer. I will record that with a highspeed camera (both audio and video), so we can compare the frequencies of each system and also analyze the recorded audio output directly on a PC.
3. I will do the same with different volume output (Line Out and max headphones output) to see that linearity and quality doesn't change with the amp.
That should be enough.
For latency:
notaz: Could you create a simple tool that will do a small white flash on the screen together with a short beep (100% synchronized) which I can run both on the Pandora and EVM?
I can then record both with a highspeed camera and test the latency.
For those tests to work we need a proper audio driver (without using a binary blob) for the TWL.
Would that be a suggestion?
Hi,
Am 26.09.2014 um 13:12 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 25 Sep 2014 20:16:10 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
The question is different: not why we don't want to have them. But does the TWL6040/AESS need them at all? Are they closed source or not? I don't know yet.
I'm quite sure AESS does, it's closed source and undocumented, so a binary blob is needed to drive that thing.
Well, that's something we need to check.
Maybe a mixture is possible?
I think so. My tests on PandaBoard and EVM did simply run aplay without installing AESS.
If normal audio (for gaming via normal speakers and headphones) works without AESS and binary blob, but 3G/4G and BT Headset needs a binary blob, then I would be fine with that. Those chips need binary blobs anyways.
But I agree that normal operation shouldn't need a binary blob, so normal audio playing, gaming, etc.
The result of my tests and Peter’s comments:
the TWL6040 already works on the EVM and PandaBoard w/o any blob. With Linux from kernel.org w/o any modification.
The only issue I know is that there is a „plop" sound when speakers are enabled (driver / calibration issue).
1x for 3G/4G modem
I thought 3G/4G was just for mobile Internet. From what I read on the forums, not many people are expecting to make calls with pyra, many said to be buying Pyra variant without 3G. I'm sure I never will make calls with my Pyra, there is a phone for that.
Well, I also won't do phonecalls with it, but I know quite a few people at the GamesCom asked for it. So if easily possible, the sure, but it's not the main priority.
1x for digital BT headset
We have that connected on pandora, but it was never used, there is no driver, we don't even know if hardware works. By default bluez is sending audio via UART data link, so nobody ever complained about missing drivers for the mcBSP link.
The reason not many people use it on the Pandora is simply because it doesn't work properly. I tried it once but didn't get it to work, so that's not a real reason. I agree that gamers won't do it (latency and bad audio quality), but if someone wants to make a phone call, they will probably use a Bluetooth headset for it.
So while not main priority, it would be nice to use.
1x for digital FM radio
We don't even know what wifi chip will be used or if it will have FM link. In either case it's not a huge loss, and we can use newer Jorjin chip without FM (if it's finally available).
Well, that REALLY is low priority, agreed.
which one should we leave out?
I think any/all except speakers/headphone can be left out, especially BT.
If BT works, it would be nice. Streaming music to car radios, using a headset for phone calls would be nice as well.
But as mentioned: Main audio should be simple without binary blobs.
The TWL is a quite simple DAC. Well, two stereo channels of them. It just has a different audio source interface and amplifiers integrated. And an ADC for microphones and Vibramotor driver. So it looks more complex but it isn't, because it is just 6 chips in one case...
Maybe, but the driver regards it as one single chip and that makes it complex. Perhaps multiple drivers for different parts would make the system simpler (divide and conquer), but I'd guess those 6 subchips are strongly related and are not as separate as you portray them here.
Well, what I certainly wouldn't like is tons of audio controls in the mixer. So we need to check upfront whether we can configure the driver to only enable / show what we need.
And even better if we can enable / disable those on the fly, i.e. only show 3G audio control if 3G is enabled, same for BT, etc.
Everything else would be too confusing.
That is neither a hardware nor a kernel issue. It is a matter of what and how well thought a GUI displays the mixers.
If it simply shows all controls in a bigtable that is bad GUI design. It should group elements and allow to hide them. Or put them in tabs or whatever.
There are systems that use amixer but don’t even present the mixer controls. The solution is to use „state files“. So the user can choose between 3 or 4 different states (which may include hundreds of fine-tuned mixer settings).
Usually a sophisticated phone has these states: * phone call through earpiece * handsfree phone call * phone call through headset (wired) * phone call through bluetooth * play music * play FM radio
Game console operation is like the play music state.
The TWL6040 is a DAC - and does not introduce additional latencies. I wonder where this assumption is coming from?
But it basically doesn't work without AESS, and that thing is driven by a binary blob and complex multi-layer driver. If there is some problem with the blob, we're screwed (maybe, just maybe Peter would be able to help..).
Yep, I don't want binary blobs for the main features as well. That's something we really need to check upfront!
I hope Peter can comment on that, since he is most experienced with this topic.
This is why I still have on my to-do list to provide a PandaBoard ES based full demo (including one of the speakers). So that you can listen and do measurements. But such a demo must be carefully set up. Especially if people expect a demo to be better in the first shot than the OpenPandora which had some development time for the audio system... And I have no Pandora to compare and improve the quality until it is better.
I guess ED should send you one then.
I can do that (I thought you had one, but maybe I just planned to send you one).
I only have one with broken LCD and disassembled :)
Here is my suggestion: Right now, we're mostly making assumptions. Maybe the TWL is working fine, maybe it's even worse than we think.
So we should do tests.
Exactly. Everything else is poking about in a fog.
As you know, I've got professional audio and video equipment to make proper measurements.
Here's what I'd like to do:
For audio quality:
- I will create an audio file which includes various tests:
Sweep and noise (for testing linearity), some high-end orchestral recordings and some chiptunes (for testing noise and faithful audio reproduction).
Ok.
- I will play that file using my video editing suite, the EVM and
a Pandora and measure using a professional frequency analyzer. I will record that with a highspeed camera (both audio and video), so we can compare the frequencies of each system and also analyze the recorded audio output directly on a PC.
What is the input specification of the analyzer? Is it measuring the signals on a real (or virtual) 8 ohm or 16 ohm speaker connected to it? I ask because the TWL class D amplifier might not show the right signals if operated without a real speaker coil.
Or do you plan to drive a defined speaker with signals and do you measure with a microphone (resembling the tympanum and cochlea)?
So I would suggest:
you define a headset / speakers + measurement microphone in some box.
And the headset / speakers are driven by a) Pandora b) PandaBoard ES (for Headset and Speaker) c) EVM (headset only) d) your video editing suite e) maybe some other devices (e.g. a MP3 player or some Notebook sound card)
The Pyra speakers should ideally be placed in the Pyra Case (with proper box volume).
And it will be interesting to see if there are differences between b) and c)
I ask that because it is very easy to measure something differently from what was planned (or is the real operating condition) if the measuring setup isn’t well designed.
- I will do the same with different volume output (Line Out and max
headphones output) to see that linearity and quality doesn't change with the amp.
That should be enough.
For latency:
notaz: Could you create a simple tool that will do a small white flash on the screen together with a short beep (100% synchronized) which I can run both on the Pandora and EVM?
I can then record both with a highspeed camera and test the latency.
Well, this is nice, but the human brain is very good at hiding or ignoring smaller latencies. So you might optimize something nobody can recognise.
What I mean is this:
http://www.hifi-forum.de/viewthread-42-38.html
They say +/-80 ms is unnoticeable. Well others disagree with that statement and we are not the first ones to think about it:
"http://www.hifi-forum.de/viewthread-42-38.html
Gemäss den Angaben in den Richtlinien der ITU (ITU-R BT.1359-1 App. 1 [1998]) sind Asynchronitäten vom Durchschnittsfernsehzuschauer ab +45/-125ms erkennbar und bis +90/-180ms tolerierbar (plus bedeutet, dass der Ton dem Bild vorausläuft
Yes, I know that the game players are not „Durchschnittsfernsehzuschauer“ :) They are trained to have much better audio-visual sensors than the average…
For those tests to work we need a proper audio driver (without using a binary blob) for the TWL.
Would that be a suggestion?
Yes, looks good to me.
I can prepare the Panda-ES for speakers.
BR, Nikolaus
Hi,
- I will play that file using my video editing suite, the EVM and
a Pandora and measure using a professional frequency analyzer. I will record that with a highspeed camera (both audio and video), so we can compare the frequencies of each system and also analyze the recorded audio output directly on a PC.
What is the input specification of the analyzer? Is it measuring the signals on a real (or virtual) 8 ohm or 16 ohm speaker connected to it? I ask because the TWL class D amplifier might not show the right signals if operated without a real speaker coil.
I can set that up. I'll start with standard Line Out signals, as they should have the exact same levels with the same audio file. (I hope the EVM also has a standard fixed line out as the Pandora has?)
Those should be fine to test the DAC, etc.
For the amplifier, I'll test the headphones port afterwards.
Or do you plan to drive a defined speaker with signals and do you measure with a microphone (resembling the tympanum and cochlea)?
I can additionally test it with a professional audio studio monitor and a Sennheiser ME66 (should be good enough for that).
I can then record both with a highspeed camera and test the latency.
Well, this is nice, but the human brain is very good at hiding or ignoring smaller latencies. So you might optimize something nobody can recognise.
When audio is delayed for more than 20ms, it's clearly noticable (20ms is about a frame in PAL) for trained people. I can easily see that (and if audio comes 10ms too early, it's even more noticable).
One thing that's important: You cannot compare TV to gaming. People in Germany are used to german dubbed movies, so when watching a movie, synchronity isn't that important. For sound effects: It depends. With explosions, you don't notice it, as most people haven't experienced in real life when exactly you can hear the sound of an explosion. Knocking on a door however is different - a 20ms delay, as mentioned, can easily be noticed.
With retro video gaming, this is different. Sound effects (jumping, shooting, etc.) are immediately connected with the user pressing a button. It feels weird if it's delayed - it can even make the game unplayable. I tried adding an artificial delay to Sonic and was way worse when playing it - as I'm used to the immediate jumping sound when pressing the button, so my control wasn't as accurate with a delay.
There will always be a bit of delay, I just want to check that it isn't too bad.
Most modern SoCs are meant for playing music, and gaming isn't as accurate as it was before (because all HDMI devices have a horrible video delay as well), so the delay is of low priority to the manufacturers.
What I mean is this:
http://www.hifi-forum.de/viewthread-42-38.html
They say +/-80 ms is unnoticeable. Well others disagree with that statement and we are not the first ones to think about it:
I know I can notice +10/-20ms, as synchronizing audio to video is something I do almost daily for over 10 years now.
"http://www.hifi-forum.de/viewthread-42-38.html
Gemäss den Angaben in den Richtlinien der ITU (ITU-R BT.1359-1 App. 1 [1998]) sind Asynchronitäten vom Durchschnittsfernsehzuschauer ab +45/-125ms erkennbar und bis +90/-180ms tolerierbar (plus bedeutet, dass der Ton dem Bild vorausläuft
Yes, I know that the game players are not „Durchschnittsfernsehzuschauer“ :) They are trained to have much better audio-visual sensors than the average…
For those tests to work we need a proper audio driver (without using a binary blob) for the TWL.
Would that be a suggestion?
Yes, looks good to me.
I can prepare the Panda-ES for speakers.
BR, Nikolaus
On Fri, Sep 26, 2014 at 2:12 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
Am Thu, 25 Sep 2014 20:16:10 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
1x for digital BT headset
We have that connected on pandora, but it was never used, there is no driver, we don't even know if hardware works. By default bluez is sending audio via UART data link, so nobody ever complained about missing drivers for the mcBSP link.
The reason not many people use it on the Pandora is simply because it doesn't work properly. I tried it once but didn't get it to work, so that's not a real reason.
It's unlikely we can get it to work on Pyra then for the same reasons it now doesn't work on pandora. The hardware is wasted there, more or less.
I agree that gamers won't do it (latency and bad audio quality), but if someone wants to make a phone call, they will probably use a Bluetooth headset for it.
So while not main priority, it would be nice to use.
That would involve steaming the audio from/to 3G though one link and then from/to BT through other link at the same time. We failed to get single link working on pandora, I don't have much hope we can get 2 of them working simultaneously on Pyra, ALSA + generic Linux software is just not good at such things. It would probably be easier to do on Android, but I don't want to touch that.
...
For latency:
notaz: Could you create a simple tool that will do a small white flash on the screen together with a short beep (100% synchronized) which I can run both on the Pandora and EVM?
You can't 100% synchronize them, Linux is not a realtime OS. It also depends heavily on things like ALSA buffer settings, playback trigger thresholds and driver itself. We could test default driver settings and do multiple experiments to rule out differences caused by OS itself, maybe.
I can then record both with a highspeed camera and test the latency.
For those tests to work we need a proper audio driver (without using a binary blob) for the TWL.
I'll need some instructions how to get that working then, i.e. what to do to get aplay to output sound without binary blob available.
Am Fri, 26 Sep 2014 15:50:18 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
1x for digital BT headset
We have that connected on pandora, but it was never used, there is no driver, we don't even know if hardware works. By default bluez is sending audio via UART data link, so nobody ever complained about missing drivers for the mcBSP link.
The reason not many people use it on the Pandora is simply because it doesn't work properly. I tried it once but didn't get it to work, so that's not a real reason.
It's unlikely we can get it to work on Pyra then for the same reasons it now doesn't work on pandora. The hardware is wasted there, more or less.
Well, on the Pandora, we basically made our own OS with OE. I think the reason it doesn't work is because we don't have a proper asound.conf. We've made a very simple one, but for multiple devices, you need some dmix setup, etc.
With Debian, this might work better than with OE, AFAIK they got some automatic asound.conf setup as well.
Also, if it works on the GTA04 with Debian, there shouldn't be a reason we couldn't get it from there.
And about wasted hardware: If it doesn't need a binary blob, needs less parts than Pandoras hardware, AND has an equal sound quality, I don't really care if it's included. Sound quality is something I really need and want to check!
I agree that gamers won't do it (latency and bad audio quality), but if someone wants to make a phone call, they will probably use a Bluetooth headset for it. So while not main priority, it would be nice to use.
That would involve steaming the audio from/to 3G though one link and then from/to BT through other link at the same time. We failed to get single link working on pandora, I don't have much hope we can get 2 of them working simultaneously on Pyra, ALSA + generic Linux software is just not good at such things. It would probably be easier to do on Android, but I don't want to touch that.
Same here. If it works on the GTA04, we can grab stuff from there. And if the TWL works fine, without blob, with the same quality as Pandoras audio, then we could still use it even if we can't get this to work. Someone else could play around with it.
... For latency: notaz: Could you create a simple tool that will do a small white flash on the screen together with a short beep (100% synchronized) which I can run both on the Pandora and EVM?
You can't 100% synchronize them, Linux is not a realtime OS. It also depends heavily on things like ALSA buffer settings, playback trigger thresholds and driver itself. We could test default driver settings and do multiple experiments to rule out differences caused by OS itself, maybe.
Hm, well, ALSA buffer settings could be set to the same on both systems.
Thinking about it: I could also simply run PicoDrive and Sonic Demo on both systems. When I record audio and video and compare the sound output, I would also see if there are huge differences thare.
I can then record both with a highspeed camera and test the latency. For those tests to work we need a proper audio driver (without using a binary blob) for the TWL.
I'll need some instructions how to get that working then, i.e. what to do to get aplay to output sound without binary blob available.
Yes, that's what we need to check out first in any case.
On 09/25/2014 11:31 AM, Dr. H. Nikolaus Schaller wrote:
And this (+plus the 'plop' problem) effectively means that you'll need a binary blob to have any kind of working audio on Pyra, which sucks.
After studying one of the documents we got for the TWL6040 it appears that it should be possible to remove the plop&click (in a system without AESS/ABE) by subtracting some calibration offset that each chip provides and using a specific initialization sequence of DAC and amplifier.
And the OMAP side McPDM IP have registers where you could place the offset values you got from the twl6040. Too bad that it is not working on the McPDM IP level. I think I have already removed that code from the twl6040 codec driver, but not sure.
Most likely we need something similar in any system so it is not necessarily something specific to the TWL6040.
On 09/26/2014 01:31 PM, Peter Ujfalusi wrote:
On 09/25/2014 11:31 AM, Dr. H. Nikolaus Schaller wrote:
And this (+plus the 'plop' problem) effectively means that you'll need a binary blob to have any kind of working audio on Pyra, which sucks.
After studying one of the documents we got for the TWL6040 it appears that it should be possible to remove the plop&click (in a system without AESS/ABE) by subtracting some calibration offset that each chip provides and using a specific initialization sequence of DAC and amplifier.
And the OMAP side McPDM IP have registers where you could place the offset values you got from the twl6040. Too bad that it is not working on the McPDM IP level. I think I have already removed that code from the twl6040 codec driver, but not sure.
I mean from the omap-mcpdm driver...
Most likely we need something similar in any system so it is not necessarily something specific to the TWL6040.
Hi Peter,
Am 26.09.2014 um 12:37 schrieb Peter Ujfalusi peter.ujfalusi@TI.COM:
On 09/26/2014 01:31 PM, Peter Ujfalusi wrote:
On 09/25/2014 11:31 AM, Dr. H. Nikolaus Schaller wrote:
And this (+plus the 'plop' problem) effectively means that you'll need a binary blob to have any kind of working audio on Pyra, which sucks.
After studying one of the documents we got for the TWL6040 it appears that it should be possible to remove the plop&click (in a system without AESS/ABE) by subtracting some calibration offset that each chip provides and using a specific initialization sequence of DAC and amplifier.
And the OMAP side McPDM IP have registers where you could place the offset values you got from the twl6040. Too bad that it is not working on the McPDM IP level. I think I have already removed that code from the twl6040 codec driver, but not sure.
I mean from the omap-mcpdm driver…
does that mean that there is some errata or why was it removed? It looks as if it is the missing piece for solving the click&pop issue of the panda/evm?
BTW: is it the same on OMAP4 and OMAP5?
BR, Nikolaus
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.
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. 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.
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)
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.
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 :(
So does anyone know a pointer to a simple (command line) setup for the PandaBoard to get sound on the headset jack and the speaker interface (J6) of the PandaBoard ES?
Most likely it should be the same for OMAP5.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
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
On 09/22/2014 06:44 PM, Dr. H. Nikolaus Schaller wrote:
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.
The 'plop' is known side effect of using dumb McPDM <-> twl6040. OMAP4 and twl6040 was developed together to provide a solution: McPDM is a new protocol only used by OMAP4/5. In short: there's a 'feature' in twl6040 that it interprets the the signal on the bus as data when OMAP stats to take it over. The 'plop' can only be fixed if you are using AESS. With AESS in use the stream starts and stops are silent and you have native support for wider array of sampling frequencies, separate PCMs for Headset, Handsfree, low-power playback mode (called ping-pong) signal mixing (tone, music).
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.
Sounds great!
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
HI,
Am 23.09.2014 um 10:40 schrieb Peter Ujfalusi:
On 09/22/2014 06:44 PM, Dr. H. Nikolaus Schaller wrote:
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.
The 'plop' is known side effect of using dumb McPDM <-> twl6040. OMAP4 and twl6040 was developed together to provide a solution: McPDM is a new protocol only used by OMAP4/5. In short: there's a 'feature' in twl6040 that it interprets the the signal on the bus as data when OMAP stats to take it over. The 'plop' can only be fixed if you are using AESS. With AESS in use the stream starts and stops are silent and you have native support for wider array of sampling frequencies, separate PCMs for Headset, Handsfree, low-power playback mode (called ping-pong) signal mixing (tone, music).
Ok, I see.
Well, for general hardware testing the plop could be acceptable if we know that it vanishes by using AESS.
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.
Sounds great!
I have now also tested on the OMAP5432EVM (after fixing the .config and not using the high performance PLL mode).
Strangely I only get mono and no stereo but the test sounds appear to be crisp and very clear (on the headset jack only of course).
BR, Nikolaus
On 09/23/2014 07:05 PM, Dr. H. Nikolaus Schaller wrote:
I have now also tested on the OMAP5432EVM (after fixing the .config and not using the high performance PLL mode).
Strangely I only get mono and no stereo but the test sounds appear to be crisp and very clear (on the headset jack only of course).
Just checked with 3.17.0-rc6-00180-g452b6361c4d9 on omap5-uevm and I have distinct channels on the AUX outputs. Playing 4channel wav with sine wave on ch1 and ch3, ch2 and ch4 is silent.
Am 24.09.2014 um 11:17 schrieb Peter Ujfalusi:
On 09/23/2014 07:05 PM, Dr. H. Nikolaus Schaller wrote:
I have now also tested on the OMAP5432EVM (after fixing the .config and not using the high performance PLL mode).
Strangely I only get mono and no stereo but the test sounds appear to be crisp and very clear (on the headset jack only of course).
Just checked with 3.17.0-rc6-00180-g452b6361c4d9 on omap5-uevm and I have distinct channels on the AUX outputs. Playing 4channel wav with sine wave on ch1 and ch3, ch2 and ch4 is silent.
Ah, that is the explanation. My stereo sound is 2 channel only. Goes to ch1&2...
So I should try to expand/rearrange channels with sox.
BR and thanks, Nikolaus