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.