xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 7 years ago

Closed 7 years ago

Last modified 17 months ago

#1001 closed defect (wontfix)

xpra leaves many _sound_record on server

Reported by: Jiang Owned by: Antoine Martin
Priority: major Milestone: 0.16
Component: sound Version: 0.15.x
Keywords: sound process not turning off Cc:

Description (last modified by Antoine Martin)

System: both Ubuntu 14.04, Server 64bit client 32bit. Since xpra 0.15.6 and still here in 0.15.7. I do not leave pulse audio sound forwarding all the time, but turning it on and off several times in each session on demand, via system-tray gui menu. Sometimes, but not always, this command is left running on the server:

0:00 /usr/bin/python /usr/bin/xpra _sound_record - - pulsesrc  wav  1.0 -d

even after turning off the sound. And after turning on the sound again, the old process till run. Indeed, even after client disconnect, the sound process still runs from the old session.

So, after turning sound on and off a few times, and after a few sessions, there would be tens of such processes running on the server.

This does not seem to affect sound performances. So it's not a blocker bug. But I think it is probably better if the process

/usr/bin/python /usr/bin/xpra _sound_record - - pulsesrc  wav  1.0 -d

get turned off each time I turn off the sound. And certainly when a client disconnect from a session, all the sound processes related to that session should be terminated.

This is forwarding speaker, not microphone.
When starting the client, I have --speaker=off to begin with, and turn sound on and off on demand.

Change History (6)

comment:1 Changed 7 years ago by Antoine Martin

Description: modified (diff)
Status: newassigned

I can't guarantee that I will get around to fixing this bug as the focus is now on 0.16.x which has improved sound forwarding support, and in particular more reliable process monitoring.

The problem here is that communicating with the sound process over pipes is inherently racy with sending signals for killing it. Not an easy problem to solve.

comment:2 Changed 7 years ago by Jiang

That's fine. This is not too much trouble. My server has plenty of RAM, so it doesn't really slow it down. Just let you know there is such a thing. Sound is already more reliable than 0.14 branch. If it improve more in 0.16 branch, that'll be wonderful!

Thank you for all these works! xpra is integral to my computing life.

comment:3 Changed 7 years ago by Antoine Martin

In case someone is willing to do the testing work, I had already recorded the patches that would need to be applied to v0.15.x on the wiki wiki/Versions/PendingFixes under "more reliable stop subprocess": r10394, r10036, r10395, r10455, r10456

comment:4 Changed 7 years ago by Antoine Martin

Resolution: wontfix
Status: assignedclosed

Too late for 0.15, let's focus on 0.16

comment:5 Changed 7 years ago by Jiang

That's reasonable. This is not a big issue. It does not affect function. Thanks for all the 0.16 work.

comment:6 Changed 17 months ago by migration script

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1001

Note: See TracTickets for help on using tickets.