I've been getting the below log quite often while playing the spotify web player.
2015-08-17 12:13:50,600 re-starting speaker because of overrun ** Message: pygobject_register_sinkfunc is deprecated (GstObject) 2015-08-17 12:13:51,104 sound-sink internal error: write connection TwoFileConnection() reset: [Errno 32] Broken pipe
Also, the sound on xpra goes "off" all of a sudden. This happens out of nowhere when I am usually playing some audio. The error log corresponding to this is below:
2015-08-17 12:15:41.343 xpra[6980:5f03] *** __NSAutoreleaseNoPool(): Object 0x1560d890 of class NSImage autoreleased with no pool in place - just leaking 2015-08-17 12:15:41.346 xpra[6980:5f03] *** __NSAutoreleaseNoPool(): Object 0x3030a0 of class NSCFNumber autoreleased with no pool in place - just leaking 2015-08-17 12:15:41.347 xpra[6980:5f03] *** __NSAutoreleaseNoPool(): Object 0x15533580 of class NSCFDictionary autoreleased with no pool in place - just leaking
The sound also goes off when I unplug the headphones. It does not resume even after plugging it back. Must refresh the page and change the sound settings to "on" to get it back.
XPRA VERSION: Client - 0.15.5
Server - 0.15.4
Revision: Client - 10308
Server - 10209
OS: Client - Mac OSX Darwain-10.8.0-i386-32bit
Server - Fedora 21
Please specify which codec you're using. This should be visible in the client and server output.
I am afraid that the likely solution to this problem is #849 - though some of these fixes could land in 0.15 eventually.
I'm using mp3 codecs. I've attached the screenshot of the session info.
Does the latest beta improve things? http://xpra.org/beta/osx/
See #849, sound improvements are going in 0.16.
Replying to antoine:
Does the latest beta improve things? http://xpra.org/beta/osx/
Even with the latest beta, things aren't any good.
The sound also goes off once I unplug the headphones. It does not resume even after plugging it back. Must refresh the page and then change the sound settings to "on" to get it back.
The default speaker codec on both client and server is mp3.
Server-side log:
2015-09-01 16:55:36,383 using Pulseaudio device 'Monitor of Null Output' 2015-09-01 16:55:36,787 sound-source codec: MPEG-1 Layer 3 (MP3) 2015-09-01 16:56:00,827 using Pulseaudio device 'Monitor of Null Output' 2015-09-01 16:56:01,162 sound-source codec: MPEG-1 Layer 3 (MP3)
Client-side log:
2015-09-01 16:55:58,319 UI thread is running again, resuming 2015-09-01 16:55:58,822 sound-sink internal error: write connection Pipe() reset 2015-09-01 16:55:58,823 sound-sink [Errno 32] Broken pipe 2015-09-01 16:56:00,495 UI thread is now blocked 2015-09-01 16:56:01,703 UI thread is running again, resuming 2015-09-01 16:56:02,439 sound-sink using audio codec: MPEG 1 Audio, Layer 3 (MP3)
P.S Did not get any overrun/underrun logs as before though.
And, here's the xpra info I grabbed ---> ticket949-sound-goes-off.text
Client: Mac OSX --- xpra 0.16.0 --- r10380 Server: Fedora 21 --- xpra 0.16.0 --- r10306
Can you get the same result by causing overruns without plugging headphones (bad connection, synthetic jitter - as pet #849), or is it only when plugging headphones?
We don't show overruns anymore because we trigger many more than before to manage the queue levels. Your client and server builds are quite out of date now..
Replying to antoine:
Can you get the same result by causing overruns without plugging headphones (bad connection, synthetic jitter - as pet #849), or is it only when plugging headphones?
We don't show overruns anymore because we trigger many more than before to manage the queue levels. Your client and server builds are quite out of date now..
The latest one on the server is 0.16.0-r10306.
However, I tried working with the latest xpra client builds (0.16.0-r10472 and r10504). But I get the error - "could not import gtk" --> #974
I tested different versions of xpra trunk for the past 1 week to fetch you the logs and reproduce the same error. But I couldn't do it.
1) With the xpra trunk server--16.0-r10656--Fedora21 and client--16.0-r10655--MacOSX10.10.3
The sound worked absolutely fine and played without any audio breaks throughout the session.
I also tried to reproduce the same result by causing overruns by introducing synthetic jitter (as per #849) with values XPRA_SOUND_SOURCE_JITTER=700 xpra start ..
and XPRA_SOUND_SOURCE_JITTER=1000 xpra start ...
But was unsuccessful. Even with the jitter, the graphs didn't show up any overruns (confirmed with Alex that I was doing nothing wrong).
I couldn't think of a way to perform the test with a bad connection (neither could Alex help me with that).
2) I performed the same test with the patch ​NSApplicationDidBecomeActive just to see if that makes any difference (as told by Alex)
Client---15.6-r10666---MacOSX10.10.3 Server---15.6-r10673---Fedora21
(I do know that the sound improvements are happening in 0.16.x)
Without any synthetic jitter being introduced, i noticed occasional breaks in audio, but it was just for a fraction of a second and it recovered itself immediately.
The corresponding client and server logs are here.
Client Logs:
2015-09-23 10:41:08,937 re-starting speaker because of overrun ** Message: pygobject_register_sinkfunc is deprecated (GstObject) 2015-09-23 10:41:09,805 sound-sink using audio codec: MPEG 1 Audio, Layer 3 (MP3) 2015-09-23 10:42:27,481 UI thread is now blocked 2015-09-23 10:42:27,497 UI thread is running again, resuming
Server Logs:
2015-09-23 10:41:09,142 using Pulseaudio device 'Monitor of Dummy Output' ** Message: pygobject_register_sinkfunc is deprecated (GstObject) 2015-09-23 10:41:09,545 sound-source codec: MPEG-1 Layer 3 (MP3)
I observed that the above logs are similar to the ones I had reported earlier, but I did not get any broken-pipe log during the entire session. So, I'm assuming that getting these logs are fairly normal.
Apart from this, there were no such instances that made the audio stop completely.
3) Performed the test with these versions:
Client---16.0-r10655---MacOSX10.10.3 Server---16.0-r10673---Fedora21
Without any synthetic jitter, it caused occasional overruns (just once, will attach screenshot below), and occasional audio breaks (about 5-6 times, each for a fraction of a second) throughout the session. It looked like it caused underruns most of the times during the session though. the graphs looked like this ----
But, as you explained in #849, underruns didn't cause the sound to stutter or stop.
At one point, I got these logs on the server side--- No broken-pipe error throughout.
2015-09-23 11:08:51,608 using pulseaudio device: 2015-09-23 11:08:51,608 'Monitor of Dummy Output' 2015-09-23 11:08:52,263 the remote printer '_10_0_11_62' has been configured [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED Vector smash protection is enabled. 2015-09-23 11:15:40,281 delayed_region_timeout: region is 15413ms old, bad connection?
Not really sure if this has anything to do with the current ticket. I don't think I can reproduce it either, as this is the first time I came across a bad connection log. But thought its better to bring this to your attention.
Just FYI, even with that bad connection log, the audio was fine. No delays or stutters.
As mentioned above, I noticed an overrun just once --- Here's the screenshot of it.
No corresponding "overrun" logs on either client or server side, and no difference in audio.
I also had an AirGap/Isla? session with a youtube video running simultaneously with xpra session. No prominent differences noticed in sound.
I am attaching an xpra info that I grabbed from the session --> ticket949_xpra_info.txt
With the synthetic jitter introduced with XPRA_SOUND_SOURCE_JITTER=700 xpra start ...
, there were occasional audio breaks (again, for a fraction of a second) - the frequency was very less compared to that of a session with no-jitter. The rest of the performance was just the same as in case of no-jitter.
In all the above cases, I observed 2 things ---
In all the above cases, I had an xpra session with youtube video. The default speaker codecs were mp3.
As you questioned in Comment 6, I couldn't reproduce the same result by introducing synthetic jitter with/without plugging headphones. Couldn't perform the test with bad connection.
If ever, I come across a situation where the sound goes off all of a sudden, I'll be sure to report to you. But I tried for the past 1 week to reproduce the issue, and was unsuccessful. The sound works fine.
Even with the jitter, the graphs didn't show up any overruns
We adjust the max queue in case of overruns, so you may not see them visually as lines intersecting, but instead as the max line going up.
If you really want to see overrun events, you have to use -d sound
and look in the output.
I did not get any broken-pipe log during the entire session
Broken pipe warnings can be ignored.
with the patch ​NSApplicationDidBecomeActive..
This patch is completely unrelated to sound processing. (see #949)
delayed_region_timeout: region is 15413ms old, bad connection?
This can happen with a bad connection or if there is a bug which prevents us from sending a delayed region. Sounds like the latter in this case, we would need a new ticket and reproduction steps for it. I believe it is very rare as I have not seen it for a long time, and the race conditions I am thinking of should be harmless - so I think we'll just ignore it for now.
then unplug the headphones. Doing this stops the sound..
This one sounds like a real bug.
Can you please open a ticket for this specifically?
Sounds like we need to detect sound output state changes and restart the pipeline - gstreamer 1.x may handle this better so we may have more luck in dealing with this after #970.
The sound worked absolutely fine and played without any audio breaks throughout the session.
I think we can close this ticket then?
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/949