Hello,

My issue involves a specific device quirk. The device generally uses a mmap'ed memory regions, however sending a StartIO command (from a trigger) causes a full buffer erase (which is completed once I get an initial UpdateTimestamp several milliseconds later), and it seems that alsa fills the DMA buffer before calling the start trigger. I'm unsure how to workaround this issue. I have seen the SNDRV_PCM_INFO_DOUBLE flag, however it didn't help me in my issue as from what I understand it's merely an information that the driver is using double buffering.

One option is to make the start trigger method copy the buffer, send the StartIO command, then do a blocking-wait for initial timestamp and restore the buffer. I don't think I can get rid of the blocking wait here if I use this temporary-buffer-copy approach as I think that in the time before I get the timestamp update, a client could try to update the shared memory resulting in that data being lost after I restore the original contents later. Another idea I had is to do the same, but in the open callback, however that seems totally wrong.

Any ideas are appreciated. I tried grepping for drivers using the SNDRV_PCM_INFO_DOUBLE flag, however I couldn't find any code workarounding similar issues.

Thank you, Paul Pawlowski

PS: I wrote an email yesterday to this mailing list from another email address, however I have received several SPF failures, so I switched to gmail. Regarding the previous mail, I have figured out the looping audio was caused by the lack of a snd_pcm_period_elapsed call. I have missed it because my device has no proper interrupt handler, and only sends a confusingly named UpdateTimestamp message once the buffer has been fully processed. I'm however still unsure as for what I should return from the _pointer function as the device does not provide a frame pointer.