Are there any public APIs in Mac OS X for checking the High-bandwidth Digital Content Protection (HDCP), and/or Display Port Content Protection (DPCP) compliance of connected displays, or for requiring that your application's output only be displayed on HDCP/DPCP-compliant displays?
I'd like my application to be able to refuse to play back certain content unless these kinds of protection are ensured on all relevant connected displays. I believe Apple is able to do this for iTunes store HD content, but I'm not sure if they are using a private API for this.
How can I guarantee that my application's output is HDCP- or DPCP-protected?
As far as I know (and I've done a lot of homework on it, I am lead engineer for a well known Mac/Win Media Player) Apple is being greedy and not sharing. There is plenty of evidence that newer macbook and mac pro HDMI and Display port connections support the full encryption protocol, and that iTunes is able to query and control it.
Apple appears to be purposely withholding the API, with the intention of preventing any possibility of Blu-ray support on Mac, in order to create leverage for getting the studios to allow HD content for iTunes.
Related
At 3:38-4:00 in the session video, it seems Baek San Chang says that AudioDriverKit will not be allowed to be used for virtual audio devices
Video: https://developer.apple.com/videos/play/wwdc2021/10190/
Here is what he says:
Keep in mind that the sample code presented is purely for
demonstrative purposes and creates a virtual audio driver that is not
associated with a hardware device, and so entitlements will not be
granted for that kind of use case.
For virtual audio driver, where device is all that is needed, the
audio server plugin driver model should continue to be used.
The mentioning of sample code is a little confusing; Does he mean the entitlements for hardware access won't be granted for a virtual device? That would seem obvious.
But if he means the entitlements for driver kit extensions (com.apple.developer.driverkit and com.apple.developer.driverkit.allow-any-userclient-access) won't be granted for virtual audio devices, and this is why AudioServerPlugins should still be used, then that's another story.
Are we allowed to use AudioDriverKit Extension for Virtual Devices?
The benefit of having the extension bundled with the app rather than requiring an installer is a significant reason to use an extension if allowed.
I need to create a virtual audio driver that presents a virtual microphone and a virtual speaker to the user. The user can then select these virtual endpoints in 3rd party audio communication apps like Skype, Zoom etc. The virtual audio driver implementation then routes audio between physical devices (selected by the user in the virtual driver userspace control app) and the virtual devices.
It is a requirement that the virtual audio driver and its control app can be published to the Apple app store for users to download and install on their machine without any problems.
How should I go about this?
How should I go about this?
Apply for the entitlements straight away (don't lie on your request form obviously), wait until AudioDriverKit is out of beta, then file a Developer Tech Support TSI and explain what you're trying to do and ask what the policy is. I haven't seen any written policy on this, and the information in the video may or may not be accurate.
Don't forget that you don't just need the entitlements; your virtual audio drivers will also need to pass App Store review, so I'd make sure to get something in writing before you spend all that effort implementing your driver.
One more comment: com.apple.developer.driverkit.allow-any-userclient-access is not generally needed, and whether or not you need to apply for it depends on the architecture you are planning for your driver.
I'm trying to understand if (and if so, how) it's possible to dedicate a HID (USB-card reader for NFC cards) to a specific application in macOS.
The card reader acts as a keyboard, sending the number of the card to whatever is open in macOS. I'm trying to get that USB-device locked to a specific application (e.g. firefox, chrome etc).
I really have no idea where to start looking for this. Hence I'm posting here for any help in the right direction.
Googling "Dedicate USB device to app" etc gave nothing useful.
macOS version 10.14.5 (18F132) (Mojave).
The way applications communicate to USB devices is IOKit framework. You could write it as service if you want to lock applications anywhere. And you need to know about launchd (Launch Daemon). It manages all your background service.
I would like to know whether SoX/LibSoX offers the possibility to access a sound device in exclusive/hog mode. The idea is to prevent other applications from accessing the sound card / DAC that is being used by the focal app.
My main target is OSX CoreAudio output, but I am also eager to know about Linux (OSS/Alsa).
I know this is possible in CoreAudio, because I have seen it implemented in several apps, including this open source one.
On Mac OS X at least, the answer appears to be no. In http://sourceforge.net/p/sox/code/ci/master/tree/src/coreaudio.c SoX uses the default input or output device but there is no provision for hog mode.
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
Where I work, we are building a GUI to run on iOS or Android; the GUI is intended to control an embedded board. The embedded board does not have WiFi, an Ethernet port, or a USB port, but it does have an RS-232 serial port; so we are using a product called a WiSnap.
http://serialio.com/products/mobile/wifi/WiSnapKit2.php
We have been able to connect to the WiSnap using OS X, or using iOS (an iPad 2). But none of our Android tablets recognize the device at all. The WiSnap acts as a WiFi access point, and broadcasts an SSID; the Android tablets do not list this SSID in the list of available WiFi access points. Under Linux Mint 12, my Laptop can see the WiSnap, but attempts to connect to it fail. Interestingly, my cell phone (a Droid 2) is able to see the WiSnap, but I don't have telnet on my phone so I haven't tested to see if it actually works.
Under OS X, I noticed something. In the drop-down list of WiFi access points, there are two distinct groups: the top group, which contains most of the listed WiFi access points, then a lower group, that has a sub-heading that says "Devices" and contains just the WiSnap and something called "hpsetup". (I don't know what "hpsetup" is or where it might be; there are lots of WiFi users in this neighborhood.)
The WiSnap is operating in "ad-hoc" mode with no security at all.
So, my question is: what is the significance of OS X calling the WiSnap a "device"? It is frustrating to try to search Google for "WiFi devices"; you get a giant haystack of results that are not related to this.
Also, is there anything we can do to make an Android tablet see the WiSnap and connect to it?
Can anyone recommend a good resource where I can read up on WiFi? Again Google hasn't helped much; there are so many introductions to WiFi out there, most of them at a very simple level.
Thanks for any help you can give me.
EDIT: The vendor does claim Android compatibility for some models of WiSnap, but not for others.
This lists Android as supported: http://serialio.com/products/mobile/wifi/WiSnapKit2.php
This does not: http://serialio.com/products/mobile/wifi/WiSnapAAA.php
I guess I should contact the vendor, but I do want to understand what is going on, so I was hoping to get advice from the StackOverflow community about this.
EDIT: We did contact the vendor. What we found out is that the WiSnap can be a stand-alone device only in ad-hoc mode. If you set up a WiFi router or access point, the WiSnap will join the network in infrastructure mode. But the WiSnap will not act as an infrastructure mode access point.
Android OS at the moment only supports infrastructure mode. So, if we want to use an Android tablet with a WiSnap we would have to set up some sort of WiFi router or access point. We are looking into other solutions now.
I'm relatively sure that hpsetup is the ad hoc wifi for an HP wireless printer. So perhaps the ad-hoc/peer-to-peer qualifier is what causes OS X to classify it as a device.