>> poll >> snd_pcm_mmap_begin(); >> snd_pcm_mmap_commit(); >> poll >> snd_pcm_mmap_begin(); >> ... realize things have gone wrong ... >> snd_pcm_drop(); >> snd_pcm_prepare(); >> snd_pcm_start (); >> poll >> snd_pcm_mmap_begin(); >> snd_pcm_mmap_commit(); >> >> i would have expected snd_pcm_drop() to effectively shut down the >> driver, or at least for snd_pcm_drop() and snd_pcm_prepare() to get it >> back to a "pristine" state again. >> >> so, how should i handle such a condition? > >The described sequence should work. As Abramo stated, the new >snd_pcm_mmap_begin() call is enough.
that implies that the h/w is left running between the failure point and the snd_pcm_mmap_begin() call, right? that would be bad - the playback stream will contain data, and we will continue to hear it will we clean up. the driver is set to *not* handle xruns by itself. > What exactly fails? after restarting, the audio stream is not in sync - it contains minor crackles and clicks suggesting that the device driver doesn't really know where the hw pointer is. the effect varies with the period size, which reinforces my belief in what's gone wrong. this happens on both the hammerfall and the trident, though the effect sounds a little different on each one. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
