[alsa-devel] Feasibility of adding alternative audio transport besides I2S/PWM/SPDIF, etc

[Caleb Crome]

On Tue, Oct 13, 2015 at 5:32 AM, Mark Brown <broonie at 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