Hi VM people,<br><br>I apologise in advance for the length of this post.<br><br><div><span class="gmail_quote">On 9/27/07, <b class="gmail_sendername">Andreas Wacknitz</b> <<a href="mailto:A.Wacknitz@gmx.de">A.Wacknitz@gmx.de
</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><blockquote type="cite">This patch fixes 4 problems which prevented the VM from building
<br>
on Solaris/SPARC. They shouldn't cause problems for other<br>
</blockquote>
Interesting that there is another guy running Squeak under Solaris.</div></blockquote><div><br>Yeah. I have an Intel Linux PC at work and a Sun SPARC at home.<br>How times have changed!<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Which version of the VM sources you are talking about?<br>
I have 3.9-8 running for quite some time on my Blade 2000.<br>
Although I haven't used sound yet.</div></blockquote><div><br>This is the Subversion sources that I'm building, rev 1762. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
I have good experiences with Sun's CoolTools gcc for SPARC systems.<br>
This is a gcc-4.0.4 frontend with a SunStudio 12 code generator.<br>
The code runs at least twice as fast as with a plain gcc-3.4.3.</div></blockquote><div><br>Cool. That's good to know.<br> </div>With this patch, the VM builds and runs fine if built with gcc-3.4.3.<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><blockquote type="cite">
I've checked both the stock 3.9a-7024 image as well as the <br>
etoys image. (My motivation for this whole exercise is to fix the<br>
problems with audio under Solaris for my young daughter to use
<br>
etoys: the first sound plays, but after that, no sounds ever play.)<br>
<br>
With gcc-4.2.1 and -O2, the VM won't even start up (complains<br>
about a missing vm-display-X11, even though it's there). With<br>
gcc-4.2.1 and no -O2, the VM starts, runs for a short while, and<br>
then cores with a bus error. gdb shows a corrupt stack. I'm<br>
about to build gcc-4.1.2 and give it a spin building the VM to<br>
try to track this down. But I do suspect bad code generation
<br>
with gcc-4.2.1.</blockquote></div></blockquote><div><br>I take back what I said about gcc-4.2.1. I'm pretty sure that this was<br>due to user-stupidity (mine).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Did you manage to build libffi-2.0? This library is part of gcc-4.2.1.</div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000">
AFAIK it is necessary for Squeak's FFI. I have only an old libffi-1.2.0
that<br>
has some Solaris bugs. So I don't have FFI which is needed for some
interesting<br>
packages (e.g. ODBC).</div></blockquote><div><br>Hmm. I haven't tried building libffi. That might be my next project,<br>once this is sorted out. Anyway, on to the sound problems.<br><br>1/<br>Thanks to the patch by
<b>Wolfgang Helbig</b> at<br><a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2006-January/000450.html">http://lists.squeakfoundation.org/pipermail/vm-dev/2006-January/000450.html</a><br>the problem was quite simple to fix. I made a few small changes,
<br>and sound is working on Solaris/SPARC hardware natively (no NAS<br>needed). Note that it looks like vm-sound-sun never implemented<br>recording; this is playback only (which is fine for my purposes).<br><br>2/<br>According to the squeak porting guide, to make sounds, the snd_Start
<br>C function is called. This is passed a (Squeak/smalltalk) semaphore<br>"that should be signalled when input/output completes". I take it this
<br>means that the sound driver should signal the semaphore when the<br>sound device has space for writing.<br><br>(An old copy of the Squeak porting guide is here:<br><a href="http://coweb.cc.gatech.edu/squeakbook/uploads/porting.1.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://coweb.cc.gatech.edu/squeakbook/uploads/porting.1.pdf</a><br>I have a much newer version on paper, but I can't remember where<br>I got it.)<br><br>When I send a sound, it plays fine, but when I signal the semaphore
<br>that output has completed, the VM keeps writing more and more stuff to
<br>the sound device. I assume that it's writing "silence", since I hear<br>nothing after the initial sound. But it does keep the CPU quite busy<br>as you might imagine.<br><br>3/<br>I have instrumented the C code where the VM checks for I/O (aioPoll),
<br>and under ordinary usage (keyboard, mouse, etc.) I get under 20<br>polls/second. As soon as a sound has started playing, this jumps<br>to 2300+ polls/second, and stays there, even when the sound is<br>played and silence reigns.
<br><br>I can't figure out why it would do this.
<br><br>Clearly, since the buffer is large enough to contain only a fraction<br>of a second of audio data, the semaphore is needed to tell the VM<br>to send some more data. And clearly the select() call in aioPoll will<br>
notice the file-descriptor for /dev/audio is writable as soon as the<br>first sample is played, and continuously thereafter, so I can<br>understand that during playback the poll-rate <span style="font-weight: bold;">should
</span> be high. This<br>problem should be fix-able by using the STREAMS SIGPOLL to<br>trigger the auHandle() function, rather than using select().<br><br>However, once the whole sound is played, why would the VM<br>continue playing nothing at full speed?
Even with the SIGPOLL<br>handler in place -- I'm about to try it now -- the VM is still issuing<br>write() calls to /dev/audio several time per second, indefinitely.<br><br>I'm sure I'm missing something here...
<br><br>Andrew<br></div></div>