Replace the class-based snooze alarm mechanism with a per-thread callback.
This makes it easy to block the current thread on an arbitrary condition:
void SomeDevice::wait_for_irq() {
m_interrupted = false;
current->block_until([this] { return m_interrupted; });
}
void SomeDevice::handle_irq() {
m_interrupted = true;
}
Use this in the SB16 driver, and in NetworkTask :^)
This makes waitpid() return when a child process is stopped via a signal.
Use this in Shell to catch stopped children and return control to the
command line. :^)
Fixes#298.
In order to repaint the GUI after the sound thread has produced some sweet
new waves, we post a CCustomEvent to the main thread's event loop and then
wake up that event loop via CEventLoop::wake().
This patch generalizes the concept used in Piano to wake up the event loop
so it can react to something happening on a secondary thread.
Basically, there's a pipe who is always part of the file descriptor set we
pass to select(), and calling wake() simply writes a little to that pipe.
* Add a LibAudio, and move WAV file parsing there (via AWavFile and AWavLoader)
* Add CLocalSocket, and CSocket::connect() variant for local address types.
We make some small use of this in WindowServer (as that's where we
modelled it from), but don't get too invasive as this PR is already
quite large, and the WS I/O is a bit carefully done
* Add an AClientConnection which will eventually be used to talk to
AudioServer (and make use of it in Piano, though right now it really
doesn't do anything except connect, using our new CLocalSocket...)
We were sending 0xd0 to pause 8-bit playback. Not sure if this actually
makes any difference but it seems like the correct thing to do.
Also update 'm_interrupted' *after* handling things.
This frees up the main thread to draw the GUI. The secondary thread uses
a pipe to trick the main thread's event loop to break out of select() and
update() the PianoWidget. :^)
Don't process any more events. We already prepend the remaining events in
this loop to the outer loop if needed.
If there were any more events queued after the exit request, the iteration
code would make an invalid access into 'queued_events'.
Fixes#300.
We should switch to Stereo but I'm having some trouble with that locally..
Since we intend to mix everything through SoundServer, let's just put the
card into 16-bit mode right away.
The idea here is to implement a simple synhesizer that allows you to play
music with your keyboard. :^)
It's a huge hack currently but we can improve upon this.
We were sometimes delivering the same mouse event twice to the active input
window. This happened because we had already delivered it via the automatic
cursor tracking mechanism.
Also add an AudioServer that (right now) doesn't do much.
It tries to open, parse, and play a wav file. In the future, it can do more.
My general thinking here here is that /dev/audio will be "owned" by AudioServer,
and we'll do mixing in software before passing buffers off to the kernel
to play, but we have to start somewhere.
