Sound latchup problem is back with Squeak-4.0.3.2202-linux_i386.tar.gz (Ubuntu/Linux)

Hi Ian, Hi Derek,

Ian>: Actually I suspect it was never solved.  The vm-sound-pulse driver was  
missing in 2196.


A missing problem is a solved problem. Which module is responsible? Maybe removing it is the thing to do?
I was still getting sound in 2196.

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?

Guys, my role here is just to be the complainer. I will not know the solution until you tell me.

Plus, after telling me can you take responsibility to see that the problem is solved?

Yours in curiosity and service, --Jerome Peace


     

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

On 14/04/10 09:26, Andreas Raab wrote:
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

Sorry for the late reply; but I have been fighting the same issue as
Jerome; it's a pretty bad one.  My code hit a Beep, something that
should have taken one minute was still running after an hour (I
suppose because the CPU was consumed but I didn't know that then).
Attempting to profile ended up in a locked image (couldn't interrupt
it with Alt+.).

Toggling soundStopWhenDone seemed to fix the problem.
...
Wow, I just was browsing senders of this method and noticed..  have a
look at SmalltalkImage>>#snapshot:andQuit:embedded:.  It calls
#setPlatformPreferences which takes the trouble to force it true if
booting into a Win32 environment, but false otherwise.  Someone knows
something about this..

On Wed, Apr 14, 2010 at 3:26 AM, Andreas Raab <[hidden email]> wrote:

On 4/15/2010 6:30 PM, Chris Muller wrote:
> Sorry for the late reply; but I have been fighting the same issue as
> Jerome; it's a pretty bad one.  My code hit a Beep, something that
> should have taken one minute was still running after an hour (I
> suppose because the CPU was consumed but I didn't know that then).
> Attempting to profile ended up in a locked image (couldn't interrupt
> it with Alt+.).
>
> Toggling soundStopWhenDone seemed to fix the problem.

Did you try rc5? It has soundStopWhenDone set to true by default on Unix.

> Wow, I just was browsing senders of this method and noticed..  have a
> look at SmalltalkImage>>#snapshot:andQuit:embedded:.  It calls
> #setPlatformPreferences which takes the trouble to force it true if
> booting into a Win32 environment, but false otherwise.  Someone knows
> something about this..

Yeah, but for other reasons. In the old days, the sound device was an
exclusive resource and leaving open would prevent any other apps from
playing any sounds. CPU usage had little to do with it.

Cheers,
   - Andreas