Latency issue in Audio codec - Not supporting Microsec range

Products Support HiKey 960
#1

Hi ,

I am working with EVAL-ADAU1777 with hikey960.

We have been experiencing a considerable signal latency ( 6 to 110 milliseconds) in our program of i2s read and write with Hikey960 as master and codec EVAL-ADAU1777 board as slave. We used 48KHz, 192KHz frequencies as sampling frequency in both Hikey and Codec,
Do we need to do any modification in i2s driver for attaining the latency tens of microseconds . Any body have the patch for this ?

Our observations:

Waveform used : 1Hz Sawtooth wave.

Oscilloscope connection : codec input in 1 channel (upper) and Codec output in the other (lower)

. In program, when we used 48KHz sampling frequency and 16K Block size as block size in i2s read function (ie pcm_read(PCM_Obj,&Buffer[TempInt],Read_Size):wink: we got 96 milliseconds latency .

. When we tried with very less blocksize/no buffering, with 192KHz we are able to get the data in the MCU within 10s of microseconds till the writing point of i2s (time values obtained in log), but i n the oscilloscope we still get milliseconds latency.

We also see values as below in static const struct snd_pcm_hardware snd_hisi_hardware

.period_bytes_min = 4096,
.period_bytes_max = 4096,
.periods_min = 4,
.periods_max = UINT_MAX,
.buffer_bytes_max = SIZE_MAX,
We would like to know whether this values has role in the relay induced.

#2

The latency on a phone device will likely consist of hardware delay as the microphone samples go through a hardware (or microcontroller) pipeline intended for early processing such as echo cancellation (although on devices like Hikey960 I suspect most of that is in bypass mode) plus the software delay based on sizing the period buffers to avoid the main OS from missing interrupts. In addition to this there will be a little bit of “jitter” in the observed latency caused by things happening inside Linux such as interrupt latency.

For example 48000Hz audio with a 4096 period should observe a software latency of 4096/48000 (~85ms). 10ms is on the high side for hardware latency but certainly not impossible. Phone audio pipelines are not usually designed for low latency because they tend to favour power reduction over low latency.