[Arm-netbook] Multi-channel audio support
jonsmirl at gmail.com
jonsmirl at gmail.com
Sat Dec 31 16:39:14 GMT 2011
On Sat, Dec 31, 2011 at 10:59 AM, lkcl luke <luke.leighton at gmail.com> wrote:
> On Sat, Dec 31, 2011 at 3:35 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>> I went through the datasheet.
>>
>> The chip does not have:
>> 1) Intel HD audio support (not the same as AC97)
>
> ah, remember that the datasheet is *not* the authoritative source.
> only the source code is truly authoritative as it implements
> everything. take a look through the datasheet and see if you can find
> mention of "SATA" or "PATA" in it.
I would like to know if the chip has Intel HD audio support. Nothing I
am able to look at indicates that it has HD audio support.
>
>> 2) S/PDIF output
>>
>> It does have:
>> 1) Eight high def capable i2s channels (our embedded hardware uses this)
>> 2) Support for slave AC97 CODECs (not a high def solution)
>
> ok, so again (apologies for pointing out that this is the 3rd time of
> asking, jon) - would placing the 8 pins of I2S/AC97 pins on the 44-pin
> expansion header be of assistance to you?
No assistance. We do HD audio, AC97 is not HD capable. We have to use
the eight I2S channels and will design our own PCB to get access to
them.
>
>
>> Final option I know of is HDMI audio output.
>> Does the HDMI output hardware support audio channels?
>
> again, apologies - the source code is the place to look.
>
>
>> If HDMI audio output is the only hidef solution, that's not going to
>> mix well with an LCD. In that case it would make sense to eliminate
>> the headphone jack and reroute that through the connector. Now the LCD
>> and stereo audio support can be done together on the external PCB.
>
> there isn't room, and even if there was it would disrupt the use of
> the 68 pins (the EOMA/PCMCIA standard) for other SoCs. audio simply
> doesn't have a lowest-common-denominator standard that is present
> across hundreds of SoCs. it just doesn't. whatever special audio
> interfaces exist on a per-SoC basis therefore has to go onto any
> expansion headers present on each CPU card or as connectors on the
> front.
>
> i _did_ explain this, jon. i am happy to have someone point out a
> flaw in the logic / reasoning, if they are happy to take into account
> the massive number of factors involved. for a standard to work it has
> to _be_ a standard, with no ambiguity or any either/or options.
> supersets and an extension protocol are ok, but i _do_ have to think
> beyond this one CPU called the allwinner a10.
>
> l.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
--
Jon Smirl
jonsmirl at gmail.com
More information about the arm-netbook
mailing list