scratch team mailing list archive

[Derek O'Connell <doc@xxxxxxxxxxxxxxxxx>]

FYI

-------- Original Message --------
Subject: Re: [squeak-dev] Re: Sound latchup problem is back with 
Squeak-4.0.3.2202-linux_i386.tar.gz (Ubuntu/Linux)
Date: Wed, 14 Apr 2010 10:32:39 +0100
From: Derek O'Connell <doconnel@xxxxxxxxx>
To: squeak-dev@xxxxxxxxxxxxxxxxxxxxxxxxxx

On 14/04/10 09:26, Andreas Raab wrote:
>  On 4/14/2010 1:19 AM, Jerome Peace wrote:
> > Derek>:There is a preference under "media" called
> > "soundStopWhenDone" which, if enabled, stops the process when the
> > sound queue is empty and brings CPU usage back down to normal.
> >
> > Well that seems to work. Can we get the image be released with
> > this as the default? Or with this as the default for Linux/Ubuntu
> > systems?
>
>  I'm willing to make this change if some Linux users can a) confirm
>  that this makes indeed a difference on their system and b) nobody
>  reports a problem on their Linux system. I will *not* touch it
>  without feedback though, so Linux users please test the preference
>  and report back.
>
>  Cheers, - Andreas

I have no personal preference but to flesh out the issue/s:

Power usage: enabling pref "soundStopWhenDone" has the advantage of
reducing power usage which alone might be enough justification for being
enabled as default, particularly for battery powered machines (eg, XO,
tablets, phones).

Delays: to some people there may be a noticeable and unacceptable delay
when re-starting the player process, although I think latency in the
other parts of the sound system outside of Squeak are/could be more
significant.

Code: the player process could be a little smarter. The
"soundStopWhenDone" pref is checked before entering the loop. On
reasonably modern hw moving it into the loop would have little/no
impact. This would allow the user to set the pref thereby stopping the
process without explicitly calling "SoundPlayer StopPlayerProcess".
Secondly, there could be another another pref to add a delay between
seeing an empty queue and actually stopping the player process, which
might alleviate any problems people experience due to delays re-starting 
the process (previous point).

Education: users should be made aware of which preferences they should
tailor for their particular usage/hw. It's easy to forget or overlook
preferences even for some more experienced users (myself included). Two
future suggestions: a wizard style dialog for important prefs when a new 
image is first opened and an easily accessible "preference profile"
selector for battery/mains operation (complementing "Theme..."). I
notice there is a pref called "automaticPlatformSettings" with not much
explanation but which supposedly could be combined with system state
messages (via dbus) to do some of this. I will stop there before I get
further off-topic ;-)

Having written the above and checked both options here, my preference is 
for "soundStopWhenDone" to be enabled as default. That way there is no 
unpleasant surprises when I use my notebook on batteries or transfer an 
image to a tablet.

-D