xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

#949 closed defect (fixed)

Speaker sound goes off often

Reported by: pvenkateswaralu Owned by: pvenkateswaralu
Priority: critical Milestone: 0.16
Component: sound Version: 0.15.x
Keywords: speaker, sound, xpra Cc:

Description

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

Attachments (5)

xpra_949.png (79.8 KB) - added by pvenkateswaralu 5 years ago.
ticket949-sound-goes-off.text (125.1 KB) - added by pvenkateswaralu 5 years ago.
ticket949-underruns.png (23.2 KB) - added by pvenkateswaralu 5 years ago.
ticket949-overrun.png (25.7 KB) - added by pvenkateswaralu 5 years ago.
ticket949_xpra_info.txt (109.9 KB) - added by pvenkateswaralu 5 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to pvenkateswaralu

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.

comment:2 Changed 5 years ago by pvenkateswaralu

I'm using mp3 codecs. I've attached the screenshot of the session info.

Last edited 5 years ago by pvenkateswaralu (previous) (diff)

Changed 5 years ago by pvenkateswaralu

Attachment: xpra_949.png added

comment:3 Changed 5 years ago by Antoine Martin

Does the latest beta improve things? http://xpra.org/beta/osx/

comment:4 Changed 5 years ago by Antoine Martin

Priority: majorcritical

See #849, sound improvements are going in 0.16.

comment:5 in reply to:  3 Changed 5 years ago by pvenkateswaralu

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

Changed 5 years ago by pvenkateswaralu

comment:6 Changed 5 years ago by Antoine Martin

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..

comment:7 in reply to:  6 Changed 5 years ago by pvenkateswaralu

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

Last edited 5 years ago by pvenkateswaralu (previous) (diff)

comment:8 Changed 5 years ago by pvenkateswaralu

Owner: changed from pvenkateswaralu to Antoine Martin

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 ---

  • Have your headphones plugged in, play some audio or video with sound for sometime, and then unplug the headphones. Doing this stops the sound (does not play on loud speaker). That is, the speaker configuration wont change. Plugging back headphones won't make any difference (does not play sound back). Once the sound is gone, its gone. Must start a new session to get the sound back. Refreshing the page, and changing the sound settings to "ON" as mentioned in the ticket-description won't make any difference too.
  • Unplug your headphones and play the sound through loud speakers. Plugging in headphones wont make any difference. The sound still plays on loud speakers. Please note that the sound does not stop in this case.

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.

Changed 5 years ago by pvenkateswaralu

Attachment: ticket949-underruns.png added

Changed 5 years ago by pvenkateswaralu

Attachment: ticket949-overrun.png added

Changed 5 years ago by pvenkateswaralu

Attachment: ticket949_xpra_info.txt added

comment:9 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to pvenkateswaralu

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?

comment:10 Changed 5 years ago by pvenkateswaralu

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.