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.
