Ticket #148 (new defect)

Opened 4 years ago

Last modified 6 months ago

Switching a stream from a remote tunnel to a local sink takes some time

Reported by: sjoerd Owned by: mkbosmans
Milestone: Component: daemon
Keywords: Cc: esmil@…, mailsander@…

Description

To reproduce.. Switch a stream to a remote tunnel, switch it back to a local sink.. Audio output stops for multiple seconds and then continues..

Below is what my local pulse server outputs when moving the stream back to a local sink..

I: resampler.c: Forcing resampler 'copy', because of fixed, identical sample rates.
I: resampler.c: Using resampler 'copy'
I: resampler.c: Using float32le as working format.
D: module-suspend-on-idle.c: Sink tunnel.spring.local.alsa_output.platform_snd_powermac_alsa_playback_0 becomes idle.
D: module-suspend-on-idle.c: Sink tunnel.spring.local.alsa_output.platform_snd_powermac_alsa_playback_0 becomes idle.
I: module-alsa-sink.c: Trying resume...
I: module-alsa-sink.c: Resumed successfully...
D: module-suspend-on-idle.c: Sink alsa_output.pci_8086_284b_alsa_playback_0 becomes busy.
D: sink-input.c: Successfully moved sink input 54 from tunnel.spring.local.alsa_output.platform_snd_powermac_alsa_playback_0 to alsa_output.pci_8086_284b_alsa_playback_0.
I: module-volume-restore.c: Saving sink for <pulsecore/protocol-native.c$Rhythmbox>
D: memblock.c: Memory block too large for pool: 49152 > 16368
I: module-alsa-sink.c: Starting playback.
W: module-tunnel.c: Server signalled buffer underrun.
I: module-suspend-on-idle.c: Sink tunnel.spring.local.alsa_output.platform_snd_powermac_alsa_playback_0 idle for too long, suspending ...

Change History

Changed 2 years ago by Esmil

..and in latest (> 0.9.21) git master branch switching a stream from remote tunnel to a local sink is completely broken. Playback just stops until you switch the stream back to the tunnel sink.

Oddly switching from local sink to tunnel sink works great though.

Changed 2 years ago by Esmil

  • cc esmil@… added

Changed 2 years ago by accumulator

  • cc mailsander@… added

I had exactly this problem, with both ubuntu provided 0.9.19 and 0.9.22 from PPA/ricotz/unstable.

The problem manifested only after the target system was running for a while (asrock nettop), mapping sound from the desktop to the asrock always works (but with audio that tries to catch up, i.e. much faster speed), but mapping it back to a local device the player is paused for a while, then continues. The delay before playing continues is a bit random, with a few sequential tests I observed 20s-120s.

restarting pulseaudio there did not make any difference.

But.. I then synced both system clocks using NTP and voila, perfect handovers!

So somehow absolute clock is used in PA for relative stream positioning?

Changed 2 years ago by accumulator

  • milestone set to 0.9.22

of course the NTP thing is a workaround, so a) hoping/assuming this is easy to fix and b) since this bug is so old already.. I mark this as milestone

Changed 11 months ago by mkbosmans

  • milestone changed from 0.9.22 to 1.0

Changed 11 months ago by mkbosmans

  • owner changed from lennart to mkbosmans

Changed 6 months ago by mkbosmans

  • milestone 1.0 deleted
Note: See TracTickets for help on using tickets.