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.