Related to #1212, r12638, #1074, #1075.
Worked OK for me:
No workee:
Not tested:
This is a blocker bug because the defaults don't work. Is this a new thing? When did this regression start? And why didn't we spot it earlier? Is this caused by ticket:1168#comment:3 (tested on El Capitan). Does it work on other versions of OSX?
What do we do? Ideally, try #1168 first. Then maybe we have to disable more codecs on OSX?
Handing this to myself so I can get info from various machines.
Please note:
My testing steps are to connect with a --speaker-codec=$codec
and walk through the available codecs listed in the Session Info page. I'm not bothering to test quality, just to see if they blow up in my face or not.
On an OSX 10.11 Machine (Trashcan aka MacPro?):
Codec Name | Works? |
opus+gdp | yes |
opus+ogg | yes |
vorbis+gdp | no |
vorbis+mka | no |
flac+gdp | no |
mp3 | no |
aac+gdp | no matching |
aac+mpeg4 | no matching |
raw+gdp+lz4 | yes |
raw+gdp | yes |
wav+lz4 | yes |
wav | yes |
wavpack | yes |
speex+gdp | no |
speex+ogg | no |
Edit: Turns out the server doesn't support AAC....
OSX 10.10 machine (Macbook Pro)
Codec Name | Works? |
opus+gdp | yes |
opus+ogg | yes |
vorbis+gdp | no |
vorbis+mka | no |
flac+gdp | no |
mp3 | no |
aac+gdp | no matching |
aac+mpeg4 | no matching |
raw+gdp+lz4 | yes |
raw+gdp | yes |
wav+lz4 | yes |
wav | yes |
wavpack | yes |
speex+gdp | no |
speex+ogg | no |
OSX 10.9 machine (also Macbook Pro)
Codec Name | Works? |
opus+gdp | yes |
opus+ogg | yes |
vorbis+gdp | yes |
vorbis+mka | yes |
flac+gdp | yes |
mp3 | yes |
aac+gdp | no |
aac+mpeg4 | yes |
raw+gdp+lz4 | yes |
raw+gdp | yes |
wav+lz4 | yes |
wav | yes |
wavpack | yes |
speex+gdp | yes |
speex+ogg | yes |
I suppose you might've already seen the errors, but with aac+gdp (the only codec that didn't work with my un-updated osx) I got the following messages:
2016-08-11 13:32:09,206 sound output pipeline error: gst-stream-error-quark: Could not decode stream. (7) 2016-08-11 13:32:09,206 sound output gstaudiodecoder.c(1632) 2016-08-11 13:32:09,206 sound output gst_audio_decoder_push_buffers () 2016-08-11 13:32:09,206 sound output /GstPipeline:pipeline0/GstFaad:faad0: 2016-08-11 13:32:09,206 sound output failed to parse stream 2016-08-11 13:32:09,207 sound output stopping 2016-08-11 13:32:09,224 stopping speaker because of error: gst-stream-error-quark: Could not decode stream. (7) 2016-08-11 13:32:09.836 xpra[68335:d0b] unlockFocus called too many times. Called on <GdkQuartzView: 0x18401f0>.
In any case, it looks like it is the 10.10 update that is breaking things.
On win32: all works, except the ones we already disable explicitly in the code (not re-tested - I assume still broken, may re-test when the gio bindings are updated with a newer gstreamer version): aac+gdp, speex+gdp, speex+ogg.
I couldn't test OSX 10.6.x because the VM lacks a virtual sound device.
Every VM pre-10.10 VM I tested (10.5.8, 10.6.8, 10.7.x, 10.8.x, 10.9.x) worked with every codec, including aac+gdp. (weird) @maxmylyn: please post the server side sound information so we can see what pipeline generated this aac stream (I do remember that we support different combinations of gstreamer elements to produce aac, maybe your setup uses a different combination)
With 10.10 I get a invalid channel positions and internal data flow error with almost every codec, probably something wrong with the sound drivers on this VM. The only ones that work are: wav variants, aac variants. This looks related: osxaudiosink: Invalid channel positions warning with headerless wav file.
Unfortunately, the patch does not apply to the 1.6.x branch, so I can't test to see if that helps. We need #1168 to know what to try next.
If this doesn't solve it, we will have to add a platform version test, something like this:
> import plistlib > pl = plistlib.readPlist('/System/Library/CoreServices/SystemVersion.plist') > pl {'ProductUserVisibleVersion': '10.11.1', 'ProductCopyright': '1983-2015 Apple Inc.', 'ProductVersion': '10.11.1', 'ProductBuildVersion': '15B42', 'ProductName': 'Mac OS X'}
@maxmylyn / afarr: see comment:4, also when you said Works = no, what was the error? "Could not decode stream" or "invalid channel positions" followed by "internal data flow error"?
For me, when I said "Works = no" it was the same error - "invalid channel positions" followed by "internal data flow error". Every time.
The end of comment:3 said that he saw the "Could not decode stream" rather than what I saw.
Lastly, -d sound
didn't produce anything other than the server does not support aac
at all. I'll poke around my machine this afternoon and see what package(s) I'm missing.
Well here's the relevant bit anyways:
2016-08-12 09:13:38,116 Handshake complete; enabling connection[0m [36m2016-08-12 09:13:38,120 pulseaudio id=None, server=None, sound decoders=['aac+gdp'], sound encoders=['vorbis+gdp', 'vorbis+gdp', 'vorbis+mka', 'flac+gdp', 'mp3', 'aac+gdp', 'aac+mpeg4', 'raw+gdp+lz4', 'raw+gdp', 'wav+lz4', 'wav', 'wavpack', 'speex+gdp', 'speex+ogg', 'speex+ogg'], receive=True, send=True[0m 2016-08-12 09:13:38,121 Python/Gtk2 Mac OS X client version 1.0-r13235 32-bit[0m 2016-08-12 09:13:38,121 connected from [censored][0m 2016-08-12 09:13:38,122 using h264 as primary encoding also available:[0m 2016-08-12 09:13:38,122 vp9, vp8, mpeg4, png, png/P, png/L, rgb24, jpeg, rgb32[0m 2016-08-12 09:13:38,124 client root window size is 1920x1080 with 1 display:[0m 2016-08-12 09:13:38,124 trashcan.local (677x381 mm - DPI: 72x72)[0m 2016-08-12 09:13:38,125 monitor 1[0m 2016-08-12 09:13:38,125 best resolution matching 1920x1080 is unchanged: 1920x1080[0m 2016-08-12 09:13:38,129 setting keyboard layout to 'us'[0m [31m2016-08-12 09:13:38,184 client 7: Error: no matching codecs between client and server[0m [31m2016-08-12 09:13:38,188 client 7: server supports: opus+gdp, opus+ogg, vorbis+gdp, vorbis+mka, flac+gdp, mp3, raw+gdp+lz4, raw+gdp+lzo, raw+gdp, wav+lz4, wav+lzo, wav, wavpack, speex+gdp, speex+ogg[0m [31m2016-08-12 09:13:38,188 client 7: client supports: aac+gdp[0m 2016-08-12 09:13:38,188 client 7: Attached to tcp:10.0.32.170:2200 (press Control-C to detach)[0m [36m2016-08-12 09:13:41,254 stop_sending_sound() sound_source=None[0m [36m2016-08-12 09:13:41,255 stop_receiving_sound() sound_sink=None[0m 2016-08-12 09:13:41,255 xpra client 7 disconnected.[0m
#1168 seems to have done the trick for me.
We still get this warning: WARNING: 140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent?.h., hopefully this will be fixes in the next gstreamer release. Or maybe moving to a newer build environment (#840) will allow it to use the newer headers and API?
Please re-test the latest trunk and the 0.17.5 release candidate. Ensure there are no memory leaks, etc..
Also, is aac+gdp
still a problem on 10.9 for you?
With the trunk latest r13447:
EDIT: tested the wrong client version, updated this info after testing the correct client version. No changes as to what works and what doesn't. Chrome caching strikes again!
Codec Name | Works? |
opus+gdp | no |
opus+ogg | yes |
vorbis+gdp | yes |
vorbis+mka | yes |
flac+gdp | yes |
mp3 | yes |
aac+gdp | yes |
aac+mpeg4 | yes |
raw+gdp+lz4 | yes |
raw+gdp | yes |
wav+lz4 | yes |
wav | yes |
wavpack | yes |
speex+gdp | yes |
speex+ogg | yes |
Oddly enough, opus+gdp
has stopped working(EDIT: "internal data flow error" - no "invalid channel" print), but all the other codecs are. And, the aac+gdp
issue is limited to one specific server - I'm missing a package to get it, will look into it, but that server is broken - #1291.
Also of note:
cmd+Q
. Using a sig-int hangs after it prints sound output stopping
: #1292.
And, using the 0.17.5 release candidate r13418:
Codec Name | Works? |
opus+gdp | not available |
opus+ogg | not available |
vorbis | yes |
vorbis+mka | yes |
flac | not available |
flac+gdp | yes |
mp3 | yes |
aac+gdp | not available |
aac+mpeg4 | not available |
raw+gdp+lz4 | not available |
raw+gdp | not available |
wav+lz4 | yes |
wav | yes |
wavpack | yes |
speex+gdp | yes |
speex | yes |
The ones marked not available
- self explanatory, the client spits out that that is an incorrect option. But, nothing was outright broken in 10.11. I'll get lunch and come back and try 10.9 and 10.10. And then, I'll check the 0.17.5 and the 1.0 more thoroughly. In the meantime, I'll hold on to this ticket.
And using an OSX 10.10 machine(afarr has the 10.9):
Codec Name | Works? |
opus+gdp | no |
opus+ogg | yes |
vorbis+gdp | yes |
vorbis+mka | yes |
flac+gdp | yes |
mp3 | yes |
aac+gdp | yes |
aac+mpeg4 | yes |
raw+gdp+lz4 | yes |
raw+gdp | yes |
wav+lz4 | yes |
wav | yes |
wavpack | yes |
speex+gdp | yes |
speex+ogg | yes |
opus+gdp
error - very consistent with 10.11.
Using the 0.17.5 release candidate r13418:
Codec Name | Works? |
opus+gdp | not available |
opus+ogg | not available |
vorbis | yes |
vorbis+mka | yes |
flac+gdp | yes |
mp3 | yes |
aac+gdp | not available |
aac+mpeg4 | not available |
raw+gdp+lz4 | not available |
raw+gdp | not available |
wav | yes |
wavpack | yes |
speex+gdp | yes |
speex | yes |
And, now I'll do some more in-depth testing on my 10.10 machine as it uses the monitor that's less likely to cause neck damage after prolonged period of use.
Finished with the 0.17.5 Client:
speek+gdp
was a little scratchy when watching a YouTube? video, but otherwise everything performed great without any noticeable issues.
speex+gdp
being a little scratchy.
Moving on to the 1.0 Client.
Testing with a 1.0 r13447 osx client on a 10.9 osx, against 1.0 r13448 fedora 23 server. (As an odd side note, shift+alt+F11 wasn't opening Session Info with the combo, had to use the client's application menus... no logs on either side.)
Codec Name | Works? |
opus+gdp | no |
opus+ogg | yes |
vorbis+gdp | yes |
vorbis+mka | yes |
flac+gdp | yes |
mp3 | yes |
aac+gdp | no |
aac+mpeg4 | yes |
raw+gdp+lz4 | yes |
raw+gdp | yes |
wav+lz4 | yes |
wav | yes |
wavpack | yes |
speex+gdp | yes |
speex+ogg | yes |
2016-08-23 18:14:52,251 sound output pipeline error: gst-stream-error-quark: Internal data flow error. (1) 2016-08-23 18:14:52,251 sound output gstbasesrc.c(2948) 2016-08-23 18:14:52,251 sound output gst_base_src_loop () 2016-08-23 18:14:52,251 sound output /GstPipeline:pipeline0/GstAppSrc:src: 2016-08-23 18:14:52,251 sound output streaming task paused, reason not-negotiated (-4) 2016-08-23 18:14:52,251 sound output stopping 2016-08-23 18:14:52,288 stopping speaker because of error: gst-stream-error-quark: Internal data flow error. (1)
2016-08-23 18:20:30,539 sound output using audio codec aac 2016-08-23 18:20:30,540 sound output using container format gdp 2016-08-23 18:20:40,419 sound output pipeline error: gst-stream-error-quark: Could not decode stream. (7) 2016-08-23 18:20:40,419 sound output gstaudiodecoder.c(1568) 2016-08-23 18:20:40,419 sound output gst_audio_decoder_push_buffers () 2016-08-23 18:20:40,419 sound output /GstPipeline:pipeline0/GstFaad:faad0: 2016-08-23 18:20:40,420 sound output failed to parse stream 2016-08-23 18:20:40,420 sound output stopping 2016-08-23 18:20:40,432 stopping speaker because of error: gst-stream-error-quark: Could not decode stream. (7) 2016-08-23 18:20:40.961 xpra[12881:d0b] unlockFocus called too many times. Called on <GdkQuartzView: 0x4e93f0>.
Testing with both Fedora 23 and Fedora 24 servers, I can see the gdp variants failing only when connecting to Fedora 23. The main difference is that Fedora 23 runs GStreamer 1.6.x whereas Fedora 24 uses 1.8.x
We have switched to gstreamer 1.8.x (#1168) around the same time, so this has gone unnoticed until now: r13449 changes the codec order so that the formats that use the gdp muxer will end up at the end of the list. (will backport).
r13450 filters the codecs to remove the "gdp" variants if we find that the server gstreamer version is different from the client's. But that's just ugly and brittle, and it would still show those options as available on the command line (--speaker-codec=help
, so r13451 just removes all gdp options (undoes #1075) - we have enough codec options anyway.
Please re-test, both against gstreamer 1.6.x (ie: Fedora 23) and gstreamer 1.8.x (ie: Fedora 24)
Finished my testing of the 1.0 client:
aac+mpeg4
had a little tiny bit of scratchiness
Will retest with different gstreamer versions on Friday.
The aac+mpeg4 issue should be tracked in #1194 or maybe a new OSX specific ticket if that's where the problem lies. mpeg4 is important for sound support with the html5 client.
Will retest with different gstreamer versions on Friday.
Please make sure to re-test with a 1.8.3 gstreamer (ticket:1168#comment:9) and record mpeg4 issues in #1194.
Update:
Got the GST quark error against a Debian Jessie 17.5 server with a Fedora 24 17.5 client at home. Will investigate - probably related to older ffmpeg, unless it's not. Just jotting this down here so I don't forget.
I was seeing some errors with older distros running gstreamer 0.10, so we now only enable "matroska" on gstreamer 1.x: r14339.
Okay, upped server to r14364 - with two different machines - one is Fedora 24 and the other is Fedora 23. Both are built from latest trunk source (r14364) - the client machine is an OSX 10.11 machine running a trunk r14155 Client:
Test steps are the same - connect and see if sound doesn't blow up or not.
Against the Fedora 24 machine:
Codec Name | Works? |
opus+gdp | not supported by client |
opus+ogg | yes |
vorbis+gdp | not supported by client |
vorbis+mka | yes |
flac+gdp | yes |
mp3 | yes |
aac+gdp | not supported by client |
aac+mpeg4 | yes |
raw+gdp+lz4 | not supported by client |
raw+gdp | not supported by client |
wav+lz4 | yes |
wav | yes |
wavpack | yes |
speex+gdp | not supported by client |
speex+ogg | yes |
Again, against a Fedora 23 machine (older):
Codec Name | Works? |
opus+gdp | not supported by client |
opus+ogg | yes |
vorbis+gdp | not supported by client |
vorbis+mka | yes |
flac+gdp | not supported by client |
mp3 | yes |
aac+gdp | not supported by client |
aac+mpeg4 | server has it disabled |
raw+gdp+lz4 | not supported by client |
raw+gdp | not supported by client |
wav+lz4 | not supported by server |
wav | yes |
wavpack | yes |
speex+gdp | yes |
speex+ogg | yes |
---
It would seem that the newer trunk builds have notably fewer codecs enabled, but all the ones enabled, but all the ones enabled do work.
Passing back to you - everything seems to be behaving nicely, at least for what's enabled.
All the "gdp" options have been removed, see comment:13 for details.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1276