ReactOS Audio Service

[silverblade]

I've started work on the ReactOS Audio Service
(can be found in base\services\audiosrv in the source tree)

I've figured out how WinMM becomes aware of plug and play devices on XP. My implementation follows how Windows appears to do things, and works like so:

AudioSrv creates a device list in shared memory, and a mutex to protect this list from modification whilst being read (I don't think Windows does this but I do as a safeguard.)

AudioSrv then registers for audio device notifications via RegisterDeviceNotification, and uses the Setup API to find existing audio devices on the system. These are registered under the KSCATEGORY_AUDIO interface.

WinMM obtains access to the shared memory created by AudioSrv. If it can't find it (it's a named file mapping with a named mutex) then the service has either failed or is stopped. So no devices are available.

WinMM can then enumerate the device list, and pass the devices to the relevant user-installable driver (usually WDMAud.drv) to be dealt with. This is done via DRVM_INIT (WODM_INIT ?) And WODM_EXIT messages being sent to wodMessage (for Wave Out devices, anyway.)

Each entry is actually a device path - WDMAud opens the devices and sends KS messages to identify it by name etc. and then maintains the number of devices present and the information about each device.

Applications using WinMM will then see this information in their calls to waveOutGetNumDevs and waveOutGetDevCaps and so on.


Compatibility

The service only does anything on Windows XP at present. It's not been tested with Vista but *should* work.

It can quite happily sit next to the "official" Audio Service and will not interfere with Windows' own WinMM.

To install as a service, and start it:

Code: Select all

sc create RosAudioSrv binpath= audiosrv.exe
sc start RosAudioSrv

(Beware! There is a space between binpath= and audiosrv.exe)

To stop the service and delete it:

Code: Select all

sc stop RosAudioSrv
sc delete RosAudioSrv

Currently the only way to obtain its output once the service is started, is to run my test application called READER.EXE which you can download from my website (note: this is a tar.gz file.) This is actually the test code for the audio device list so it shares some code with audiosrv from the ReactOS tree.


More work to be done

"Why doesn't this work on ReactOS?" I hear you ask.

In Windows there are 3 additional components:
KS.SYS - Kernel Streaming API
PORTCLS.SYS - Port Class (driver utility library)
SYSAUDIO.SYS - System Audio graph builder

One of these (either SysAudio or KS) register devices in the KSCATEGORY_AUDIO interface class.

Without these components, the ReactOS Audio Service will receive no notifications of new audio devices, and won't find any existing devices. Hence, it will sit there and do nothing.

So there's not much to look at (or hear!) yet, but I'm getting there slowly!

[Angelus]

WOW!

Thanks a lot for share your progress.
I'm sure that you will get there.

[Radhad]

Nice I hope other developers will publish their work in a similar way, so more people get to know what happens within ReactOS (or Windows)

[Phalanx]

Now that is some great work there! This is why ReactOS devs are so good ath what they do!

[Mrkaras]

thats realy good to hear. those other three things sound fairly involved but I'm sure you'll get there, good work.

[Nmn]

Excellent progress. Instead of instant gratification, code that will be better in the long run is always better. I'm not one who is good at programming, but i try hard, and still don't get too much success, so i have to respect how well you've already handled this.

[forart]

Seems that the NASPRO project is evolving faster than forecasts:

I've completed the message reporting subsystem, which was the last "basic" component to complete the low level "programming environment" for NASPRO, and now I am putting together all of the pieces in order to have a clear, well-behaving and integrated API.

So I will commit the last changes when this work is completed and later update the design papers, since there are a lot of changes. I guess it will take a week or two and, when it's done, the NASPRO core library will be more or less 80% completed (the missing parts for the first release are dynamic linking and filesystem inteaction, which are higher level and probably easier to handle).

Though this kind of work is heavy (for the brain), frustrating and is probably not interesting at all to end users (nothing that can be actually "seen"), I'm quite excited an happy about it the same. That's because I'm finally testing such building blocks against each other and in external tests, and I have to say that the resulting environment, though not complete nor optimized, is already extremely sane, easy (once understood), sensitive, not resource hungry and quite fast as well. I would say that in some aspects it is already better than most similar tools around (otherwise I wouldn't have developed it .

Comments (on NASPRO website, of course) apreciated.

I posted this 'cause it maybe an interesting project to collaborate with (expecially for audio developers).

[silverblade]

It seems a tad off-topic for what I'm doing here, however I'm curious as to what exactly its purpose is?

EDIT: (I keep seeing things like this all over the place...)

[Z98]

That's a very good question.........

[forart]

Sorry, i think i already talked about it.

Its main aim is to give audio application developers a full-featured, yet scalable, high-performance and integrated tool to make use of virtually any external sound processing component (including, but not limited to, LADSPA/DSSI, LV2, VST, AudioUnits and DirectX plugins) via a single, semi-transparent and platform-independent API.

[etko]

May I ask what's currents status of those components in ReactOS?

I mean :

KS.SYS - Kernel Streaming API
PORTCLS.SYS - Port Class (driver utility library)
SYSAUDIO.SYS - System Audio graph builder

BTW isn't this audio service only responsible for maintaining WaveOut interface on Windows XP which is regarded deprecated/buggy by MS folks?

[silverblade]

KS.SYS, PORTCLS.SYS are stubbed, mostly.
SYSAUDIO.SYS doesn't exist (or if it does, it doesn't do anything.)

The audio service is responsible for providing a list of audio devices to the MME API component, of which WaveOut is a part of, yes.

I don't recall anyone commenting that it is deprecated. It's old, but it's useful for simple audio applications and old applications depend on it (in fact, again for simple audio applications, many modern apps use it!)

Even pro audio music applications make use of it for its MIDI capabilities.

I don't recall it being buggy, however.

[etko]

Never mind I was just reading somewhere that on XP and above DirectSound should be used for more serious sound processing and is more "correct". However take this as unverified claim, as long as I can not find that article.

[boomerific]

Can the audio service be designed to be an audio server such as http://pulseaudio.org/ which is new to Linux distributions? The ability to redirect audio, change formats and re-sample would be very nice for me, maybe not so much if one is trying to support DRM technologies.

[bscwireless]

silverblade, Any update's on ros audio ?