[Arm-netbook] SPDIF on EOMA68 A20

[mike.valk at gmail.com]

2013/11/13 Miguel Angel Ochoa Rodriguez <maochoa at tecnipyme.com>

> >- In event of failure to implement GPIO , I noticed that the photos of
> >The first prototype boards last is eliminated auxiliary bus had on top
>
>
> >The Bus on top is a 44 pin header, 30pins are RGB/TTL, 8 are GPIO, 2 are
> I2C, 2 are RX/Tx, and the last 2 are 5VDC and >GND.
>
> Are you sure in the last EOMA68 A20 Boards have this conector?¿?
>
> In the news Photos of working examples in april and may dont see this
> conector
> http://rhombus-tech.net/allwinner_a10/news/
>
>
> In the case of A20 plate actually incorporates an auxiliary bus 44pins.
>
> It would be possible to extend or modify the bus to enter the i2s??
>

Extending the spec to include i2s or s/p diff requires the SoC to provide
either. Or additional hardware needs to be added to the already cramped
EOMA card. Regardles of the SoC used AllWinner  Axx, Freescale iMX.x,


>
> If I'm right in the project OLINUXINO implemented several lines of cpu
> to the same pin expansion connectors with a choice of system function
> pin
>
> https://github.com/OLIMEX/OLINUXINO
>
> 2013/11/13 luke.leighton <luke.leighton at gmail.com>:
> >> Modifying the specification at this point in the EOMA68 seems unlikely,
> >
> >  not a chance.  audio was one of the first things that was eliminated
> > from putting out over the 68 pins due to there being no clear common
> > audio standard.  it is left to implementors to decide what ICs to
> > place on the I/O board, USB audio being the most sensible and
> > self-contained option.
> >
>
> For us this would be the second option since we have found that using
> converters usb light generated synchronization delays in the video /
> audio. that must be corrected through the player (XBMC - MPlayer).
>

Both PulseAudio has audio delay options for syncing multiple outputs like
network linked pulse audio devices (Like Logitech SqueezeBox, Sonos, etc).
I believe ALSA (drivers) also has(have) delay parameters. Obviously because
expecting every sound source, eg. Mplayer, FireFox, Audacity, VLC, etc., to
sync them selfs is unthinkable.




>
> By contrast, in the tests we've done with CPU integrated SPDIF not
>
have these delays. (Important in case of decoding DTS or DOLBY


S/P Diff does not support DTS-HD/Dolby true HD. Max 192Mhz/24Bit is not
enough bandwith. And a lot of HW only accepts
i2s should be capable but only if all component support such a high
bitrate. I think in i2s no min max bandwith is specified
HDMI audio does support DTS-HD/Dolby true HD.

The only usefull/low cost standard available  left is USB.

Most audiophiles prefer USB because, among the above, it lets you do DAC
outside the digital LF and HF noise environment a computer is.

Yes A/V sync is a b*tch but nothing new. Usually the regular PCI/SoC audio
drivers already contain the correct timings because the position of all
components is sort of fixed. Even in windows. With USB the infrastucture
tends to be a bit more differential, controllers, hubs,  same audio chips
used in different config and pcb layouts.

And thus requires a bit more tinkering.

Good luck!


>  _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20131113/7d988751/attachment.html>