Jaroslav Kysela

Do you see this problem with 1.2.5 ?

The maximal timeout can be estimated for those callers wait callers. I agree that the timeout should be set to a more sane value, because we know the stream parameters...

If you set the params - snd_pcm_hw_params(), the driver may restrict the future configuration space depending on this settings (for example to lock the playback and capture rates to identical...

Yes, the configuration space is dynamic and it may change when the hw params are set.

Yes, snd_pcm_hw_free() call after snd_pcm_hw_params(). The PCM stream should be put back to the "open" state. I don't follow the "set params" -> "query params" operation in PA. The query...

You may use snd_pcm_dump() to check the set / current params.

Check also permission bits in /usr/share/alsa/alsa.conf (defaults.pcm.ipc_perm).

The PA check is not 100%. The real time measurement is missing, so it may be possible, that there's a task scheduling glitch (gap). This suggest also the log in...

The problem with those redirections is that there are many false-positive reports (they are here, in kernel bugzilla and ocassionally on the alsa-devel mailing list). If PA does not measure...

Could you elaborate a bit more what does not work? The snd_pcm_mmap_begin() also limits the number of frames.