[alsa-devel] Streaming wake-up buffer from DSP to SoC over SPI

[Dylan Reid]

On Mon, Dec 15, 2014 at 8:41 PM, Vinod Koul <vinod.koul at intel.com> wrote:
> On Mon, Dec 15, 2014 at 06:45:37PM -0800, Dylan Reid wrote:
>> What is the right way to model a bursty, SPI based audio transfer?
>> There could be hours between samples, then several seconds of audio
>> will be ready.
>>
>> The codec, an rt5677, is attached to the SoC with both an IIS bus and
>> a SPI bus.  The IIS bus is used for normal audio playback and record.
>> The SPI bus is used for transferring audio that caused a voice wake,
>> "OK Google" in this case.
>>
>> When the codec detects the wake up phrase, the SoC will read out two
>> plus seconds of buffered data over the SPI bus and continue to stream
>> audio data over SPI for the rest of the query.  Nexus 9 has a custom
>> ioctl to access rt5677-spi and some user-space smarts to poll for more
>> data.
> why do we need custom ioctls :( current framework can address all your
> needs..

This is what I'm trying to avoid =)

>
>> I was thinking of making a separate PCM device.  The odd things are
>> that it would have to originate from soc/codecs, the codec would own
>> the codec and cpu end of the link, and the hw_ptr position would need
>> to be queried over SPI.  But it would make userspace access to it more
>> standard looking.
> okay here we have two things and they need to be decoupled. First is
> detection by the codec for "OK Google". And second is getting the data (some
> buffered while things are setup) to usermode.
>
> For the former, the codec should implement a 'sink' for voice wake, so
> essentially connecting the voice wake widget to MIC pins will power up codec
> and codec can do the detection while rest of the system is sleeping
>
> Once the event is detected, codec should send an interrupt to host, thereby
> waking up the system. The driver will figure out that it is voice wake event
> and should set the alsa kcontrol status, on which usermode needs to listen.
>
> Now usermode knows the event occurred so lets read the data. During all the
> activation, wakeup etc some data would be buffered, in you case 2 secs. IMO
> PCM devices aren't suited for this, so you need to use a compressed device.
> The data can come from SPI port (we can get all the buffered data in one big
> burst". I know one vendor has implemented such a mechanism.
>
> The device here wont be any different than regular PCM/Compressed devices.
> Assume the data path is SPI rather than I2S so things would be modelled that
> way. You still need to setup SPI port, DMAs like you would do on I2S.

Ah, I hadn't thought about using the compressed framework.  I can see
how that would make this easier.  I'll take a closer look at it
tomorrow.

Thanks Vinod.

-Dylan

>
> HTH
> --
> ~Vinod
>