After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 98363 - Login takes much too long if startup sound file is long
Login takes much too long if startup sound file is long
Status: RESOLVED OBSOLETE
Product: gnome-session
Classification: Core
Component: general
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-11-13 06:11 UTC by Elijah Newren
Modified: 2014-12-15 21:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Elijah Newren 2002-11-13 06:11:46 UTC
I tried to explain this to one of the guys in #bugs on irc.gnome.org, and
it became apparent that I'll probably need to be fairly verbose in this
report to make sure others understand what I'm saying and what is happening.

Let me describe the login steps in my words.  First is the gdm login
screen.  Upon entering my username and password, the gdm login screen
disappears and a few seconds later I get the login splash screen (defined
at /usr/share/pixmaps/splash/gnome-splash.png).  This is followed by some
icons that appear in the lower left corner of the login splash screen.  A
few seconds later the login splash screen disappears and the gnome desktop
with all the icons and panels and such appear.

Now, I timed all this over and over with my stopwatch.  I know that's a
crude method, but, surprisingly, I think my results are no worse than a
quarter of a second off (I expected no better than half a second; but I
timed each thing about 5 times and compared the times and I was extremely
consistent).  So I'll report an approximate time that is the average of the
times I recorded.  For reference, I'm running on an Athlon 800 Mhz processor.

Here are the events that I timed (all in seconds):

  E1 - Time from pressing enter after entering password until the login
       splash screen appears.
  E2 - Amount of time after login splash screen appears until first icon
       appears in the lower left of the login splash screen.

With the "Enable sound server startup" in the 'Sound Preferences' turned
OFF, I get the following approximate timings:

  E1 - 2.70
  E2 - 0.90  (This one was a little hard and seemed more prone to error)

With the "Enable sound server startup" turned to ON, I get very different
timings for E2 and only marginally different timings for E1.  Note that the
sound starts playing at almost exactly the same time that the splash screen
appears.  I'm not totally sure which comes first, but I'd place money on
the sound playing before the splash screen appears.  Thus the sound server
starting up is measured as part of E1.  Anyway with the default gnome
startup sound (defined at 'GNOME system events'->'Login' in Sound Events),
which is a 2 second .wav file (according to xmms, I don't know how to get
the durations of sound files any more accurate), I get the following timings:

  E1 - 2.81
  E2 - 2.29

Now, for the following two cases, E1 is the same as above so I won't report
it.  For an 8 second .wav file used instead of the default gnome startup
sound, I get:

  E2 - 5.73

and for a 26 second .wave file used for the startup sound I get

  E2 - 5.77

So, it seems that starting up the sound server takes a little longer, but
it's very difficult to even measure.  However, there is a significant delay
while waiting for the sound file before the login process continues.  It
seems that the login will not continue at all when a sound is being played,
unless somewhere around fives seconds first elapses (or, of course, the
file finishes playing).

This seems like an embarrasingly long pause for trying to show off to my
windows friends, especially since the whole login process only takes around
10 seconds (I wasn't sure when to quit on that one and I only timed it
once, so this is the most rough number).  Is there any way to get gnome to
continue with the login while the startup sound is playing so as to get rid
of this pause?

Let me know if you need any more information for this bug.  I'd even be
happy to try to help track it down and fix it if you can give me some
pointers where to start.  I do know a little C and C++, though I'm not a
computer scientist and I haven't done any Gnome/GTK programming (yet).
Comment 1 Elijah Newren 2002-11-13 21:19:14 UTC
Well, I've been reading through the gnome-session bugs and it appears
(just a guess) that this bug might be related to bug #91273.  I'll see
if I can try to duplicate that bug when I get home tonight; hopefully
I'll have some time...
Comment 2 Elijah Newren 2002-12-02 18:02:23 UTC
Well, I've done some more searching.  I no longer believe this is
related to bug 91273.  Anyway, in searching through the code (I have
garnome 0.18.3 now), this is what I've found:

In the file gsm-sound.c, at lines 71-81, the code reads:
  starttime = time (NULL);
  gnome_sound_init (NULL);

  while (gnome_sound_connection_get () < 0
         && ((time(NULL) - starttime) < 4))
    {
#ifdef HAVE_USLEEP
      usleep(200);
#endif
      gnome_sound_init(NULL);
    }
I don't see what the second part of the while loop needs to be there.
 That is, why can't
  while (gnome_sound_connection_get () < 0
         && ((time(NULL) - starttime) < 4))
be changed to
  while (gnome_sound_connection_get () < 0)
?  Note also, that if this is truly the part of the code slowing
things down (I don't really know), then the slowdown is about 4
seconds.  Unfortunately I have been unable to test this, as Jeff Waugh
says that startup sounds aren't supported under garnome.  I'll keep
trying to figure this out (and I'll try to figure out 91273 too) and
do more tests, but I thought I'd at least add what I've found so far.
Comment 3 Tom Tromey 2006-09-27 00:51:26 UTC
I think the second part of the loop condition is there to make
gnome-session continue its work if it takes more than 4 seconds
to get a sound connection.

So, I don't think this condition can be causing the problem.


Comment 4 Ray Strode [halfline] 2014-12-15 21:09:31 UTC
presumably this problem is no longer actually a problem...