[alsa-devel] How to Tx/Rx data via TDM/I2S interface of Intel HD Audio controller without a CODEC attached?
I'm designing software for a specific test application that will utilize an Intel HD audio controller. I must verify the functionality of several sets of TDM audio signals (CK, FS, TXD, RXD) from the Intel HD Audio controller. In this scenario, the Intel HD Audio controller is NOT connected directly to a CODEC, but to a header. My proposal is to connect these signals directly to an FPGA, using it to loopback the data (in various permutations of loopback to channels) to verify each of the signals. Because the FPGA will be in place of a real CODEC device, I'm concerned with how the software side of this approach will work? I essentially just want to push a known bitstream through one TDM interface and verify it upon reception via an alternate TDM interface. This doesn't necessarily require actual audio data. Lastly, I should point out that the system will be tested with it booted to Linux (using a recent kernel 3.x) so utilizing the standard linux audio interfaces (like ALSA - though this isn't a requirement) is preferable to expedite development.
I have spent several hours reading over documentation at the official site and elsewhere, but am left unsure of how to accomplish my goal. I am hopeful it is simply a matter of ALSA configuration, but am not sure if that will suffice, nor how to accomplish it.
The test method (hardware configuration) is unlikely to change, so I'm soliciting any suggestions and information that you all have to enable sending and receiving a specific data stream over the TDM interfaces of the Intel HD Audio controller.
Thanks, -Kelly
Couch, Kelly J wrote:
I'm designing software for a specific test application that will utilize an Intel HD audio controller. I must verify the functionality of several sets of TDM audio signals (CK, FS, TXD, RXD) from the Intel HD Audio controller. In this scenario, the Intel HD Audio controller is NOT connected directly to a CODEC, but to a header. My proposal is to connect these signals directly to an FPGA, using it to loopback the data (in various permutations of loopback to channels) to verify each of the signals.
Let's see what the spec says: | SDO – Serial Data Out: [...] Data is double pumped – i.e., the | controller drives data onto SDO, and codecs sample data present on | SDO with respect to every edge of BCLK. [...] | SDI – Serial Data In: [...] Data is single pumped; codecs drive SDI | and the controller samples SDI with respect to the rising edge of | BCLK.
Oh, and outbound and inbound frames use a different format.
I guess this why you're using an FPGA instead of a wire? :)
Because the FPGA will be in place of a real CODEC device, I'm concerned with how the software side of this approach will work?
The ALSA driver tries to detect the capabilities of the codec(s). You would have to replace all codec read accesses with hardcoded values that describe a virtual codec with a suitable widget topology.
Regards, Clemens
participants (2)
-
Clemens Ladisch
-
Couch, Kelly J