[alsa-devel] Feasibility of adding alternative audio transport besides I2S/PWM/SPDIF, etc
Hi All, I'm in a constant struggle to bring up many channel audio on each separate SoC.
I can easily put a microcontroller in place that will collect and distrubute all the TDM channels to the codecs, and connect the hardware via an SPI interface to the SoC.
So, instead of:
CODECS <---TDM---> SoC
It would be
CODECS <---TDM---> uC <---SPI---> SoC
So, my questions are:
* I suspect the SPI interface could be used more universally than each individual I2S/TDM interface (like FSL SSI vs. Ti McBSP vs. Ti McASP, etc). and the SPI port would provide a very common API regardless of SoC. Is that true?
* Is it feasible to integrate an SPI transport into the SoC/alsa layer? What are the difficulties involved with that?
Cheers, -Caleb
On Thu, 2015-10-08 at 08:51 -0700, Caleb Crome wrote:
Hi All, I'm in a constant struggle to bring up many channel audio on each separate SoC.
I can easily put a microcontroller in place that will collect and distrubute all the TDM channels to the codecs, and connect the hardware via an SPI interface to the SoC.
So, instead of:
CODECS <---TDM---> SoC
It would be
CODECS <---TDM---> uC <---SPI---> SoC
So, my questions are:
- I suspect the SPI interface could be used more universally than each
individual I2S/TDM interface (like FSL SSI vs. Ti McBSP vs. Ti McASP, etc). and the SPI port would provide a very common API regardless of SoC. Is that true?
Some SPI ports could probably be used for audio, but this depends on the SPI port HW capabilities. e.g. the SSP port on minnowboard can be configured for TDM, I2S and SPI (afaik). I don't think any advantage could be gained from running in SPI mode unless your HW permits some special features ?
- Is it feasible to integrate an SPI transport into the SoC/alsa
layer? What are the difficulties involved with that?
Yes, that's doable providing the SPI port is capable of supporting audio formats and has good DMA connectivity. A DAI driver would need to be written for your SPI port to allow it to send audio data within ASoC.
Liam
Cheers, -Caleb
On Fri, Oct 9, 2015 at 2:34 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Thu, 2015-10-08 at 08:51 -0700, Caleb Crome wrote:
Hi All, I'm in a constant struggle to bring up many channel audio on each separate SoC.
I can easily put a microcontroller in place that will collect and distrubute all the TDM channels to the codecs, and connect the hardware via an SPI interface to the SoC.
So, instead of:
CODECS <---TDM---> SoC
It would be
CODECS <---TDM---> uC <---SPI---> SoC
So, my questions are:
- I suspect the SPI interface could be used more universally than each
individual I2S/TDM interface (like FSL SSI vs. Ti McBSP vs. Ti McASP, etc). and the SPI port would provide a very common API regardless of SoC. Is that true?
Some SPI ports could probably be used for audio, but this depends on the SPI port HW capabilities. e.g. the SSP port on minnowboard can be configured for TDM, I2S and SPI (afaik). I don't think any advantage could be gained from running in SPI mode unless your HW permits some special features ?
Sorry, I wasn't clear. The point is to use the 'generic' SPI API in the linux kernel to stream the data, and *not* use an audio format. So, the idea is, the external micro would buffer up a block of data, (in our case, maybe 160 samples * 32 channels = 10 kBytes), then use the SPI port to read and write to the micro as if it were a memory or something like that to transfer the data. So the external micro would appear to the CPU as an external register bank, and would do all the audio aggregation.
I was hoping that would provide a pretty much universal means of getting many channels of data into and out of pretty much any SoC that has an SPI port capable of the requisite speed.
Does that make sense?
I guess there would be an interrupt line from the micro->SoC that says, "data ready". When that's triggered, the SPI bus just goes and reads 160 samples x 32 channels x 2 bytes, and writes as many as needed to satisfy the given application.
- Is it feasible to integrate an SPI transport into the SoC/alsa
layer? What are the difficulties involved with that?
Yes, that's doable providing the SPI port is capable of supporting audio formats and has good DMA connectivity. A DAI driver would need to be written for your SPI port to allow it to send audio data within ASoC.
Right. That's the bit I'm pretty clueless on.
Liam
Cheers, -Caleb
+ Mark
On Fri, 2015-10-09 at 09:11 -0700, Caleb Crome wrote:
On Fri, Oct 9, 2015 at 2:34 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Thu, 2015-10-08 at 08:51 -0700, Caleb Crome wrote:
Hi All, I'm in a constant struggle to bring up many channel audio on each separate SoC.
I can easily put a microcontroller in place that will collect and distrubute all the TDM channels to the codecs, and connect the hardware via an SPI interface to the SoC.
So, instead of:
CODECS <---TDM---> SoC
It would be
CODECS <---TDM---> uC <---SPI---> SoC
So, my questions are:
- I suspect the SPI interface could be used more universally than each
individual I2S/TDM interface (like FSL SSI vs. Ti McBSP vs. Ti McASP, etc). and the SPI port would provide a very common API regardless of SoC. Is that true?
Some SPI ports could probably be used for audio, but this depends on the SPI port HW capabilities. e.g. the SSP port on minnowboard can be configured for TDM, I2S and SPI (afaik). I don't think any advantage could be gained from running in SPI mode unless your HW permits some special features ?
Sorry, I wasn't clear. The point is to use the 'generic' SPI API in the linux kernel to stream the data, and *not* use an audio format. So, the idea is, the external micro would buffer up a block of data, (in our case, maybe 160 samples * 32 channels = 10 kBytes), then use the SPI port to read and write to the micro as if it were a memory or something like that to transfer the data. So the external micro would appear to the CPU as an external register bank, and would do all the audio aggregation.
Ok, so this sounds like a burst based DAI where the host sends audio data in bursts then sleeps. I think this has been done by some codec vendors, but I dont know if any code is upstream.
I was hoping that would provide a pretty much universal means of getting many channels of data into and out of pretty much any SoC that has an SPI port capable of the requisite speed.
Does that make sense?
Yes, just need to make sure that your SPI port has low latency and enough bandwidth and I think you should be OK.
Liam
I guess there would be an interrupt line from the micro->SoC that says, "data ready". When that's triggered, the SPI bus just goes and reads 160 samples x 32 channels x 2 bytes, and writes as many as needed to satisfy the given application.
- Is it feasible to integrate an SPI transport into the SoC/alsa
layer? What are the difficulties involved with that?
Yes, that's doable providing the SPI port is capable of supporting audio formats and has good DMA connectivity. A DAI driver would need to be written for your SPI port to allow it to send audio data within ASoC.
Right. That's the bit I'm pretty clueless on.
Liam
Cheers, -Caleb
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 10/13/2015 11:57 AM, Liam Girdwood wrote:
- Mark
On Fri, 2015-10-09 at 09:11 -0700, Caleb Crome wrote:
On Fri, Oct 9, 2015 at 2:34 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Thu, 2015-10-08 at 08:51 -0700, Caleb Crome wrote:
Hi All, I'm in a constant struggle to bring up many channel audio on each separate SoC.
I can easily put a microcontroller in place that will collect and distrubute all the TDM channels to the codecs, and connect the hardware via an SPI interface to the SoC.
So, instead of:
CODECS <---TDM---> SoC
It would be
CODECS <---TDM---> uC <---SPI---> SoC
So, my questions are:
- I suspect the SPI interface could be used more universally than each
individual I2S/TDM interface (like FSL SSI vs. Ti McBSP vs. Ti McASP, etc). and the SPI port would provide a very common API regardless of SoC. Is that true?
Some SPI ports could probably be used for audio, but this depends on the SPI port HW capabilities. e.g. the SSP port on minnowboard can be configured for TDM, I2S and SPI (afaik). I don't think any advantage could be gained from running in SPI mode unless your HW permits some special features ?
Sorry, I wasn't clear. The point is to use the 'generic' SPI API in the linux kernel to stream the data, and *not* use an audio format. So, the idea is, the external micro would buffer up a block of data, (in our case, maybe 160 samples * 32 channels = 10 kBytes), then use the SPI port to read and write to the micro as if it were a memory or something like that to transfer the data. So the external micro would appear to the CPU as an external register bank, and would do all the audio aggregation.
Ok, so this sounds like a burst based DAI where the host sends audio data in bursts then sleeps. I think this has been done by some codec vendors, but I dont know if any code is upstream.
The upstream tlv320dac33 driver does something like this, but it is not necessarily an implementation I'd recommend to mimic. The whole burst access mode probably wants some support at the framework level.
On Tue, Oct 13, 2015 at 10:57:45AM +0100, Liam Girdwood wrote:
On Fri, 2015-10-09 at 09:11 -0700, Caleb Crome wrote:
Sorry, I wasn't clear. The point is to use the 'generic' SPI API in the linux kernel to stream the data, and *not* use an audio format. So, the idea is, the external micro would buffer up a block of data, (in our case, maybe 160 samples * 32 channels = 10 kBytes), then use the SPI port to read and write to the micro as if it were a memory or something like that to transfer the data. So the external micro would appear to the CPU as an external register bank, and would do all the audio aggregation.
Ok, so this sounds like a burst based DAI where the host sends audio data in bursts then sleeps. I think this has been done by some codec vendors, but I dont know if any code is upstream.
Well, it's not triggerd from the CODEC side which is a bit different to what the CODEC vendors were trying - it sounds more like what some of the DSP vendors are doing with bursting data into the DSP over a message based interface which maps pretty well onto the existing copy() operation.
On Tue, Oct 13, 2015 at 5:32 AM, Mark Brown broonie@kernel.org wrote:
On Tue, Oct 13, 2015 at 10:57:45AM +0100, Liam Girdwood wrote:
On Fri, 2015-10-09 at 09:11 -0700, Caleb Crome wrote:
Sorry, I wasn't clear. The point is to use the 'generic' SPI API in the linux kernel to stream the data, and *not* use an audio format. So, the idea is, the external micro would buffer up a block of data, (in our case, maybe 160 samples * 32 channels = 10 kBytes), then use the SPI port to read and write to the micro as if it were a memory or something like that to transfer the data. So the external micro would appear to the CPU as an external register bank, and would do all the audio aggregation.
Ok, so this sounds like a burst based DAI where the host sends audio data in bursts then sleeps. I think this has been done by some codec vendors, but I dont know if any code is upstream.
Well, it's not triggerd from the CODEC side which is a bit different to what the CODEC vendors were trying - it sounds more like what some of the DSP vendors are doing with bursting data into the DSP over a message based interface which maps pretty well onto the existing copy() operation.
That sounds right. Send over a messaging interface, rather than an audio interface. Which copy() operation do you mean?
Thanks, - Caleb
On Tue, Oct 13, 2015 at 08:33:26AM -0700, Caleb Crome wrote:
On Tue, Oct 13, 2015 at 5:32 AM, Mark Brown broonie@kernel.org wrote:
Well, it's not triggerd from the CODEC side which is a bit different to what the CODEC vendors were trying - it sounds more like what some of the DSP vendors are doing with bursting data into the DSP over a message based interface which maps pretty well onto the existing copy() operation.
That sounds right. Send over a messaging interface, rather than an audio interface. Which copy() operation do you mean?
The one in snd_pcm_ops.
participants (4)
-
Caleb Crome -
Lars-Peter Clausen -
Liam Girdwood -
Mark Brown