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