[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@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...