No Sound with Flash in Firefox
gmccullagh at gmail.com
Fri Jul 13 09:58:30 BST 2007
you're a fair way deeper into this than I've been but hopefully some of
this will help.
On Thu, 12 Jul 2007, Jim Kronebusch wrote:
> > So you're running 64-bit Ubuntu with 32-Bit Firefox on the server and
> > presumably a 32-bit thin client system. I've personally never run flash on
> > 64-bit ubuntu.
> I am running 64-bit edubuntu feisty. I have tried 32-bit flash under 64-bit firefox
> via nswrapper, I tried 32-bit firefox with 32-bit flash and I also tried the
> Automatix2 install of 32-bit swiftfox with 32-bit flash. All have the same error.
At the end of the day, all of these end up with you running 32-bit
pulseaudio libflashsupport on a 64-bit system. That may be problem (though
I could well be wrong). You can probably compile 64-bit pulseaudio
libflashsupport using the sources here:
but it's not clear to me if the adobe flash plugin will talk to the 64-bit
library -- I'd guess not.
> > I'd recommend you use 32-bit Ubuntu, not 64-bit.
> I need to use 64-bit in order to recognize the 16GB of RAM (maybe more in
> the future). Also the machine is Dual Quad Core Xeon machine so I want
> to be sure I get the most out of the processors. I will be serving 110
> clients from this server so I need all the horsepower I can get.
That's not entirely true. 32-bit linux can address greater than 4GB RAM
using PAE (Physical Address Extension). This feature (as I understand it)
is compiled into the linux-image-server packages on 32-bit (ed)ubuntu so
you should be able to address the full available RAM.
There is some performance penalty to using PAE, but I'd be lying if I said
I understood the details. A colleague of mine recently said he had used
PAE on FreeBSD and that depending on what you're doing it can work pretty
well. I believe PAE has been fairly widely used in large environments. As
you say the cpu performance is less with emulated 32-bit, but they should
still be pretty quick. People have run 30-40 users with older dual single
core xeons, though it's hard to know how that will scale up.
If you need flash (and java, etc.) to work well, I'd be inclined to try the
32-bit. I believe Java is going to be more freely distributable soon so
maybe that issue will go away, but you might also need adobe acrobat
reader, skype, etc. One assumes they will release 64-bit linux versions at
some point, but who knows when. You can run 32-bit apps in 64-bit systems
using these tricks, but it's not a solution I'd like to roll out to 110
users. In fairness to the ubuntu developers, it's almost impossible for
them to support flash at all, with no access to source and when adobe
haven't even ported it to 64-bit yet.
My instincts with large numbers of people are generally to run with tried
and tested stuff to maintain stability.
> > Are you running Gutsy?
> Funny you should ask. Not at first. I have been trying to get local apps working
> with LDAP on the server, the /opt/ltsp/i386 configured as an LDAP client and /home
> mounted on boot and openssh server running on the client and a local firefox and flash
> installed into /opt/ltsp/i386. Then the server accessing firefox via ssh from the
> client. My testing has firefox running and checking processes confirms it is running
> from the client, but the start time for the app is simply unacceptable. So until I
> can get that figured out local apps aren't an option. So I read that
> local apps are a goal in Gutsy and I was looking for a desperate fix for
> the sound issue
You're a brave man to do experimental stuff like this with so many users
Does it run okay once it's started? I suppose you must have:
- ldm runs ssh client -> server
- firefox ssh runs server -> client
- firefox executes on client
- client gets firefox libs & binaries from server over nfs
- client executes firefox locally
- client gets firefox user profile over nfs
- client sends window data back to server over ssh
- server sends window data back to client over ldm ssh session
Off the top of my head. The startup time could be slowed down by:
- plain old slow cpu on the client. What's the spec?
- lack of RAM on the client causing network swap to be used
- DNS pausing issues in starting the ssh session (you could test this by
running ssh from command line perhaps with no X11, then with xeyes and
- NFS slowness serving out the binaries. There's quite a bit you can tune
here -- use of NFS, changing block sizes, etc.
- overhead of doubled ssh encryption. I think it should be possible for
you to ssh to the client and run "export DISPLAY=localhost:0" so as not
to send the window back to the server. You might have to run something
like "xhost +localhost" within ldm to achieve this. This is what the "no
encryption" stuff does. You could also run ssh with
'-c blowfish-cbc,aes128-cbc,3des-cbc' so as to use a cheaper encryption
cipher (the ldm ssh session does this).
> apt-get dist-upgrade.....I successfully (take that word with a grain of salt) upgraded
> a stand alone workstation to Gutsy to play with, but it appears that the Edubuntu
> efforts must not be as far along. Apt broke all over with dependancy errors and I
> have been screwing around trying to fix that. From what has loaded so far my clients
> still have the same sound issues.
The -kiosk option in ltsp-build-client installs firefox for local use. You
might get some clues from it as to how best to get firefox installed on the
> I have read success stories all over on running 32-bit Firefox w/Flash under 64-bit
> OS, but I just can't get it to work with sound. I hate flash.
The difference is they aren't using thin clients. Until recently flash
didn't work with sound on thin clients, period. Only the most recent flash
plugin with extra pulseaudio support added by the revolutionlinux guys
> All other apps I need work perfectly and are stable. If I could just get
> sound working on flash I would be set. This is a major holdup up however
> and this is the year I am making a 100% changeover to Linux at the
> student level and no flash will look pretty poor on my part. I might try
> building a secondary server dedicated to running 32-bit apps next and
> tunnel them to the main server via ssh....in fact I'll start that
I'm not saying that can't work, but I really don't like the sound of it.
Firefox is I suspect, the _key_ application in most school environments.
Running it in such a hackish way is probably asking for trouble. By the
time you spend all those extra cpu cycles on ssh tunnelling 60 firefox
sessions from 32-bit to 64-bit machine and then down to the clients, as
well as sending the sound direct to the client (I'd try and short-cut the
sound using the environment variable), I'd say your performance might well
be lower than using PAE and 32-bit ubuntu. You'll also need a lot of RAM
on the secondary server if it's going to run firefox for 80 users at a time
(firefox is one of the big RAM hogs that makes the main server need all
that RAM in the first place). If you ran both 32-bit, you might be able to
use the spare machine to load balance with the main one.
I hope some of this is helpful and what way you go is of course entirely up
to you. These are just my instincts were I in your situation.
Good luck and let us know how you get on, this is all very interesting
stuff for the list,
More information about the edubuntu-users