On Sat, 2016-03-26 at 13:16 +0100, Georg Chini wrote: > On 24.03.2016 13:38, Tanu Kaskinen wrote: > > I expect there to be a fixed buffer. It doesn't make sense to me that > > the driver would consume data from the ring buffer when the full > > pipeline isn't yet running. I don't know much about what the different > > PCM device states really are supposed to mean, but I would expect that > > snd_pcm_prepare() already starts most of the sound card hardware, and > > snd_pcm_start() just connects the application buffer to the rest of the > > audio pipeline. > > > As far as I can tell, there is no additional buffer in between. As you > expected, snd_pcm_prepare() sets up bus streaming (at least for > playback) and sends silence until snd_pcm_start(). > If I read the code right (with a big if, I don't know anything about USB), > after snd_pcm_start() we have to wait for the next URB to retire before > the first audio can be sent. And then it apparently takes a while before > the audio reaches the speakers and completion of the first chunk is > reported back to the alsa driver. > > I also checked again, what exactly happens at startup. > mmap_write() fills the buffer to the expected level and then > snd_pcm_start() is called. > When mmap_write() refills the buffer the next time, some audio has > already been played. So everything looks fine on first inspection. > > The expectation however would be, that during the period between > the first and second mmap_write() call an equivalent amount of > audio has been played. And that is not the case for USB devices > because of the startup delay. Do you mean that you still consider the "startup delay" to be a different thing than the normal delay that the device has all the time? I assume that by "has been played" you mean that the audio has reached the speakers. If that's what you mean, I don't understand why you have the expectation that between the first and second write the equivalent amount of audio would have reached the speakers. That would imply zero latency after audio has left the alsa buffer. > For me it still looks like pulseaudio should be able to detect and handle > that situation. Why can't the alsa driver report the delay correctly from the very beginning? I don't see why the startup delay case would be any different from the normal playback delay, and if there's no difference, why can't the driver report the latency accurately in the beginning if it can report it accurately later? And what can pulseaudio do that the alsa driver can't? > Something else, when looking at mmap_write() I noticed that there is > a situation where pa_alsa_safe_mmap_begin() is not followed by a > snd_pcm_mmap_commit() when !after_avail && frames == 0. > Not sure if this is a bug. Do you mean is it incorrect use of the alsa API to ever call mmap_begin() without a corresponding mmap_commit() call? It's probably fine. According to the documentation the purpose of mmap_commit() is to update the write pointer, but since we don't write anything in the "!after_avail && frames == 0" case, the write pointer doesn't need updating. --Â Tanu
