You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When playing songs with different sample rates, PipeWire can adapt its internal graph's sample rate on the fly, eliminating the need for any resampling. However, this will only happen if source streams are destroyed and recreated (and PipeWire therefore is idle [1]). To make the graph's sample rate adapt to a change in sample rate between songs in Squeezelite, one must therefore do one of two things:
Shut down the player via the LMS UI, or
specify the "-C 1" command-line option, then pause playback for one second.
In both cases, the stream is torn down and will be recreated when the next song is started. However, when recreating the stream, Squeezelite initializes it with the sample rate with the previously played song, not the newly chosen one [2]. The sample rate is updated moments later of course [3], but PipeWire won't update the graph at this point anymore as it isn't idle.
As a result, getting PipeWire's graph to match a new song's sample rate is a cumbersome process:
A) Start playing the new song (so that when the stream is later torn down and recreated, this song will be considered the "previous" one and its sample rate is used straight away).
B) If "-C 1" was specified on the command line, pause playback for one second. Otherwise, turn off the player via the LMS UI. At this point, the stream is torn down.
C) Resume play. At this point, the stream is recreated. Since the new song was playing for a split second before, its sample rate is used to initialize the stream - and the PipeWire graph adapts to it.
The following changes to Squeezelite would make this a lot more user-friendly:
Ideally, a new command-line option to tear down and recreate the stream whenever the new song has a different sample rate than the previous one, giving PipeWire a chance to adapt its graph.
Failing the above, when recreating the stream after it has been torn down manually by the user, use the sample rate of the newly chosen song, not the previous one at [2].
In addition to (2), allow specifying "-C 0" to tear down the stream immediately on pause. Right now, "-C 0" means "never tear down the stream," so the minimum possible is "-C 1," requiring the user to pause and then wait one second for the stream to be torn down.
When playing songs with different sample rates, PipeWire can adapt its internal graph's sample rate on the fly, eliminating the need for any resampling. However, this will only happen if source streams are destroyed and recreated (and PipeWire therefore is idle [1]). To make the graph's sample rate adapt to a change in sample rate between songs in Squeezelite, one must therefore do one of two things:
In both cases, the stream is torn down and will be recreated when the next song is started. However, when recreating the stream, Squeezelite initializes it with the sample rate with the previously played song, not the newly chosen one [2]. The sample rate is updated moments later of course [3], but PipeWire won't update the graph at this point anymore as it isn't idle.
As a result, getting PipeWire's graph to match a new song's sample rate is a cumbersome process:
A) Start playing the new song (so that when the stream is later torn down and recreated, this song will be considered the "previous" one and its sample rate is used straight away).
B) If "-C 1" was specified on the command line, pause playback for one second. Otherwise, turn off the player via the LMS UI. At this point, the stream is torn down.
C) Resume play. At this point, the stream is recreated. Since the new song was playing for a split second before, its sample rate is used to initialize the stream - and the PipeWire graph adapts to it.
The following changes to Squeezelite would make this a lot more user-friendly:
[1] Look for "the graph sample rate will be switched when devices are idle" at https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire
[2]
squeezelite/output_pulse.c
Line 207 in 6394b3f
[3]
squeezelite/output_pulse.c
Line 333 in 6394b3f
The text was updated successfully, but these errors were encountered: