Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Advice on writing a virtual sound device driver

wc2023wc2023 Member Posts: 39

Hi everyone:

I'm somewhat new to Windows device drivers. I've written a handful of software-only kernel drivers. Mostly just as a test. I've never written any hardware (sound) drivers though.

So now I need to see if I can write a software-only driver that can act as a virtual (U S B.) sound input. It should accept sound data via network and present it in the system as a virtual sound device (say, a microphone, or a sound input device) to let other running software (in user land) to use it as if it was a physical microphone.

So I have a couple of questions, if you don't mind:

  1. Is it worth attempting to write this in the kernel? I'd rather do it in user-land, if possible.
  2. If the only way to do this is in the kernel, can someone guide me where shall I start next?

It would really help if there was a code sample that I can review that does a similar thing.

I understand that there are technically two questions in one here: how to receive data via a network (from the kernel) and how to create a virtual sound device.

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,757

    There are plenty of discussions here on virtual audio drivers. Search them out.

    The real time constraints are always going to be an issue. Also it will be difficult to implement the network part in kernel mode as part of the audio driver. I'd suggest doing that part in user mode and providing the data to your audio driver to present to the audio stack. The samples here are a good place to start: https://github.com/microsoft/Windows-driver-samples/tree/main/audio

    Also I don't know why you want to emulate a USB audio device, that is likely to result in other complications that are entirely outside of the objective.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,837

    So now I need to see if I can write a software-only driver that can act as a virtual (U S B.) sound input.

    No, you want a driver that acts as virtual sound input Forget about USB -- that's entirely irrelevant to your task.

    There are commercial products that can do this today. Virtual Audio Cable is one of them.

    Have you even looked at the Microsoft samples? There is a "Simple Audio Sample Device Driver" that does 90% of the work for a virtual audio device. All you have to do is add a back-door ioctl to feed the audio in. Well, it's still a fair amount of work, but the structure is there.

    https://learn.microsoft.com/en-us/samples/microsoft/windows-driver-samples/simple-audio-sample-device-driver/

    Tim Roberts, [email protected]
    Software Wizard Emeritus

  • wc2023wc2023 Member Posts: 39

    I really appreciate your input guys! I'll look at those samples that you linked to.

    Yes, I agree. I don't know why I said USB. Probably just thinking of a hardware device. But if it's virtual, it doesn't matter, right.

    @Tim_Roberts that's a great idea, I didn't think about implementing the networking part in the user land and piping the data into the sound driver through IOCTL. It will need some buffer too keep the incoming data, so user mode service would probably be the best way to go.

    Thanks again!

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online