Sound does not work properly in Flash in firefox
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
flash-player (Ubuntu) |
Invalid
|
Medium
|
Unassigned | ||
flashplugin-nonfree (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
affects /distros/
affects /distros/
done
Sound does not work in Flash in firefox. This is because I am about
to (in my next upload) turn off the hack that makes it work.
Basic facts as I understand them:
* Firefox itself uses libesd from ./widget/
and I expect this to continue to work.
* The Flash player (which is not Free Software) opens /dev/dsp
directly. This (a) causes contention with other applications
over /dev/dsp (which can only be opened once) and (b) does not work
if the player (ie, the browser) is not running on the machine
sitting in front of the user (eg, ltsp/thincl, or many other
situations).
Previously the problems with Flash and /dev/dsp have been worked
around by use of a wrapper `esddsp' provided by esound-clients.
esddsp is a fairly simple shell script which basically LD_PRELOADs a
library provided by esddsp which wraps open, ioctl, connect, and a
number of other important system calls and library functions; it then
executes the target program. So, firefox is invoked as esddsp firefox
and runs with this LD_PRELOAD hack. This means that all of firefox's
uses of these calls are, in the first instance, handled by the wrapper.
The file in esound which provides the LD_PRELOAD wrappers, esddsp.c
(and also stdioemu.c) describes itself as an `Evil evil evil hack'.
This is an accurate description. Additionally, the esddsp script
warns that it `[allows] *some* binary only programs to use esd'.
This is an accurate caveat.
The esddsp.c wrapper functions have a number of problems:
* They are not appropriately threadsafe;
* They will go wrong if the calling program opens /dev/dsp more than
once;
* They do not use RTLD_NEXT, so that they will interfere with other
LD_PRELOAD hacks.
* They wrap up stdio functions for no readily apparent reason. (The
reason documented in the source code is wrong.)
Furthermore, these problems are not readily fixable because:
* Many system calls need overriding;
* The resulting code is (almost inevitably) too complex to be
wholly reliable.
It is therefore my opinion that the instabilities these arrangements
introduce into the operating system's core web browser are
(a) unacceptable and (b) not straightforward to remedy while
maintaining the current approach.
I will therefore be changing the default configuration of dapper's
firefox so that it does not use the LD_PRELOAD hack. This will make
the web browser more stable but cause trouble with sound for users
using Flash. I consider this the appropriate tradeoff.
Users who find this inconvenient can turn the hack back on but may
of course find that their browser is unstable.
I would recommend the following alternative approaches to solving this
problem:
1. Fix esddsp and use it only where appropriate:
* Rewrite esddsp.c so that every wrapped entrypoint is not made less
threadsafe and not much less concurrent. Each entrypoint should
(i) acquire mutex; (ii) check fd against list or bitmap of esd fd's;
(iii) if fd is not esddsp's, release mutex and go to RTLD_NEXT
function; (iv) call appropriate esd function; (v) release mutex.
This should be done by boilerplate code generated by a macro or
code generator, not written out by hand.
* Change the names of the provided wrapper functions in esddsp in a
systematic way so that it is possible to:
* Have the Flash installer edit the symbol table of the Flash plugin
(but not of anything else) to refer to wrapper functions.
* Fix the other problems with esddsp (see above).
or
2. Write a kernel driver which allows /dev/dsp to be routed to a
user-space program (just as tty's were so routed many years ago
when pty's were introduced).
or
3. Write or use a generic kernel driver for user-space provision of
char devices, or user-space provision of ioctls. FUSE may be able
to help here.
Additionally, it is clear that plugins for firefox should not run in
the same process as the web browser. However this is an intractable
problem and quite possibly even a design problem with the browser. It
is clear that doing that is well beyond the capability of the Ubuntu
team.
Ian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://
iD8DBQFD2K+
QlFldsV86xqz07c
=hII1
-----END PGP SIGNATURE-----
Changed in flash-player: | |
status: | Confirmed → Rejected |
Changed in flashplugin-nonfree: | |
status: | Rejected → In Progress |
Changed in flashplugin-nonfree: | |
assignee: | nobody → rganoom |
Changed in flashplugin-nonfree (Ubuntu): | |
assignee: | nobody → txapastosca (deckardroybatty) |
assignee: | txapastosca (deckardroybatty) → nobody |
Changed in flashplugin-nonfree (Ubuntu): | |
status: | Fix Released → Fix Committed |
status: | Fix Committed → Fix Released |
Changed in flashplugin-nonfree (Ubuntu): | |
status: | Fix Released → Fix Committed |
Changed in flashplugin-nonfree (Ubuntu): | |
status: | Fix Committed → Fix Released |
thats right i had to use a trick mentionned in ubuntu-fr wiki.
tenshu