[alsa-devel] Emulated IEC958 Card
Hi,
Ok, so there is already the iec958 plugin, but wouldn't it be nice to have an 'Emulated IEC958-Card' driver that implements implements all the possible components of the IEC958-cum-AES/EBU specification. The user could have the look and feel of a real card via ALSA control and audio i/f .... User Data can be provided too (which lacks in the iec958 plugin ?)
This driver might be boon for low-end embedded devices which have neither IEC958 controller in the SoC nor a codec chip that supports it. In fact the SPDIF controller of one SoC that I know implements only a subset of the standard with limitations.
The only requirement for the emulated-iec958 card would be a shifter with deep enough fifo, that can shift out bits at around 6Mbps (for 48KHz Stereo). And most SoCs have such a resource available that can be put to the use -- OMAP has McBSP, Samsung's and other SoCs can leverage a SPI controller.
Any suggestions welcome.
Regards, Jassi
PS: I start the topic upon insistence from Angat yadi.brar01@gmail.com, a grad student who wanted to implement the feature for his univ project on his beagle board.
On Wed, Sep 15, 2010 at 11:05 PM, Jassi Brar jassisinghbrar@gmail.com wrote:
Hi,
Ok, so there is already the iec958 plugin, but wouldn't it be nice to have an 'Emulated IEC958-Card' driver that implements implements all the possible components of the IEC958-cum-AES/EBU specification. The user could have the look and feel of a real card via ALSA control and audio i/f .... User Data can be provided too (which lacks in the iec958 plugin ?)
This driver might be boon for low-end embedded devices which have neither IEC958 controller in the SoC nor a codec chip that supports it. In fact the SPDIF controller of one SoC that I know implements only a subset of the standard with limitations.
The only requirement for the emulated-iec958 card would be a shifter with deep enough fifo, that can shift out bits at around 6Mbps (for 48KHz Stereo). And most SoCs have such a resource available that can be put to the use -- OMAP has McBSP, Samsung's and other SoCs can leverage a SPI controller.
Any suggestions welcome.
ASoC folks, Mark, Liam, I would really appreciate your take on the idea if you could spare a few moments please. Actually I just might get our AP design folks to implement such a dedicated shifter IP in later SoC. Also, I don't wanna direct the bloke(Angat) in a direction that is outright unacceptable to maintainers -- if it is so.
Thanks
On Fri, Sep 17, 2010 at 09:20:16PM +0900, Jassi Brar wrote:
I would really appreciate your take on the idea if you could spare a few moments please. Actually I just might get our AP design folks to implement such a dedicated shifter IP in later SoC. Also, I don't wanna direct the bloke(Angat) in a direction that is outright unacceptable to maintainers -- if it is so.
The idea of having a full IEC958 emulation layer that just needs a generic serial port or shifter accessed through some standard interface seems entirely sensible. This isn't so different to what things like the McBSP, PXA SSP or FSL SSI ports do.
On Fri, Sep 17, 2010 at 9:27 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Sep 17, 2010 at 09:20:16PM +0900, Jassi Brar wrote:
I would really appreciate your take on the idea if you could spare a few moments please. Actually I just might get our AP design folks to implement such a dedicated shifter IP in later SoC. Also, I don't wanna direct the bloke(Angat) in a direction that is outright unacceptable to maintainers -- if it is so.
The idea of having a full IEC958 emulation layer that just needs a generic serial port or shifter accessed through some standard interface seems entirely sensible. This isn't so different to what things like the McBSP, PXA SSP or FSL SSI ports do.
Yup, I knew those features but am unaware of any situation where they drive out IEC958 - they just run I2S, SPI, TDM (?) Also, IMO, it would make more sense to implement it as a Virtual card independent of ASoC(outside of linux/sound/soc/), with number of devices equalling the number of shifters registered.
Thank you.
On Fri, Sep 17, 2010 at 09:42:46PM +0900, Jassi Brar wrote:
On Fri, Sep 17, 2010 at 9:27 PM, Mark Brown
The idea of having a full IEC958 emulation layer that just needs a generic serial port or shifter accessed through some standard interface seems entirely sensible. This isn't so different to what things like the McBSP, PXA SSP or FSL SSI ports do.
Yup, I knew those features but am unaware of any situation where they drive out IEC958 - they just run I2S, SPI, TDM (?)
Me either, I just meant that this is a well known model for structuring this sort of hardware and software so it should be a good model to follow.
Also, IMO, it would make more sense to implement it as a Virtual card independent of ASoC(outside of linux/sound/soc/), with number of devices equalling the number of shifters registered.
I agree, though it would be nice to have some facility for implementing an interface between the two since you can get IEC958 I/O on ASoC CODECs. I don't think that's needed at first pass, but it may come up at some point.
On Fri, Sep 17, 2010 at 9:47 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Also, IMO, it would make more sense to implement it as a Virtual card independent of ASoC(outside of linux/sound/soc/), with number of devices equalling the number of shifters registered.
I agree, though it would be nice to have some facility for implementing an interface between the two since you can get IEC958 I/O on ASoC CODECs. I don't think that's needed at first pass, but it may come up at some point.
Ok, we'll try to figure that out. Thanks.
participants (2)
-
Jassi Brar -
Mark Brown