Hi, I have studied the OMAP5 docs a little more and the ABE is more or less what the DSP in the OMAP3 could have been used for: shutting down the CPU and running audio functions autonomously.
Here is the block diagram:
Unfortunately this has some consequences: * there are only 3 McBSP ports - we need them all for: Bluetooth, FM-Radio, UMTS modem * the codec port is a McPDM - which is a TI proprietary format (on OMAP3+TWL4030 it was a PCM channel) * the only MCPDM compatible codecs appear to be the TWL6040/6041 * I am not sure if the ABE-Firmware for the "AE" is a binary BLOB or just some control settings - so some Freedom enthusiasts may complain about that
This means: * if we want to use the ABE (to save power while playing sound or phoning around) we must use the TWL604x * if we don't use it we maybe can use the McASP for I2S * if we don't use it we have to write a lot of software to make audio work * if we use the TWL604x it must very likely be placed on the CPU board (HDI/micro via multilayer) - which means we must route audio over the B2B connectors (which isn't a big problem for speakers but maybe for headphone, microphone and line-in) * if we use the TWL604x we can't use the simple potentiometer for loudness control as in the OpenPandora but must do that with buttons and in software (maybe one of the Cortex-M4 cores can control that even if the A15 system hangs?)
Hm. I think this needs much more thoughs and discussions than is urgent for the next Pyra Prototype (which will *not* have the real CPU board, just an adapter to the EVM - so it will not yet have a working audio subsystem).
So I think the best will be to just (temporarily?) add a Class D amplifier (LM4666) for Protoype Version 3 so that we can at least test the speakers in their enclosure.
BR, Nikolaus
Hi,
On 03/16/2014 10:43 AM, Dr. H. Nikolaus Schaller wrote:
Hi, I have studied the OMAP5 docs a little more and the ABE is more or less what the DSP in the OMAP3 could have been used for: shutting down the CPU and running audio functions autonomously.
ABE stands for Audio Back End and it consists of AESS or AE (Audio Engine SubSystem), McPDM, McBSP, DMIC, McASP.
Yes in essence AESS is a DSP. It can move data around, do resampling, mixing, etc.
Unfortunately this has some consequences:
- there are only 3 McBSP ports - we need them all for: Bluetooth, FM-Radio,
UMTS modem
- the codec port is a McPDM - which is a TI proprietary format (on
OMAP3+TWL4030 it was a PCM channel)
- the only MCPDM compatible codecs appear to be the TWL6040/6041
- I am not sure if the ABE-Firmware for the "AE" is a binary BLOB or just some
control settings - so some Freedom enthusiasts may complain about that
It is a blob, yes. It contains the AESS binary and it also contains additional information like audio controls, routes, etc. In a same way as most WiFi cards have Firmware we need to load the DSP code to the AESS to be able to use it.
The code to support AESS is not yet upstream. It has dependency on ASoC Dynamic Firmware.
I'm maintaining the AESS support (only OMAP4 is tested, OMAP5 should not be hard to get it working) here: https://gitorious.org/omap-audio/linux-audio The branch 'next-bnw/ti-audio-next-3.13' is the latest rebase I did, I'm planning to do this for the 3.14 as well soon. The base-bnw/* branches are just topic branches and they are merged to form the next-bnw/* snapshots and also my personal working branch: peter/topic/ti-audio-next-bnw-wip (which is the same as the 3.13 snapshot currently).
The firmware is not in there, I think I'm going to place it and push that as well.
This means:
- if we want to use the ABE (to save power while playing sound or phoning
around) we must use the TWL604x
Also AESS helps with resampling, routing, mixing. With McPDM/twl6040 (no AESS) for example if you want to play audio to the speaker (or line-out) you need to play 4 channel audio and place the stereo data to channel 3 and 4. Channel 1 and 2 is going to Headset/Earpiece. With AESS you would have separate PCM for this so you do not need to care about this. There are other things as well, but can not recall them all.
- if we don't use it we maybe can use the McASP for I2S
Note that McASP is only TX, it can not receive data. It also lacks AFIFO which can cause audio underruns when the system is stressed...
- if we don't use it we have to write a lot of software to make audio work
- if we use the TWL604x it must very likely be placed on the CPU board
(HDI/micro via multilayer) - which means we must route audio over the B2B connectors (which isn't a big problem for speakers but maybe for headphone, microphone and line-in)
- if we use the TWL604x we can't use the simple potentiometer for loudness
control as in the OpenPandora but must do that with buttons and in software (maybe one of the Cortex-M4 cores can control that even if the A15 system hangs?)
Hm. I think this needs much more thoughs and discussions than is urgent for the next Pyra Prototype (which will *not* have the real CPU board, just an adapter to the EVM - so it will not yet have a working audio subsystem).
So I think the best will be to just (temporarily?) add a Class D amplifier (LM4666) for Protoype Version 3 so that we can at least test the speakers in their enclosure.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi Peter, thanks for these clarifications! This confirms that we have to think more about it to find the best compromise...
Am 17.03.2014 um 11:09 schrieb Peter Ujfalusi:
Hi,
On 03/16/2014 10:43 AM, Dr. H. Nikolaus Schaller wrote:
Hi, I have studied the OMAP5 docs a little more and the ABE is more or less what the DSP in the OMAP3 could have been used for: shutting down the CPU and running audio functions autonomously.
ABE stands for Audio Back End and it consists of AESS or AE (Audio Engine SubSystem), McPDM, McBSP, DMIC, McASP.
Yes in essence AESS is a DSP. It can move data around, do resampling, mixing, etc.
Unfortunately this has some consequences:
- there are only 3 McBSP ports - we need them all for: Bluetooth, FM-Radio,
UMTS modem
- the codec port is a McPDM - which is a TI proprietary format (on
OMAP3+TWL4030 it was a PCM channel)
- the only MCPDM compatible codecs appear to be the TWL6040/6041
- I am not sure if the ABE-Firmware for the "AE" is a binary BLOB or just some
control settings - so some Freedom enthusiasts may complain about that
It is a blob, yes. It contains the AESS binary and it also contains additional information like audio controls, routes, etc. In a same way as most WiFi cards have Firmware we need to load the DSP code to the AESS to be able to use it.
The code to support AESS is not yet upstream. It has dependency on ASoC Dynamic Firmware.
Ok! I think we will needs some time until we have the Pyra hardware to test things. So maybe mainline will be 3.16 or 3.18 when the Pyra is finalized.
I'm maintaining the AESS support (only OMAP4 is tested, OMAP5 should not be hard to get it working) here: https://gitorious.org/omap-audio/linux-audio The branch 'next-bnw/ti-audio-next-3.13' is the latest rebase I did, I'm planning to do this for the 3.14 as well soon. The base-bnw/* branches are just topic branches and they are merged to form the next-bnw/* snapshots and also my personal working branch: peter/topic/ti-audio-next-bnw-wip (which is the same as the 3.13 snapshot currently).
The firmware is not in there, I think I'm going to place it and push that as well.
Yes, tracing the firmware is a little difficult. There appears to be an Ubuntu package.
This means:
- if we want to use the ABE (to save power while playing sound or phoning
around) we must use the TWL604x
Also AESS helps with resampling, routing, mixing. With McPDM/twl6040 (no AESS) for example if you want to play audio to the speaker (or line-out) you need to play 4 channel audio and place the stereo data to channel 3 and 4. Channel 1 and 2 is going to Headset/Earpiece. With AESS you would have separate PCM for this so you do not need to care about this. There are other things as well, but can not recall them all.
- if we don't use it we maybe can use the McASP for I2S
Note that McASP is only TX, it can not receive data. It also lacks AFIFO which can cause audio underruns when the system is stressed...
Oh, that is good to know! So we will only have 3 McBSPs we need for * Audio codec (speaker/line) * Modem * Bluetooth (headset) * FM radio
So we have to sacrifice one. Unless we can use the McPDM interface for Audio codec.
- if we don't use it we have to write a lot of software to make audio work
- if we use the TWL604x it must very likely be placed on the CPU board
(HDI/micro via multilayer) - which means we must route audio over the B2B connectors (which isn't a big problem for speakers but maybe for headphone, microphone and line-in)
Well, it would be more flexible to have the audio codec on the CPU board. Then, people can develop other boards and choose their own codec scheme that best fits to the CPU.
- if we use the TWL604x we can't use the simple potentiometer for loudness
control as in the OpenPandora but must do that with buttons and in software
That is something ED must comment on...
(maybe one of the Cortex-M4 cores can control that even if the A15 system hangs?)
Hm. I think this needs much more thoughs and discussions than is urgent for the next Pyra Prototype (which will *not* have the real CPU board, just an adapter to the EVM - so it will not yet have a working audio subsystem).
So I think the best will be to just (temporarily?) add a Class D amplifier (LM4666) for Protoype Version 3 so that we can at least test the speakers in their enclosure.
BR, Nikolaus
BR, Nikolaus
On 03/18/2014 10:11 AM, Dr. H. Nikolaus Schaller wrote:
It is a blob, yes. It contains the AESS binary and it also contains additional information like audio controls, routes, etc. In a same way as most WiFi cards have Firmware we need to load the DSP code to the AESS to be able to use it.
The code to support AESS is not yet upstream. It has dependency on ASoC Dynamic Firmware.
Ok! I think we will needs some time until we have the Pyra hardware to test things. So maybe mainline will be 3.16 or 3.18 when the Pyra is finalized.
I hope the AESS support will be upstream by that time. I do have dependencies like I mentioned the ASoC dynamic firmware. Other thing for OMAP5 is the Palmas clock driver (twl6040's clock is coming from Palmas usually).
I'm maintaining the AESS support (only OMAP4 is tested, OMAP5 should not be hard to get it working) here: https://gitorious.org/omap-audio/linux-audio The branch 'next-bnw/ti-audio-next-3.13' is the latest rebase I did, I'm planning to do this for the 3.14 as well soon. The base-bnw/* branches are just topic branches and they are merged to form the next-bnw/* snapshots and also my personal working branch: peter/topic/ti-audio-next-bnw-wip (which is the same as the 3.13 snapshot currently).
The firmware is not in there, I think I'm going to place it and push that as well.
Yes, tracing the firmware is a little difficult. There appears to be an Ubuntu package.
I just pushed the firmware to git://gitorious.org/omap-audio/linux-audio.git base-bnw/aess-firmware and git://gitorious.org/omap-audio/linux-audio.git next-bnw/ti-audio-next_3.13
it is the firmware/omap-aess-adfw.bin
This is a new firmware, I have fixed couple of long standing bugs with it and one should not mix up the firmwares. As a sidenote: Ubuntu is using the old version of FW and AESS/ABE code while the code I have in gitorious went through several clean up rounds and stuff. The whole code layout is different, etc.
This means:
- if we want to use the ABE (to save power while playing sound or phoning
around) we must use the TWL604x
Also AESS helps with resampling, routing, mixing. With McPDM/twl6040 (no AESS) for example if you want to play audio to the speaker (or line-out) you need to play 4 channel audio and place the stereo data to channel 3 and 4. Channel 1 and 2 is going to Headset/Earpiece. With AESS you would have separate PCM for this so you do not need to care about this. There are other things as well, but can not recall them all.
- if we don't use it we maybe can use the McASP for I2S
Note that McASP is only TX, it can not receive data. It also lacks AFIFO which can cause audio underruns when the system is stressed...
Oh, that is good to know! So we will only have 3 McBSPs we need for
- Audio codec (speaker/line)
- Modem
- Bluetooth (headset)
- FM radio
If you only plan to have FM transmitter than: McASP - FM tx McBSP1,2,3 - codec, modem, BT
and you do not need AESS.
Oh, one more note about McASP. We do not have driver upstream for it. Android have omap-mcasp driver (used in Galaxy Nexus for S/PDIF on the dock). The main issue with the OMAP4/5 McASP is that I do not have HW where I could test it. In theory however the davinci-mcasp driver can be reused. The IP is derived from there, only some features are missing (RX, AFIFO).
So we have to sacrifice one. Unless we can use the McPDM interface for Audio codec.
I hope you do not need to make too big compromises. I try to upstream the needed parts for audio on time so you will be able to utilize it. But it is good to have backup plan...
Hi,
Sorry to ping an old thread, but I have some updates and correction regarding to audio: In omap534x ES2.0 McASP can be used for transmit and receive mode with 4 available serializers. It does not have AFIFO to aim McASP so data underrun/overrun can be an issue. This gives: 3x McBSP ports and 1 McASP can be used to connect any codec with I2S/TDM. McASP can also be used for S/PDIF.
There's one BUT for McASP: we do not have driver for it but I think the current davinci-mcasp driver should just work with the OMAP5 version. The problem here is that we do not have any device where this can be tested.
As for the McPDM/twl6040 with AESS/ABE support: I have it running on top of 3.14 on OMAP4/5. In upstream it might still take some time since it needs ASoC DFW which is not yet even sent to upstream. The good news with DFW is that it is not going to be much different in upstream compared to what I have so it should not be a big effort to have AESS/ABE support upstreamed soon after DFW is available.
Regards, Péter
On 03/18/2014 11:01 AM, Peter Ujfalusi wrote:
On 03/18/2014 10:11 AM, Dr. H. Nikolaus Schaller wrote:
It is a blob, yes. It contains the AESS binary and it also contains additional information like audio controls, routes, etc. In a same way as most WiFi cards have Firmware we need to load the DSP code to the AESS to be able to use it.
The code to support AESS is not yet upstream. It has dependency on ASoC Dynamic Firmware.
Ok! I think we will needs some time until we have the Pyra hardware to test things. So maybe mainline will be 3.16 or 3.18 when the Pyra is finalized.
I hope the AESS support will be upstream by that time. I do have dependencies like I mentioned the ASoC dynamic firmware. Other thing for OMAP5 is the Palmas clock driver (twl6040's clock is coming from Palmas usually).
I'm maintaining the AESS support (only OMAP4 is tested, OMAP5 should not be hard to get it working) here: https://gitorious.org/omap-audio/linux-audio The branch 'next-bnw/ti-audio-next-3.13' is the latest rebase I did, I'm planning to do this for the 3.14 as well soon. The base-bnw/* branches are just topic branches and they are merged to form the next-bnw/* snapshots and also my personal working branch: peter/topic/ti-audio-next-bnw-wip (which is the same as the 3.13 snapshot currently).
The firmware is not in there, I think I'm going to place it and push that as well.
Yes, tracing the firmware is a little difficult. There appears to be an Ubuntu package.
I just pushed the firmware to git://gitorious.org/omap-audio/linux-audio.git base-bnw/aess-firmware and git://gitorious.org/omap-audio/linux-audio.git next-bnw/ti-audio-next_3.13
it is the firmware/omap-aess-adfw.bin
This is a new firmware, I have fixed couple of long standing bugs with it and one should not mix up the firmwares. As a sidenote: Ubuntu is using the old version of FW and AESS/ABE code while the code I have in gitorious went through several clean up rounds and stuff. The whole code layout is different, etc.
This means:
- if we want to use the ABE (to save power while playing sound or phoning
around) we must use the TWL604x
Also AESS helps with resampling, routing, mixing. With McPDM/twl6040 (no AESS) for example if you want to play audio to the speaker (or line-out) you need to play 4 channel audio and place the stereo data to channel 3 and 4. Channel 1 and 2 is going to Headset/Earpiece. With AESS you would have separate PCM for this so you do not need to care about this. There are other things as well, but can not recall them all.
- if we don't use it we maybe can use the McASP for I2S
Note that McASP is only TX, it can not receive data. It also lacks AFIFO which can cause audio underruns when the system is stressed...
Oh, that is good to know! So we will only have 3 McBSPs we need for
- Audio codec (speaker/line)
- Modem
- Bluetooth (headset)
- FM radio
If you only plan to have FM transmitter than: McASP - FM tx McBSP1,2,3 - codec, modem, BT
and you do not need AESS.
Oh, one more note about McASP. We do not have driver upstream for it. Android have omap-mcasp driver (used in Galaxy Nexus for S/PDIF on the dock). The main issue with the OMAP4/5 McASP is that I do not have HW where I could test it. In theory however the davinci-mcasp driver can be reused. The IP is derived from there, only some features are missing (RX, AFIFO).
So we have to sacrifice one. Unless we can use the McPDM interface for Audio codec.
I hope you do not need to make too big compromises. I try to upstream the needed parts for audio on time so you will be able to utilize it. But it is good to have backup plan...