Speaker sound goes off often

[totaam]

Issue migrated from trac ticket # 949

component: sound | priority: critical | resolution: fixed | keywords: speaker, sound, xpra

2015-08-17 20:44:44: pvenkateswaralu created the issue

---

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

[totaam]

2015-08-18 03:22:56: antoine changed owner from antoine to pvenkateswaralu

[totaam]

2015-08-18 03:22:56: antoine commented

---

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.

[totaam]

2015-08-18 19:13:18: pvenkateswaralu commented

---

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

[totaam]

2015-08-18 19:16:21: pvenkateswaralu uploaded file xpra_949.png (79.8 KiB)

[totaam]

2015-08-21 03:34:22: antoine commented

---

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

[totaam]

2015-08-30 11:09:06: antoine changed priority from major to critical

[totaam]

2015-08-30 11:09:06: antoine commented

---

See #849, sound improvements are going in 0.16.

[totaam]

2015-09-02 01:11:33: pvenkateswaralu commented

---

Replying to [comment:3 antoine]:

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

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

[totaam]

2015-09-02 01:11:59: pvenkateswaralu uploaded file ticket949-sound-goes-off.text (125.1 KiB)

[totaam]

2015-09-02 04:44:09: antoine commented

---

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

[totaam]

2015-09-02 18:14:04: pvenkateswaralu commented

---

Replying to [comment:6 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

[totaam]

2015-09-23 22:57:36: pvenkateswaralu changed owner from pvenkateswaralu to antoine

[totaam]

2015-09-23 22:57:36: pvenkateswaralu commented

---

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

[[Image(ticket949-underruns.png)]]

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.

[[Image(ticket949-overrun.png)]]

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.

[totaam]

2015-09-23 22:58:16: pvenkateswaralu uploaded file ticket949-underruns.png (23.2 KiB)

[totaam]

2015-09-23 22:58:28: pvenkateswaralu uploaded file ticket949-overrun.png (25.7 KiB)

[totaam]

2015-09-23 22:58:47: pvenkateswaralu uploaded file ticket949_xpra_info.txt (109.9 KiB)

[totaam]

2015-09-24 08:58:37: antoine changed owner from antoine to pvenkateswaralu

[totaam]

2015-09-24 08:58:37: antoine commented

---

Even with the jitter, the graphs didn't show up any overruns
[[BR]]
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.
[[BR]]

I did not get any broken-pipe log during the entire session
[[BR]]
Broken pipe warnings can be ignored.
[[BR]]

with the patch ​NSApplicationDidBecomeActive..
[[BR]]
This patch is completely unrelated to sound processing. (see #949)
[[BR]]

delayed_region_timeout: region is 15413ms old, bad connection?
[[BR]]
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.
[[BR]]

then unplug the headphones. Doing this stops the sound..
[[BR]]
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.

[[BR]]

The sound worked absolutely fine and played without any audio breaks throughout the session.
[[BR]]

I think we can close this ticket then?

[totaam]

2015-09-24 17:06:41: pvenkateswaralu changed status from new to closed

[totaam]

2015-09-24 17:06:41: pvenkateswaralu set resolution to fixed