I would like to experiment with real time audio and was wondering what options are there for accessing audio via a usb port?
I would like to get data from this hardware in an audio stream.
Is this sort of thing best handled by audio frameworks or should the data be fetched using IOKit and passed to e.g. an audio component using a framework?
Also, how is this access effected if e.g. A DAW is accessing the audio from the port? Is dual access handled by the OS?
The specs page for that hardware (Moog Minitaur) doesn't claim that it can transmit audio over USB, only that it has USB MIDI- essentially it has a built in MIDI interface.
If you wanted to get audio from it into your computer you would have to connect it to your computer's line or mic input, or an external soundcard - which may itself connect via USB. One way to handle audio in OSX would be Core Audio. You shouldn't need to write any drivers or anything to deal with the low-level I/O with the soundcard, as the soundcard should come with a driver if there isn't one already in the OS.
Related
I would like to ask for guidance on how to ideally communicate with a custom USB HID device on MacOS.
Use case
Modify a microphone volume via an external USB HID device.
Question
Can I use DriverKit (HIDDriverKit) for that or I need to use IOKit? I have read something here about audio limitation, but not sure what exactly is not supported.
DriverKit doesn’t support USB devices that manipulate audio or that
communicate wirelessly over Bluetooth or Wi-Fi. For those types of
devices, create a kernel extension using IOKit.
— Source
Would DriverKit still work in my case as I am not sending audio streams but controlling volume only?
Many thanks!
Cheers,
Tom
If I understand you correctly, you wouldn't even need to use DriverKit. (from experience: avoid it if you can!)
You can communicate with HID-compliant devices directly from user space processes. User space processes can generally also control the volume on audio devices.
So by far the easiest option would be to have a launch agent which uses IOKit matching as its launch condition so it starts up when your device is connected. Your agent can communicate with the device using the IOHIDManager API to receive events when your buttons are pressed, and then use the regular Core Audio APIs to control volume.
It doesn't have to be a launch agent, incidentally: a regular Cocoa app with a UI can do all of this as well. (And indeed, you may want to show some form of UI as feedback to the user pressing the buttons.)
When I connect several USB audio devices using the default drivers I usually end up with some kind of friendly device description like "nn- USB Audio codec" or something else, so I have currently no unique property which refers to a specific hardware the e.g. manufacturer ID. I would like to ensure that in case of re-enumerating or replugging the hardware to a different port that my software will automatically identify the changed windows audio device which maps to this hardware. I there a possibility to gather further windows audio device information which can be used to determine the physical hardware ?
Maybe a little clarification is needed:
I have two or more USB audio devices, not necessarily same product or manufacturer. The audio connections have different purposes, so I want to ensure that I my software uses constantly the same physical audio devices for different tasks. This sometimes fails when a re-enumeration occurs ( sometimes without changing the physical USB port connections, it's a windows thing...)
Ideally I would distinguish them by an individual serial number, which usually is only available with storage devices. But what I can retrieve is the "physical" USB topology when I'm looking at the device with a tool such as USBDeview from Nir Sofer. There I have a property like "Hub 3, Port1". If I could map this to a sound device I get from audio audio api like "nn- USB Audio codec" as seen in the sound control panel I would be perfectly happy.
Edit2:
May be this[1] post helps here, but I still have to figure out how to get a USB Port <-> Windwos Sounddevice mapping.
[1]: Can the physical USB port be identified programatically for a device in Windows? "
I want to create a virtual audio device that gets audio data from the default output (which is an output IOAudioStream) and converts it to an input IOAudioStream.
I went through most of the examples I could find, however they only implement a feature to copy the output IOAudioStream to the input one at most. That means it only converts the audio to an input stream if the audio device is selected as output.
This should be possible, since ScreenFlow allows recording of computer audio by installing a kext that creates a virtual driver.
How can I access the audio data from the default output and send it to my virtual driver?
Take a look at the open-source WavTap, which is a simplified fork of the open-source SoundFlower virtual sound card driver. It is a .kext that I believe does substantially what you want.
For reference, here is how some popular commercial closed-source options work:
Rogue Amoeba's Audio Hijack Pro
-Captures system audio via code based off of the open-source SoundFlower .kext
-Captures an application's audio by substituting a "patch" framework for the normal CoreAudio.framework when launching the application
-Captures an already-running application's audio with the help of the haxie "Application Enhancer" (APE) from Unsanity
These features are branded as their "Instant On" feature (InstantOn.kext).
Ambrosia Software's WireTap Studio
-Captures system audio and application audio via an in-house developed .kext
Telestream's ScreenFlow
-Captures system audio via an in-house developed .kext. (Version 2.x uses varaudio.kext; Version 3.x uses TelestreamAudio.kext)
Macsome's Audio Recorder
-Unknown method
Araelium Group's Screenflick
-Captures system audio using the SoundFlower .kext
UPDATE #1
After reading the author's comments, it appears the underlying goal is to be able to capture the system sound without publishing the virtual audio driver as a device (that would appear in the System Preference's list) and without changing the current default output device (or at least the appearance that the device has changed).
SoundFlower: Adds a sound device to the list upon installation
WavTap: Adds a sound device to the list upon installation; auto-selects the device when the WavTap application is started; auto-deselects the device when the application is shutdown and reselects the previous device
Audio Hijack Pro: Adds a sound device only when audio capture of the default system sound is selected; removes the sound device when audio capture is no longer selected and reselects the previous device
WireTap Studio: Unknown
ScreenFlow: Captures the system sound without changing the current default output device and without publishing the virtual audio driver as a device
UPDATE #2
A quote from Jeff Moore, a CoreAudio Apple engineer, in reference to applications such as WireTap and Audio Hijack Pro:
"There are no APIs on the system that will give you the output of any specific app or the whole mix going to the hardware...[Capturing System Sound] isn't supported by the System and those folks had to be clever. There's nothing stopping you from doing the same thing except how willing you are to get your hands dirty.
The fact is, Mac OS X's audio system was designed first and foremost for performance. This lead us to a design where it is not easy to support the functionality you want without imposing performance penalties. So, we have opted for better performance at the cost of not being able to provide this feature."
If you want to read more on the subject, check out these threads on the CoreAudio API mailing list:
"WireTap, CoreAudio's API, and system capture, and kexts..."
"Another question on capturing audio played back by a software"
"Capturing currently played audio using CoreAudio on Mac"
"'audio hijack'"
"monitoring system audio output like wire tap"
"Capturing audio output to a file"
"Mirroring Audio Output"
"Recording system audio"
Relevant SO Questions:
Hide Audio device using codeless kext
So long story short, you're not likely to find examples from Apple that accomplish this, and you're not likely to find open source code that accomplishes this either, unless someone is feeling very generous. It appears to be too valuable of information.
After additional research, here are some theoretical techniques I came up with that might allow you to accomplish your goal:
Similar to Prosoft Engineering's Hear product, you could create a HAL plugin (user-mode virtual driver) rather than a .kext (kernel-mode virtual driver). Apple has a sample HAL plugin called "SampleHardwarePlugIn" and PulseAudio has one as well. However, with his method I don't think you get access to a pre-mixed system sound stream. You would have to gather up all streams from the various applications (which must use CoreAudio to play sound) and mix them together for pseudo system sound capture.
Create a virtual audio device that is hidden [1][2] from user interaction. When the user wishes to capture the default sound, programmatically create an aggregate device that includes your hidden virtual device and the current default sound device. Temporarily set this aggregate device as the default output. In this manner, you are able to both capture the default sound and hear it.
Side Note: If Mac OS X allows for a hidden device to also be set as the default output device, what would System Preferences show as the selected device? If it instead shows the secondary output device as selected, then you have the added allusion that nothing has changed.
A newer open-source virtual audio device that works with the latest versions of MacOS is BlackHole - it supports multiple audio channels and sampling rates.
It can be used as an audio sink and/or source. It's also handy as part of an aggregate audio device so audio can be heard and re-routed - e.g. using the MacOS Audio MIDI Setup app
I am trying to design a Windows KMDF driver for an old USB Webcam.
I think I have enough informations on the driver development / USB protocol side, but I am wondering how I should expose the webcam functionalities from the driver so that Windows program can take advantage of it.
This webcam has 3 functionalities:
a video stream,
an audio stream,
a "take picture" hardware button.
For each of those, what is the more natural way to expose it to Windows, so that my webcam can be used in relevant programs (gTalk, Skype, etc.)? Or, to revert the question: what is expected by those programs, and how do they detect webcams?
When you write a 'WebCam' driver, you should use kernel streaming as your driver model. this provides you with the correct interfaces, so that other programs can communicate with your device through DirectShow/VfW/etc. .
Currently kernel streaming is implemented in the AVStream mini driver base. The WDK contains a AVStream mini driver sample to base your own driver on. The backend to the device can then be implemented using KMDF.
I am working on building a USB Video Class camera, which is supposed to work well with various flavours of Windows. The camera needs firmware upgrade support to upload new software images into it. There are two ways to do it, as far as I know.
Use DFU.
Use control endpoint of the UVC Class device to transfer bytes into the device.
To use the second option, it looks like, one needs to write a Filter Driver. Is this correct? Is there any other way to accomplish this task?
There are several ways to do what you want.
The standard UVC Class driver supports a user mode interface, from which you can send USB packets to the device. This interface is called: USB Video Class Extension Units.
Another way is to use WinUSB, where you install the WinUSB driver for your device. After that you can send USB packets through the WinUSB interface.
The most involved solution would be, to write a complete USB driver. Just see the samples in the WDK.