Audio issue with new input

MrZoltan

New Member
Joined
Oct 13, 2025
Messages
7
Reaction score
1
Credits
111
Hi,

I suppose I am in a very specific issue because I don't seem to find a whole lot of informations on it.

The context is :
  • I have a linux debian 12 with xfce on a MINIX Z100-0dB (Pipewire 0.3.65 & Pulseaudio module)
  • An SMSL-SU9n is connected to it with USB. (And amp & speakers in the chain)
  • I have connected recently a Hifime UR23 Optical to usb to manage sound from from my Samsung TV.
  • I can see the input from the UR23 in Qpwgraph, I have draged FL & FR to the SMSL analog output.
  • I also use Spotifyd that output to the same SMSL analog output.

The problem is everything work ok when the TV is on, if I turn the TV off the Spotifyd is making some strange barely recognizable choppy noises, but dont correctly play music anymore, if I turn the TV on everything work fine again. If I remove the link between the UR23 capture device and the SMSL output or virtual sink then I can turn the TV off and the Spotifyd work ok.

I have tried so many unsuccesful things that I can't remember all (and reverted back with timeshift)
  • Creating Virtual sink and connecter the UR23 to it (null-audio)
  • Tried to mess with "session.suspend-timeout-seconds = 0" without any effect
  • Hoped that I could play with clock master by setting the SMSL as proaudio
  • Tried some stuff with Wireplumber to remove the timeout, that completly broke Pipewire.
  • I will not even get to the issue that alsa is setting the SMSL audio to 0 between reboot or restart of pipewire.

So I am afraid I don't know what I am doing and can't exactly identify the reason, nor the solution for that issue.

By chance someone here know more on the subject and wish to help me in that battle that I am loosing. For the moment I connect the TV via Blueman to have sound on speakers, but I don't like that solution much.

Thanks
 


It could be the issue in here somwhere :

S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
S 28 0 0 --- --- --- --- 0 Dummy-Driver
S 29 0 0 --- --- --- --- 0 Freewheel-Driver
S 36 0 0 --- --- --- --- 0 Midi-Bridge
R 46 2048 48000 828.4us 1.2us 0.02 0.00 2 S24LE 2 48000 alsa_input.usb-HiFimeDIY_Audio_UR23_USB_SPDIF_Rx-01.analog-stereo
R 30 0 0 0.8us 14.0us 0.00 0.00 2 F32P 2 48000 + TV-sink
R 47 0 0 22.7us 445.8us 0.00 0.01 2 S32LE 2 48000 + alsa_output.usb-SMSL_SMSL_USB_AUDIO-00.pro-output-0
R 58 4630 44100 80.8us 262.3us 0.00 0.01 2 S24_32 2 44100 +

I have continued troubleshooting by myself
  • Change the device from default to SMSL & bitrate (S24LE->F32) in Spotifyd config file (Nope)
  • In Wireplumber UR23 config : (Nope)
    • "node.pause-on-idle" = false
      "node.always-process" = true
      "node.driver" = false
      "stream.dont-remix" = true

S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
S 28 0 0 --- --- --- --- 0 Dummy-Driver
S 29 0 0 --- --- --- --- 0 Freewheel-Driver
S 35 0 0 --- --- --- --- 0 Midi-Bridge
R 46 2048 48000 848.5us 1.3us 0.02 0.00 2 S24LE 2 48000 alsa_input.usb-HiFimeDIY_Audio_UR23_USB_SPDIF_Rx-01.analog-stereo
R 30 0 0 0.8us 15.5us 0.00 0.00 2 F32P 2 48000 + TV-sink
R 47 0 0 23.7us 455.1us 0.00 0.01 2 S32LE 2 48000 + alsa_output.usb-SMSL_SMSL_USB_AUDIO-00.pro-output-0
R 58 4630 44100 95.0us 256.6us 0.00 0.01 2 F32LE 2 44100 +

Could it be a bitrate issue (44.1 instead of 48) or when TV Optical turn off and that Pipewire/Wireplumber do something?
 
I have a linux debian 12 with xfce on a MINIX Z100-0dB (Pipewire 0.3.65 & Pulseaudio module)
This makes no sense, you can have either one but not both.

Also Debian 12 is now out of date, the default audio for Debian 12 is pulseaudio and for Debian 13 is Pipewire.
 
This makes no sense, you can have either one but not both.

Also Debian 12 is now out of date, the default audio for Debian 12 is pulseaudio and for Debian 13 is Pipewire.
Well maybe you are not aware how I can use pulse with pipewire, here is how : pipewire-pulse

I don't use PulseAudio server but use it as a pipewire package, the same way it is done in Debian 13.
Upgrading could solve the issue, but I am not sure it would, eventually it could break other things too, giving me more troubleshooting.
 
This makes no sense, you can have either one but not both.

Also Debian 12 is now out of date, the default audio for Debian 12 is pulseaudio and for Debian 13 is Pipewire.
It could make sense :-) . Debian 12, as you say, has pulseaudio as default, but pipewire can be installed on debian 12, instructions here: https://wiki.debian.org/PipeWire#Debian_Testing.2FUnstable. When that happens, pulseaudio modules are managed by the pipewire compatibility server: pipewire-pulse, which is a sort of daemon that implements the pulseaudio protocol on top of pipewire. It allows pulse apps like pavucontrol to just work. I guess one can run: pactl list modules to see which modules are actually present. More clarity from the OP may help.
 
Last edited:
When that happens, pulseaudio modules are managed by the pipewire compatibility server
while it's true that pipewire manages pulseaudio trough compatibility layer, the pulseaudio package itself is removed when you install pipewire.
You have to reinstall it if you want it back.
That's what I experienced when I was troubleshooting audio in 12
 
while it's true that pipewire manages pulseaudio trough compatibility layer, the pulseaudio package itself is removed when you install pipewire.
You have to reinstall it if you want it back.
That's what I experienced when I was troubleshooting audio in 12
Yes, you are correct. In trying to make sense of the OP's comment though, it occurred to me that they may have been referring to a pulseaudio module like "module-device-restore" which has been replaced by a pipewire one, but still has the same name, or similar name, it had in pulseaudio with the same or similar function, hence was being referred to as "pulseaudio". This sort of thing can be confusing and has confused me in the past. Clarity from the OP about what was meant would help.
 
It could make sense :-) . Debian 12, as you say, has pulseaudio as default, but pipewire can be installed on debian 12, instructions here: https://wiki.debian.org/PipeWire#Debian_Testing.2FUnstable. When that happens, pulseaudio modules are managed by the pipewire compatibility server: pipewire-pulse, which is a sort of daemon that implements the pulseaudio protocol on top of pipewire. It allows pulse apps like pavucontrol to just work. I guess one can run: pactl list modules to see which modules are actually present. More clarity from the OP may help.

You are right I have installed most of it from a bare Debian 12, including Xfce.

Here is the "pactl list modules"
Module #1
Name: libpipewire-module-rt
Argument: {
nice.level = -11
#rt.prio = 88
#rt.time.soft = -1
#rt.time.hard = -1
}
Usage counter: n/a
Properties:
module.name = "libpipewire-module-rt"
object.id = "1"
object.serial = "1"
module.author = "Wim Taymans "
module.description = "Use realtime thread scheduling, falling back to RTKit"
module.usage = "[nice.level=<priority: default 20(don't change)>] [rt.prio=<priority: default 88>] [rt.time.soft=<in usec: default -1] [rt.time.hard=<in usec: default -1] "
module.version = "0.3.65"
nice.level = "-11"

Module #2
Name: libpipewire-module-protocol-native
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-protocol-native"
object.id = "2"
object.serial = "2"
module.author = "Wim Taymans "
module.description = "Native protocol using unix sockets"
module.version = "0.3.65"

Module #3
Name: libpipewire-module-profiler
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-profiler"
object.id = "3"
object.serial = "3"
module.author = "Wim Taymans "
module.description = "Generate Profiling data"
module.version = "0.3.65"

Module #5
Name: libpipewire-module-metadata
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-metadata"
object.id = "5"
object.serial = "5"
module.author = "Wim Taymans "
module.description = "Allow clients to create metadata store"
module.version = "0.3.65"

Module #7
Name: libpipewire-module-spa-device-factory
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-spa-device-factory"
object.id = "7"
object.serial = "7"
module.author = "Wim Taymans "
module.description = "Provide a factory to make SPA devices"
module.version = "0.3.65"

Module #9
Name: libpipewire-module-spa-node-factory
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-spa-node-factory"
object.id = "9"
object.serial = "9"
module.author = "Wim Taymans "
module.description = "Provide a factory to make SPA nodes"
module.version = "0.3.65"

Module #11
Name: libpipewire-module-client-node
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-client-node"
object.id = "11"
object.serial = "11"
module.author = "Wim Taymans "
module.description = "Allow clients to create and control remote nodes"
module.version = "0.3.65"

Module #13
Name: libpipewire-module-client-device
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-client-device"
object.id = "13"
object.serial = "13"
module.author = "Wim Taymans
module.description = "Allow clients to create and control remote devices"
module.version = "0.3.65"

Module #15
Name: libpipewire-module-portal
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-portal"
object.id = "15"
object.serial = "15"

Module #16
Name: libpipewire-module-access
Argument: {
# access.allowed to list an array of paths of allowed
# apps.
#access.allowed = [
# /usr/bin/pipewire-media-session
#]

# An array of rejected paths.
#access.rejected = [ ]

# An array of paths with restricted access.
#access.restricted = [ ]

# Anything not in the above lists gets assigned the
# access.force permission.
#access.force = flatpak
}
Usage counter: n/a
Properties:
module.name = "libpipewire-module-access"
object.id = "16"
object.serial = "16"
module.author = "Wim Taymans "
module.description = "Perform access check"
module.usage = "[ access.force=flatpak ] [ access.allowed=<cmd-line> ] [ access.rejected=<cmd-line> ] [ access.restricted=<cmd-line> ] "
module.version = "0.3.65"

Module #17
Name: libpipewire-module-adapter
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-adapter"
object.id = "17"
object.serial = "17"
module.author = "Wim Taymans "
module.description = "Manage adapter nodes"
module.version = "0.3.65"

Module #19
Name: libpipewire-module-link-factory
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-link-factory"
object.id = "19"
object.serial = "19"
module.author = "Wim Taymans "
module.description = "Allow clients to create links"
module.version = "0.3.65"

Module #21
Name: libpipewire-module-session-manager
Argument:
Usage counter: n/a
Properties:
module.name = "libpipewire-module-session-manager"
object.id = "21"
object.serial = "21"
module.author = "George Kiagiadakis "
module.description = "Implements objects for session management"
module.version = "0.3.65"

Module #536870912
Name: module-always-sink
Argument:
Usage counter: n/a
Properties:
module.author = "Pauli Virtanen "
module.description = "Always keeps at least one sink loaded even if it's a null one"
module.usage = "sink_name=<name of sink>"
module.version = "0.3.65"
 
Last edited:
I think first priority would be upgrade to the latest stable debian build https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-13.1.0-amd64-DVD-1.iso

Thanks for the suggestion, I am evaluating what work I will have to put in that, most things have been installed manually, some even compiled from source. I don't know if an upgrade will work, a fresh install is the probably the best way to make sure of it. (No forgetting the initial problem that may still be there)
 
So, the good news is that I spent the day reinstalling the computer with Debian 13 (From scratch)

The bad is that I am exactely having the same issue than before.

Is there someone here that know enough about pipewire/wireplumber to help me with that ?
 


Follow Linux.org

Members online


Top