[Vm-dev] patch: fix build problems on Solaris [resend]
ag at computer.org
Sat Oct 13 19:22:06 UTC 2007
[Note: I'm resending this message because it seems the server
filtered it. My apologies if you have already seen it.]
On 9/27/07, Andrew Gaylard <ag at computer.org> wrote:
> When I send a sound, it plays fine, but when I signal the semaphore
> that output has completed, the VM keeps writing more and more stuff to
> the sound device. I assume that it's writing "silence", since I hear
> nothing after the initial sound. But it does keep the CPU quite busy
> as you might imagine.
> I have instrumented the C code where the VM checks for I/O (aioPoll),
> and under ordinary usage (keyboard, mouse, etc.) I get under 20
> polls/second. As soon as a sound has started playing, this jumps
> to 2300+ polls/second, and stays there, even when the sound is
> played and silence reigns.
> I can't figure out why it would do this.
> Clearly, since the buffer is large enough to contain only a fraction
> of a second of audio data, the semaphore is needed to tell the VM
> to send some more data. And clearly the select() call in aioPoll will
> notice the file-descriptor for /dev/audio is writable as soon as the
> first sample is played, and continuously thereafter, so I can
> understand that during playback the poll-rate should be high. This
> problem should be fix-able by using the STREAMS SIGPOLL to
> trigger the auHandle() function, rather than using select().
> However, once the whole sound is played, why would the VM
> continue playing nothing at full speed? Even with the SIGPOLL
> handler in place -- I'm about to try it now -- the VM is still issuing
> write() calls to /dev/audio several time per second, indefinitely.
> I'm sure I'm missing something here...
OK, I've done some more digging into this problem, and have
implemented the SIGPOLL-based scheme. This works as well
as the select()-based scheme of Wolfgang Helbig; i.e. there's no
discernible difference in the sound quality.
The problem with the VM playing silence at full speed once the
first sound has played, remains. I'm not sure what to do about
this, as I am fairly sure it is not a driver issue.
Here are some figures showing the performance:
(a) Newly-started VM, idle for 60s
1-minute load-average: 0.22
'23633677 bytecodes/sec; 990806 sends/sec'
(b) select driver, 60s after playing a 1-second-long sound
1-minute load-average: 1.14
'21932830 bytecodes/sec; 899000 sends/sec'
(c) sigpoll driver, 60s after playing a 1-second-long sound
1-minute load-average: 0.62
'21592442 bytecodes/sec; 911752 sends/sec'
Clearly, the writes to /dev/audio keep the squeak
process busy in both cases (b) and (c). Case (b)
has the added disadvantage of spending a great
deal of time in select calls.
For reference, my system details are:
- Sun SPARC Ultra-60, 2x400MHz CPUs
- Squeak SVN tree r1749
- unchanged etoys image, files dated September 7, 2005
The new driver files are not attached. Since the changes are
widespread, I have not made patches (but will on request).
The file can be found in the mailing list archives from the
first time I tried to send this message, at
Can someone please check the sqUnixSoundSun.c file
into SVN (assuming it's OK)? I have included the other file,
sqUnixSoundSun-select.c, for comparison only.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev