#1507 closed defect (fixed)
html5 client sound forwarding broke
| Reported by: | Antoine Martin | Owned by: | alas |
|---|---|---|---|
| Priority: | major | Milestone: | 2.1 |
| Component: | html5 | Version: | trunk |
| Keywords: | Cc: |
Description
Originally reported in ticket:845#comment:28.
Affects trunk and 2.0
Change History (6)
comment:1 Changed 5 years ago by
| Status: | new → assigned |
|---|
comment:2 Changed 5 years ago by
With older versions, the "sound-data" packets contain buffers using the [object Array] datatype, whereas the new code uses Uint8Array.
Oh javascript, why you so flaky.
Fixed in r15697 (will need backporting to v2.0).
Still TODO: fix legacy:mp3?
comment:3 Changed 5 years ago by
Found another pair of gems: r15698, r15704 + r15705.
(but I thought we had fallback code for this?)
We do... but it was broken in some cases, fixed in r15701.
Backports for all of the above in: r15706, r15702, r15700.
Minor sound related improvement in r15703.
Then, r15707 improves the buffer handling: we keep the network layer zero-copy buffers until we submit them to the audio decoder. (unlikely to backport this one because it may break something)
comment:4 Changed 5 years ago by
| Owner: | changed from Antoine Martin to alas |
|---|---|
| Status: | assigned → new |
@afarr: mostly a FYI - feel free to close. Sound should now be fixed in 2.0 - and it is also using zero-copy in trunk - the "legacy" decoding issues are now tracked in #1509.
comment:6 Changed 12 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1507
copyleft 2010 - 2021
Bisection:
So that's caused by r15183 which is "#1424: zero copy whenever possible in the network layer".
It's probably sending the wrong datatype down to the audio decoders.
The problems with "legacy:mp3" could just be caused by the lack of mp3 support on the server:
(but I thought we had fallback code for this?)