pulse audio build player sync problems at start of track

[pssc]

Using the PA build rather than the alas build player sync seems to be broken on every track change, The scenario currently is PA build and Radio.

This was discovered when I switched the Home assistant Addon to use the Pulse Audio build to work round issues found with sound quality https://github.com/pssc/ha-addon-squeezelite/issues/1 .

I am adding some instrumentation and extra debug to my local PA build, I believe this is may be an upstream issue, so of the sync calculation code looks a little suspect after review and reading the PA API. I will try I few tweaks and experiments, is there anything you would like me to try?

If you have any insights they would be welcome, I will report further findings on this issue thread,

[ralph-irving]

User manison provided the native pulse audio support. I don't use it so don't really have anything to add.

[pssc]

Thanks I will continue looking into it and see what I can do.

[troffasky]

What is "broken" about sync? Does it wander out of sync on track change, or do you find that the player using Pulseaudio randomly goes silent at the beginning of tracks?

[pssc]

Hi,

Yes does wonder a bit sometimes, I have some improvements to the timing and pipeline, but it seems mainly around manual rack change-skip goes silent at the start of tracks, and is then out of sync. I am currently reading up and putting in Debugging. Trying to understand the existing alsa and pulse implementations

Phill.

On Fri, 12 Nov 2021 at 07:58, troffasky @.***> wrote:

What is "broken" about sync? Does it wander out of sync on track change, or do you find that the player using Pulseaudio randomly goes silent at the beginning of tracks?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ralph-irving/squeezelite/issues/155#issuecomment-966898682, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANORYOSLQQUKIO7AARJC2TULTCLLANCNFSM5HXZAYHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- I Can Resist Everything Except Temptation -- Oscar Wilde

[troffasky]

OK, "good", because I came here to log a bug about silence on track change and I'm glad it's not just me! For me however, it's not every track change, it just seems to happen at random.

Desktop running Debian with pulseaudio + squeezelite, synced with Pi 0W running PiCorePlayer. It's the desktop that has the issue. I have found that I can get audio to resume by skipping around in the track.

[troffasky]

When a track changes I see an event like [20:52:37.915266] _output_frames:153 track start sample rate: 44100 replay_gain: 0 when it's working fine. When a player decides to not bother playing the next track, there is no "track start" event logged. I have player.sync log level set to Info but nothing nothing interesting is logged when tracks change.

[tmancill]

Adding a squeezelite+pulseaudio to my sync group causes issues for me as well, sometimes at the start of the track and rarely (but very annoyingly) shortly after the start of a track, causing the entire group to advance forward/jump around a few times. I have Logitech Squeezebox Booms, HiFiBerry devices running HiFiBerryOS (which is squeezelite under the hood, but doesn't exhibit the problem), and squeezelite+pulseaudio running on a laptop that shouldn't have any problem keeping up with the stream.

I'd be glad to help with testing @pssc .

[troffasky]

This doesn't seem to be a Pulseaudio issue, I killed pulseaudio and started squeezelite with -o default:CARD=Extigy and the silence on track change still occurs randomly.

[pssc]

@troffasky what build are you using?

[troffasky]

1.9.9-1386 on the Desktop

[adi1]

I just wanted to add to this, not sure if it's related.

The ALSA plugin works fine, track changes are instant, no sync problems.

In the pulseaudio build, manually changing tracks results in a long pause until the next track starts, around 8 seconds. During this delay, you can still hear the old track playing. If the tracks are not the same bit rate, it will be playing either too fast or too slow until the next track starts.

This only started happening when I got a new DAC, a TEAC UD-301. With my Audioengine D1 and with the built-in notebook sound card, the delay is much shorter, about 1 second, and there is no noticeable sync problem.

This happens on the version from git, currently v1.9.9-1398. The behaviour is identical to the one from my debian bullseye repo, v1.9.8-1317.

I'm just posting this in case it gives anyone ideas, since the issue is so pronounced on my TEAC DAC. If you'd like me to run some tests, just let me know and I'd be glad to help.

[pssc]

I have some changes in testing for some improvements in the pulse audio sync and buffering, these make it better but don't currently eliminate the problem, I am currently staved of time but will get back to it

having said that I don't think this will address the bitrate issues and it may be worth logging that as a separate issue. The pause I have some handle on.

Phill

On Tue, 8 Feb 2022 at 10:25, adi1 @.***> wrote:

I just wanted to add to this, not sure if it's related.

The ALSA plugin works fine, track changes are instant, no sync problems.

In the pulseaudio build, manually changing tracks results in a long pause until the next track starts, around 8 seconds. During this delay, you can still hear the old track playing. If the tracks are not the same bit rate, it will be playing either too fast or too slow until the next track starts.

This only started happening when I got a new DAC, a TEAC UD-301. With my Audioengine D1 and with the built-in notebook sound card, the delay is much shorter, about 1 second, and there is no noticeable sync problem.

This happens on the version from git, currently v1.9.9-1398. The behaviour is identical to the one from my debian bullseye repo, v1.9.8-1317.

I'm just posting this in case it gives anyone ideas, since the issue is so pronounced on my TEAC DAC. If you'd like me to run some tests, just let me know and I'd be glad to help.

— Reply to this email directly, view it on GitHub https://github.com/ralph-irving/squeezelite/issues/155#issuecomment-1032448650, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANORYJN5PBCVMP7Z77DJALU2DVQXANCNFSM5HXZAYHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

-- I Can Resist Everything Except Temptation -- Oscar Wilde

[djtroyal]

@pssc Curious if you've made any headway on your sync/buffering issues? I am experiencing the same problem on the current pulse build.

[pssc]

I have made it better but not fixed, then the next baby arrived so things have become glacial.

Phiil.

On Thu, 23 Jun 2022 at 16:14, Derek T @.***> wrote:

@pssc https://github.com/pssc Curious if you've made any headway on your sync/buffering issues? I am experiencing the same problem on the current pulse build.

— Reply to this email directly, view it on GitHub https://github.com/ralph-irving/squeezelite/issues/155#issuecomment-1164540294, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANORYJFC7AATTVBE3K5WLDVQR5N5ANCNFSM5HXZAYHQ . You are receiving this because you were mentioned.Message ID: @.***>

-- I Can Resist Everything Except Temptation -- Oscar Wilde