Hi,
On May 18 2017 14:12, Kuninori Morimoto wrote:
Both information have to be accurate enough. With tsched=1, the
period update is basically ignored and PA tries to update the buffer
at its own timing. The samples to be updated are determined by avail
and delay values of snd_pcm_status, which are calculated from hw_ptr,
appl_ptr and delay in the kernel.
Also, such a problem might be some memory coherency issue.
OK, thank you for your explanation.
My current driver updates snd_pcm_ops::pointer only when DMA transfer was
finished, but I guess it needs to adjust to update it during transfer, too.
I think I can use dmaengine_tx_status() for this purpose.
I don't know how to know about delay, but I will try update pointer as 1st step.
If your driver calls 'snd_pcm_period_elapsed()' in any hw/sw IRQ
context, it's correct. But 'struct snd_pcm_ops.pointer' callback is not
only executed by the function, but also in the other contexts such as
ioctl(2) with HWSYNC.
In design of ALSA PCM core, the callback is expected to return the
number of PCM frames currently transferred via physical audio serial
bus, inner PCM period boundary. As long as I know, recent hardwares have
any register for this purpose and your driver could calculate the number.
The 'accuracy' represents how accurate the returned number is, against
actual transferring via audio serial bus.
Regards
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
