[pulseaudio-discuss] Toslink capture looback latency problem

[Georg Chini]

On 29.01.2018 19:19, Georg Chini wrote:
> On 29.01.2018 18:46, Nico wrote:
>> On 01/29/2018 03:52 PM, NicoHood wrote:
>>> On 01/29/2018 03:29 PM, Georg Chini wrote:
>>>> On 29.01.2018 14:44, NicoHood wrote:
>>>>> On 01/29/2018 01:39 PM, Georg Chini wrote:
>>>>>> On 29.01.2018 12:52, Nico wrote:
>>>>>>> Hi,
>>>>>>> I want to capture the audio stream of my TV with my PCI-E 
>>>>>>> Toslink sound
>>>>>>> card and play it back on my usb XLR soundcard. The reason why I 
>>>>>>> do that
>>>>>>> is to use my own music boxes rather than the TV speakers. With
>>>>>>> toslink +
>>>>>>> XLR I do not have problems with ground loops etc.
>>>>>>>
>>>>>>> I am using the pulseaudio loopback module with its default
>>>>>>> configuration. The problem is, that the delay between picture 
>>>>>>> and sound
>>>>>>> is about one second off, and the longer I wait, the more delay 
>>>>>>> it gets
>>>>>>> (30 seconds and more). It is no usable like this.
>>>>>>>
>>>>>>> I tried to play with the latencies of source, sink and the tv delay
>>>>>>> itself without sucess. I also tried streaming with pacat 
>>>>>>> directly as
>>>>>>> described here:
>>>>>>> https://thelinuxexperiment.com/fix-pulseaudio-loopback-delay/
>>>>>>>
>>>>>>> I also tried to change different parameters of the loopback 
>>>>>>> module or
>>>>>>> the sources/sinks, but that did not help. I never changed any 
>>>>>>> global
>>>>>>> pulseaudio config to avoid larger configuration issues. The CPU
>>>>>>> usage of
>>>>>>> pulseaudio is at 3% with the loopback module
>>>>>>>
>>>>>>> Can anyone help me to get rid of this lag?
>>>>>>>
>>>>>> Hi Nico,
>>>>>>
>>>>>> which version of PA are you using? Can you provide logs?
>>>>>>
>>>>>> Regards
>>>>>>                Georg
>>>>>>
>>>>> Hi Georg,
>>>>> oh sure I completely forgot:
>>>>>
>>>>> pulseaudio 11.1-1 (Arch Linux)
>>>>> uname -a: Linux zebes 4.14.15-1-ARCH #1 SMP PREEMPT Tue Jan 23 
>>>>> 21:49:25
>>>>> UTC 2018 x86_64 GNU/Linux
>>>>>
>>>>> Here is a logfile:
>>>>> LANG=C pulseaudio -vvvv --log-time=1 > ~/pulseverbose.log 2>&1
>>>>> https://gist.github.com/NicoHood/85976f426e1621e599253ee1a95230dd
>>>>>
>>>>> Regards
>>>>> Nico
>>>> This is weird. It looks like the source sample rate is so much higher
>>>> than the sink rate that module-loopback can't adapt. No idea why
>>>> this happens. Does it work with another input?
>>>>
>>>>
>>> I've tested it also with the builtin front microphone input (2nd
>>> revision on gist) and with the PCIE Analog line in (3rd gist revision).
>>> You can view the changes here:
>>> https://gist.github.com/NicoHood/85976f426e1621e599253ee1a95230dd/revisions 
>>>
>>>
>>> The problem only occurs with the digital, optical TOSLINK input from my
>>> Samsung TV. For some other reason the sound distortion for the analog
>>> input is now (temporary) gone. However I still want to get that TOSLINK
>>> running :/
>>> _______________________________________________
>>> pulseaudio-discuss mailing list
>>> pulseaudio-discuss at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>>
>> As an additional test I send the audio to the TOSLINK output of the
>> soundcard, back to its input and setup loopback on the input again (to
>> the USB soundcard). With this method the sound has no lag. The
>> difference is that the toslink signal comes from the soundcard itself
>> rather than the TV. I have some smaller noises/distortion however
>> sometimes. Here is the log:
>> https://gist.github.com/NicoHood/6ef237649d97eaa69d9a78dd91eff34a
>>
> Somehow this still sounds like a sample rate mismatch. (A wild
> guess, I do not know how the signal chain works for a TOS-link)
> Have you tried setting your card to 48kHz? You can change
> default-sample-rate and alternate-sample-rate in daemon.conf
> both to 48000 and restart pulse to enforce this.

I took a look at your first log again. At some point, module-loopback runs
at 44540 Hz output rate. Log entries are spaced by 10 seconds. Every
10 seconds, the latency increases by 783 ms. When you calculate
(48000 - 44540) *10 / 44100 you get 784 ms, so it is very probable that
you are in fact receiving data at 48kHz.