On 06/26/12 12:39, Bryan Ischo wrote: > > So what I need is a way to tell ALSA to re-sync the application write > position with the hardware read position without having to reset the > device. > > Before I start digging into the ALSA code to understand this better, > is there any obvious way to make this happen with the current APIs? > What about if I use ALSA mmap mode and manage pointers myself? Is it > possible then? OK I think I figured out a way: Immediately after preparing a PCM device, and before doing any writes to it, I call snd_pcm_avail() and record that number (in my case, it is 16384) as "maxValidAvail". Immediately before any call to snd_pcm_writei(), I again call snd_pcm_avail(). If the result is greater than maxValidAvail, I call snd_pcm_forward(pcm, snd_pcm_avail() - maxValidAvail). I *think* that what this accomplishes is to forward the write pointer within the ring buffer to the read pointer. Anyway, it seems to work; now when I have enabled "silence instead of underrun", when what would have been an underrun occurs, it is detected using the above logic and the silence that was played out is skipped past right before the next write of audio data. I don't really understand why snd_pcm_avail() goes greater than the ring buffer size when silence has been played out; but it seems like a reliable way to detect this situation and an accurate enough number to allow skipping the silence. I do still get pops, which I don't understand, but they only occur after very "large" underruns, where I have allowed a significant amount of silence to play, instead of "small" underruns, which happen when my thread delivering audio data is very slightly behind where it should be. Thanks, Bryan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
