Dear OEMA68 developer community .
We are a team of Spanish engineers who are developing a Home Cinema -Media Center to integrate XBMC on Linux on a modular concept .
We thought we had EOMA68 use platform for our project.
But note that not included SPDIF output included in the CPU to one of the GPIO outputs as expecificacion see that the original is not contemplated.
We think that in a Media Center is mandatory to have a SPDIF connection because sometimes only play music and it is interesting to connect the audio DAC you have, no need to convert from HDMI .
My question is ..
The EOMA68 espeficicaciones the A- 20 are closed or else you could ask implement this output to a GPIO ??
- 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 .
It would be possible to go back on the design some kind of signal SPDIF auxiliary bus and maybe some other CPU signal discarded but interesting in specific applications .???
Sincerely Miguel Ochoa Industrial Electronics Technician
Sent from my iPhone
On Nov 12, 2013, at 5:56 PM, Miguel Angel Ochoa Rodriguez maochoa@tecnipyme.com wrote:
Dear OEMA68 developer community .
We are a team of Spanish engineers who are developing a Home Cinema -Media Center to integrate XBMC on Linux on a modular concept .
We thought we had EOMA68 use platform for our project.
But note that not included SPDIF output included in the CPU to one of the GPIO outputs as expecificacion see that the original is not contemplated.
We think that in a Media Center is mandatory to have a SPDIF connection because sometimes only play music and it is interesting to connect the audio DAC you have, no need to convert from HDMI .
My question is ..
The EOMA68 espeficicaciones the A- 20 are closed or else you could ask implement this output to a GPIO ??
The EOMA68 as a STANDARD is open, however, in its current draft, SDIF would have to be provided by an auxiliary/external Audio IC. Repurposing the 8 specified GPIO to SPDIF would make your product NON-EOMA Compliant. Although, I'm not sure, but I think I saw Luke or someone implementing PCM audio via the GPIO, I'm unsure however.
- 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.
.
It would be possible to go back on the design some kind of signal SPDIF auxiliary bus and maybe some other CPU signal discarded but interesting in specific applications .???
Modifying the specification at this point in the EOMA68 seems unlikely, however, Luke is more qualified to answer those questions.
By modifying the spec specifically for SPDIF, you then alienate those who would like to change the spec for some other feature like the 2nd USB HOST, or CANBUS lines. Which can further dilute the standard and cause confusion.
I believe, but could be wrong, that a somewhat work around that has been discussed, but not decided upon is to have some sort of device tree stored in EEPROM or NAND, that has a list of the devices on the board and reprogramming the EOMA68 on insertion.
Again, Luke can correct me if I'm wrong.
That said, have a look at one of our future projects that incorporates a standalone USB Audio IC with USB HUB.
http://rhombus-tech.net/community_ideas/carrier_board/
Sincerely Miguel Ochoa Industrial Electronics Technician
Welcome to the list!
Christopher Thomas Firemoth Industries, LLC - Owner christopher@firemothindustries.com
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
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.
l.
- 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??
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@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).
By contrast, in the tests we've done with CPU integrated SPDIF not have these delays. (Important in case of decoding DTS or DOLBY)
On Wed, Nov 13, 2013 at 12:38 PM, Miguel Angel Ochoa Rodriguez maochoa@tecnipyme.com wrote:
- 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?¿?
they do not.
In the news Photos of working examples in april and may dont see this conector http://rhombus-tech.net/allwinner_a10/news/
that's correct. if you had followed the progress of the project you would know that we found it completely impossible to fit a 44-pin header onto a 73 x 43 mm PCB as well as everything else.
l.
On 11/13/2013 07:38 AM, Miguel Angel Ochoa Rodriguez wrote:
- 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/
Ah, the confusion here is that your talking about two separate parts.The EOMA-A20 is a EOMA-68 CPU card. All functionality it provides is on the 68-pin pcmica connector and those pin-outs are defined in the EOMA-68 Spec.
The 44 pin header that Chris is referring to is on the MEBv1 I/O board for use with a EOMA-68 compliant CPU Card. Those pins are simple break-outs of the pins on the EOMA-68 CPU Card, specially the ones not connect to specialized connectors (USB/SATA/Ethernet). The MEBv1 is an engineering board.
http://www.gplsquared.com/eoma_boot/eoma_boot.html#meb1_case
EOMA-68 CPU Card + I/O Board = Full consumer device.
All unique functionality that makes a consumer device (LCD, VGA, Audio, GPIO Expansion, Buttons... etc) are the responsibility of the I/O board that makes up said device (be it Tablet, Set-top box, Smart Refrigerator, etc..).
So the EOMA-68 spec is fixed in it's functionality, using generic discoverable buses and a little bit of descriptive data on the I/O board to create a full device. The advantage is that as CPU's and ram get better, you don't have to throw out the whole set top box for a new one, just the get a better CPU card.
On 11/13/2013 09:40 AM, Scott Sullivan wrote:
On 11/13/2013 07:38 AM, Miguel Angel Ochoa Rodriguez wrote:
- 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/
More Ah!!!
This is an instance of two people talking about to different things entirely.
Miguel is speaking of this header on the very early prototype A10 card. Which was never part of the spec and not expected to be usable and as such was removed from the later revisions of the EOMA-A20 CPU card.
http://rhombus-tech.net/allwinner_a10/news/2012-12-14.17.22.05.png
Chris listed the break out of the EOMA-68 pins on the MEBv1, as I outline in the previous message.
Ah, the confusion here is that your talking about two separate parts.The EOMA-A20 is a EOMA-68 CPU card. All functionality it provides is on the 68-pin pcmica connector and those pin-outs are defined in the EOMA-68 Spec.
The 44 pin header that Chris is referring to is on the MEBv1 I/O board for use with a EOMA-68 compliant CPU Card. Those pins are simple break-outs of the pins on the EOMA-68 CPU Card, specially the ones not connect to specialized connectors (USB/SATA/Ethernet). The MEBv1 is an engineering board.
http://www.gplsquared.com/eoma_boot/eoma_boot.html#meb1_case
EOMA-68 CPU Card + I/O Board = Full consumer device.
All unique functionality that makes a consumer device (LCD, VGA, Audio, GPIO Expansion, Buttons... etc) are the responsibility of the I/O board that makes up said device (be it Tablet, Set-top box, Smart Refrigerator, etc..).
So the EOMA-68 spec is fixed in it's functionality, using generic discoverable buses and a little bit of descriptive data on the I/O board to create a full device. The advantage is that as CPU's and ram get better, you don't have to throw out the whole set top box for a new one, just the get a better CPU card.
2013/11/13 Miguel Angel Ochoa Rodriguez maochoa@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@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@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Wed, Nov 13, 2013 at 12:38 PM, Miguel Angel Ochoa Rodriguez maochoa@tecnipyme.com wrote:
It would be possible to extend or modify the bus to enter the i2s??
i looked at I2S, and i looked at over 50 SoCs.
1) I2S is not standard enough across enough SoCs in order to guarantee that it will be available. the EOMA68 interfaces were chosen because they have been lowest-common-denominator for well over a decade.
2) although I2S was high on the priority list of interfaces to be added to EOMA68, it was simply too many pins to add (8 if you want to support Dolby multi-channel).
so .... USB (either with a hardware IC or in an Embedded Controller) it had to be.
l.
On Tue, Nov 12, 2013 at 11:56 PM, Miguel Angel Ochoa Rodriguez maochoa@tecnipyme.com wrote:
Dear OEMA68 developer community .
We are a team of Spanish engineers who are developing a Home Cinema -Media Center to integrate XBMC on Linux on a modular concept .
We thought we had EOMA68 use platform for our project.
But note that not included SPDIF output included in the CPU to one of the GPIO outputs as expecificacion see that the original is not contemplated.
correct.
We think that in a Media Center is mandatory to have a SPDIF
i recommend a USB Audio IC that has SPDIF. the CM108AH has SPDIF output and the publicly-available datasheet has a full schematic in it. http://hands.com/~lkcl/eoma/kde_tablet/CM108_DataSheet_v1.6.pdf
l.
arm-netbook@lists.phcomp.co.uk
-
Christopher Thomas -
luke.leighton -
Miguel Angel Ochoa Rodriguez -
mike.valk＠gmail.com -
Scott Sullivan