On 29.03.2016 05:56, Georg Chini wrote: > On 29.03.2016 02:13, Pierre-Louis Bossart wrote: >> On 3/28/16 12:38 PM, Georg Chini wrote: >>> On 28.03.2016 17:18, Georg Chini wrote: >>>> On 28.03.2016 16:16, Pierre-Louis Bossart wrote: >>>>> On 3/22/16 4:11 AM, Georg Chini wrote: >>>>>> Hi, >>>>>> >>>>> Ups, looks like I misread your sentence above. You are right, in >>> software you can't >>> see the output. But what you can see is the time between dispatching >>> the >>> audio >>> to the USB bus and the time when the bus reports back that the audio >>> was >>> played. >>> >>> I am not sure if I read the code right, I don't know anything about >>> USB, >>> but if the >>> URB's you are submitting to the bus in the prepare step are handled in >>> chronological >>> order, it means that >>> a) you have to wait for the next URB to retire before you can send any >>> real audio >>> b) after you submitted the first audio, it is at the end of the queue >>> and all the other >>> URB's containing silence will be processed first. >> >> The USB driver will submit N silence URBs on startup in the prepare >> and you will have to wait for those URBs to retire before the samples >> are queued. There is very little 'USB processing'. If you want to >> reduce this delay you have to use smaller periods, it'll decrease the >> size of the URBs. I guess it could be possible to change the URB size >> after the start but that's not implemented atm. >> > I don't want to shorten the latency. I only want the latency reported > correctly. To me it still > looks like the real latency of the driver is not what it reports, > because the time that the > audio spends in the URB's is not taken into account. What I am seeing > is, that the real > latency is around 10ms longer than expected. OK, I thought about it another time and I believe I figured out what the problem is. (Sometimes I feel like I am talking Chinese to you - I seem not to be able to express myself in a way that others can understand, sorry for that. I'll try my best now. If we would sit in one room it would probably be sorted out in half an hour.) The starting point is the observation, that with module-loopback and an USB sink the real end-to-end latency is about 10ms longer than configured. This cannot be observed with a HDA sink. Let's go through the sequence of events when module-loopback is started: 1) The module sets up a buffer and fills it with silence up to the configured loopback latency. Sink and source are configured to 1/3 of the loopback latency. In this example, we will use 30ms as loopback latency, so that sink and source are configured to 10ms. 2) Source and sink are started. For simplicity we assume that the source starts delivering samples immediately. 3) As long as sink_input_pop() has not been called, module-loopback drops the audio coming in from the source. 4) On the alsa side, the preparation has been done. Again, to simplify we assume 2 URB's with 5ms each have been set up and submitted to the USB bus. The first URB starts playing silence to the speakers now. 5) The pulseaudio sink code takes the first 10ms of audio out of the loopback buffer, writes it to the alsa buffer and calls snd_pcm_start(). 6) Now sink_input_pop() is called, and that is where things go wrong, because the audio from the source is buffered from now on. 7) On the alsa side nothing has happened yet. The reported delay is what is in the alsa buffer - 10ms. Alsa has to wait for the first URB to expire before any sample can be submitted to the bus. 8) Now the first URB has retired and can be filled with audio. After the URB is submitted to the bus, the alsa delay is NOT updated and still shows 10ms. The second URB starts playing silence for 5ms. Because the buffer seems filled to the correct level, the pulseaudio sink code will wait until the fill level gets lower. 9) The second URB has retired, is filled with audio and submitted to the bus. Still the delay is NOT updated, but from now on, it is correct, since a sample that would now be submitted to the alsa buffer would take 10 ms to the speakers. The first real audio starts playing. 10) Meanwhile the source has been producing samples that have been queued in the loopback buffer and that make up the extra latency I have been observing. In this example it would be 5ms from the second URB plus the time that was left from the first URB when snd_pcm_start() was called. 11) The first URB-full of audio has been played and the URB retires. Now the alsa delay is adjusted to reflect that the first 5ms have been played and the audio flow is completely set up. If the first sink_input_pop() would be called at this point, everything would be fine. So the problem seems to be that sink_input_pop() is called too early. I hope I was able to find the right words this time ...
