Show some information about the file we're playing, and display how many
samples we've played out of how many total.
This might be a bit buggy as I haven't tested it with many different files,
but it's a start. :^)
This is a total hack, because I haven't really looked into why these are
happening. Somehow we're producing one extra sample and it's glitching
up the sound stream ever so slightly.
Each client connection now sets up an ASBufferQueue, which is basically a
queue of ABuffers. This allows us to immediately start streaming the next
pending buffer whenever our current buffer runs out of samples.
This makes the majority of the skippiness go away for me. :^)
Also get rid of the old PlayBuffer API, since we don't need it anymore.
This adds a bounds check to the loop that writes to the buffer
'recognized_symbols'. This prevents buffer overflows in the
case when a programs backtrace is particularly large.
Fixes#371.
The previous implementation of the PIIX3/4 PATA/IDE channel driver only
supported a single drive, as the object model was wrong (the channel
inherits the IRQ, not the disk drive itself). This fixes it by 'attaching'
two `PATADiskDevices` to a `PATAChannel`, which makes more sense.
The reading/writing code is presented as is, which violates the spec
outlined by Seagate in the linked datasheet. That spec is rather old,
so it might not be 100% up to date, though may cause issues on real
hardware, so until we can actually test it, this will suffice.
Now that we can set icons directly "by bitmap", there's no need for passing
around the icon paths anymore, so get rid of all the IPC and API related
to that. :^)
Now that we support more than 2 clients per shared buffer, we can use them
for window icons. I didn't do that previously since it would have made the
Taskbar process unable to access the icons.
This opens up some nice possibilities for programmatically generated icons.
Thanks to Dan for pointing this out on IRC:
<danboid> I see TextEditor still numbers its lines from 0. You're too much of a programmer sometimes kling! :)
< kling> that might be the most extreme form of "programmer design" I've seen in serenity
We were limiting ourselves to only play WAV files smaller than 42 MB
for no particular reason. This patch increases the limit to 1 GB.
Perhaps there should not be any limit at all, but 1GB seems like a
reasonable sanity check at the moment. :^)
This allows us to carry the same buffer all the way from the WAV loader
to the AudioServer mixer.
This alleviates some of the stutter, but there's still a noticeable
skip when switching buffers. We're gonna need to do better. :^)
I had to solve a bunch of things simultaneously to make this work.
Refactor AWavLoader to be a streaming loader rather than a one-shot one.
The constructor parses the header, and if everything looks good, you can
repeatedly ask the AWavLoader for sample buffers until it runs out.
Also send a message from AudioServer when a buffer has finished playing.
That allows us to implement a blocking variant of play().
Use all of this in aplay to play WAV files chunk-at-a-time.
This is definitely not perfect and it's a little glitchy and skippy,
but I think it's a step in the right direction.
So we already have ByteBuffer::wrap() which is like a StringView for random
data. This might not be the best abstraction actually, but this will be
immediately useful so let's add it.
This is expensive because we have to page in the entire executable for every
process up front for this to work. This is due to the page fault code not
being strong enough to run while another process is active.
Note that we already had userspace symbols in *crash* stacks. This patch
adds them generally, so they show up in /proc, Process Manager, etc.
There's room for improvement here, but the debugging benefits way overshadow
the performance penalty right now. :^)
It was a tad too bright. Also make sure we're using the same color in
all the different places. At some point it would be nice to improve global
color settings, etc.
We're going to be using dedicated server socket classes instead.
This was only implemented for CLocalSocket, and clients have been switched
over to using CLocalServer.
Use CLocalServer to listen for connections in WindowServer and AudioServer.
This allows us to accept incoming CLocalSocket objects from the CLocalServer
and construct client connections based on those.
Removed COpenedSocket since it's replaced by CLocalSocket.
Instead of trying to support both client and server in CLocalSocket, let's
have a specialized server class.
The basic usage is:
CLocalServer server;
server.listen("/tmp/name-of-portal");
server.on_ready_to_accept = [&] {
CLocalSocket* client = server.accept();
...
};
This will make things a lot simpler, since an accepting socket doesn't need
half of the stuff that a regular CIODevice provides. :^)
Since ChildAdded events originate from the CObject constructor, they are not
fully constructed when their parent learns that they were added.
Added a little comment about this to the child_event() declaration.
