ReactOS Audio Service

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

silverblade
Developer
Posts: 58
Joined: Sat Dec 18, 2004 9:41 pm
Location: Newbury, UK
Contact:

ReactOS Audio Service

Post by silverblade » Wed Sep 19, 2007 4:37 pm

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!
Last edited by silverblade on Thu Sep 20, 2007 12:41 am, edited 1 time in total.
Andrew / Silver Blade

Image

Angelus
Posts: 132
Joined: Sat Sep 23, 2006 12:26 pm
Location: Spain

Post by Angelus » Wed Sep 19, 2007 5:04 pm

WOW! :shock:

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

Radhad
Posts: 605
Joined: Wed Apr 12, 2006 5:09 pm
Contact:

Post by Radhad » Wed Sep 19, 2007 6:29 pm

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
Posts: 360
Joined: Sun Dec 19, 2004 12:42 am
Location: Australia

Post by Phalanx » Thu Sep 20, 2007 1:41 am

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

Mrkaras
Posts: 379
Joined: Sat Nov 27, 2004 5:43 am
Location: Australia
Contact:

Post by Mrkaras » Thu Sep 20, 2007 2:45 pm

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

Nmn
Posts: 170
Joined: Wed Dec 07, 2005 10:20 pm
Location: In front of my pc maybe?

Post by Nmn » Fri Sep 21, 2007 2:01 am

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.
Programmers: Help us put Vista graphics drivers on Linux! The WDOL Project Homepage

forart
Posts: 1050
Joined: Mon Nov 29, 2004 1:36 pm
Location: Italy
Contact:

Post by forart » Thu Sep 27, 2007 12:00 pm

Seems that the NASPRO project is evolving faster than forecasts:
Updates on NASPRO core development wrote: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).
»Forward Agency NPO
In progress we (always) trust.

silverblade
Developer
Posts: 58
Joined: Sat Dec 18, 2004 9:41 pm
Location: Newbury, UK
Contact:

Post by silverblade » Thu Sep 27, 2007 8:40 pm

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...)
Last edited by silverblade on Thu Sep 27, 2007 9:10 pm, edited 1 time in total.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Post by Z98 » Thu Sep 27, 2007 8:46 pm

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

forart
Posts: 1050
Joined: Mon Nov 29, 2004 1:36 pm
Location: Italy
Contact:

Post by forart » Thu Sep 27, 2007 9:32 pm

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.
»Forward Agency NPO
In progress we (always) trust.

etko
Posts: 154
Joined: Thu May 26, 2005 3:43 am
Location: Slovakia
Contact:

Post by etko » Tue Oct 09, 2007 9:54 pm

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
Developer
Posts: 58
Joined: Sat Dec 18, 2004 9:41 pm
Location: Newbury, UK
Contact:

Post by silverblade » Thu Oct 11, 2007 9:17 pm

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
Posts: 154
Joined: Thu May 26, 2005 3:43 am
Location: Slovakia
Contact:

Post by etko » Mon Oct 15, 2007 6:40 pm

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
Posts: 6
Joined: Wed Oct 05, 2005 12:55 am

Post by boomerific » Sun Nov 11, 2007 6:30 am

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
Posts: 13
Joined: Sat Sep 22, 2007 11:55 am

Post by bscwireless » Tue Nov 27, 2007 5:06 am

silverblade, Any update's on ros audio ? :wink:

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests