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