ReactOS Newsletter: Newsletter 78

Author: Z98. Link to original: (English).
Tags: FOSS, GPL, Newsletter, ReactOS, windows Submitted by evilslon 22.11.2010. Public material.
ReactOS Newsletter 78 by Z98 on 2010-11-22 - Sound Stack - Mouse Messages

Translations of this material:

into Russian: Выпуск новостей ReactOS № 78. Translation complete.
Submitted for translation by evilslon 22.11.2010 Published 7 years, 11 months ago.


Sound Stack

The sound stack on Windows has a fairly clearcut layout, but the explanation provided in issue 65 of the newsletter was very brief and likely confusing so a more complete explanation follows. The sound card on a computer deals with two types of lines, source and destination. Source lines are effectively inputs from various things like the CD-ROM, microphone, or the like. Destination lines are ouputs from the card to speakers, headphones, and such. These can be tied together into a single mixer "line" from source to destination, though there can be only a single path from any one source to any particular destination.

The lines themselves are represented by a topology, which includes the source and destination and the components that link the two together. The endpoints of the topology are called pins in the kernel streaming module, with input (sink) pins becoming source line endpoints and output (source) pins becoming destination line endpoints. In addition to the pins, there are components called topology nodes. Whereas the pins represent the source or destination of a particular mixer line, the nodes represent the actual mixers that form a line. These are the components that control things like volume, bass, and even muting. There are also placeholder nodes that represent terminations of a chain of nodes and technically a mixer line does not need to have any mixer nodes at all. This is in many ways akin to the earlier stages of sound development in ReactOS where the volume could not be controlled.

The mixer lines that are composed of the pins and node chains must be correctly set up and kept track of, lest the lines get mixed together and cause weird side effects. Johannes Anderwald's recent effort has dealt with correctly discovering what components a line is supposed to have and partitioning the nodes to their respective lines. Checks for circuits, where nodes are for some reason connected to each other, also have been added. Together, these should allow more media applications to be used and reduce the instances of weird noises when playing sound, or even no sound at all.

Mouse Messages

The code in ReactOS that handles processing of mouse input, interpreting what the driver says has happened and passing it onto processes in the form of Windows messages, is very old. For that matter, it appears to be from the CVS era of ReactOS' history and has not been touched since. Its design was also incorrect and in many ways was the exact opposite of what the architecture on Windows is. In Windows, there exists a thread called the Raw Input Thread (RIT) that receives both keyboard and mouse inputs. When it receives this input, the RIT will walk the list of top level Windows to determine which application is supposed to receive the input. It will then translate the input into the appropriate Windows message and add it to the application's internal queue of messages. Applications then can use the PeekMessage function to read the message, with one of the arguments to the function indicating whether the message should be removed from the queue.

ReactOS on the other hand has two threads, one for keyboard and one for mouse. The mouse thread also does not post messages to application specific queues, but instead adds them to a system wide queue. Thus a call to PeekMessage by an application will result in examining the system wide queue instead of an application specific one. This can result in some rather unpredictable behavior as applications might see Windows messages not intended for them if the timing is just right.

The PeekMessage function also does some additional work to deal with various types of mouse messages. Depending on the type of message in its queue, it may need to do additional checks to determine if something was a double click or the like. In these situations it may even generate additional messages if the receiving Window needs to be activated and brought forward.

Giannis Adamopoulos has been working on fixing the issues mentioned above, with the first step being getting the mouse input thread to post messages to application queues instead of a system wide queue. This also required fixing PeekMessage to use the application specific queue and Giannis imported some code from Wine's implementation for some of the extra message translation functionality. A few other issues cropped up like a broken implementation of the WindowFromPoint function, which provides a handle to the Window that a particular position belongs to, which has also been rewritten. The end game would be to merge the two threads to have a single thread for keyboard and mouse input handling, but that will have to wait until the new mouse thread code sees more testing.

© ReactOS Team.