[alsa-devel] [BUG] snd_pcm_drop() does not stop the PCM immediately

[Takashi Iwai]

On Wed, 14 Mar 2018 16:50:48 +0100,
Martin Schreiber wrote:
> 
> On 03/14/2018 04:13 PM, Takashi Iwai wrote:
> > 
> > It's a best-effort base stopping mechanism with dmix, so it's a sort
> > of expected behavior, unfortunately.  Due to its nature of
> > implementation, scratching off the existing data from the mixed buffer
> > isn't so trivial for now.
> > 
> eSpeakNG has the workaround in pcaudiolib (see outcommented part):
> "
> int
> alsa_object_flush(struct audio_object *object)
> {
> 	struct alsa_object *self = to_alsa_object(object);
> 	if (self && self->handle){
> 		snd_pcm_drop(self->handle);
> 	}
> /*
> 	if (!self) return 0;
> 
> 	// Using snd_pcm_drop does not discard the audio, so reopen the device
> 	// to reset the sound buffer.
> 	if (self->is_open) {
> 		audio_object_close(object);
> 			//this crashes write operation in other thread!
> 		return audio_object_open(object, self->format, self->rate,
> self->channels);
> 	}
> */
> 	return 0;
> }
> 
> "
> "
> void
> alsa_object_close(struct audio_object *object)
> {
> 	struct alsa_object *self = to_alsa_object(object);
> 
> 	if (self->handle) {
> 		snd_pcm_close(self->handle);
> 		self->handle = NULL;
> 		self->is_open = 1;
> 	}
> }
> "
> Does snd_pcm_close() "scratching off the existing data from the mixed
> buffer"?

It shouldn't.  There is no corresponding code in the dmix close path
as far as I read again.  So, if it really does anything better, it's
somewhere rather in the ALSA timer handling, I suppose.

> If yes, how could the workaround be made without letting crash
> pending write operations in separate thread?

Likely no, but please test whether it really makes difference before
the final conclusion.  If yes, it's worth for further investigation.
There can be something I overlooked or forgot, of course, it's a damn
old code :)


thanks,

Takashi