I'm trying to tap the currently selected output audio device on macOS, so I basically have a pass through listener that can monitor the audio stream currently being output without affecting it.
I want to copy this data to a ring buffer in real time so I can operate on it separately.
The combination of Apple docs and (outdated?) SO answers are confusing as to whether I need to write a hacky kernel extension, can utilise CoreAudio for this, or need to interface with the HAL?
I would like to work in Swift if possible.
Many thanks
(ps. I had been looking at this and this)
I don't know about kernel extensions - their use of special "call us" signing certificates or the necessity of turning off SIP discourages casual exploration.
However you can use a combination of CoreAudio and HAL AudioServer plugins to do what you want, and you don't even need to write the plugin yourself, there are several open source versions to choose from.
CoreAudio doesn't give you a way to record from (or "tap") output devices - you can only record from input devices, so the way to get around this is to create a virtual "pass through" device (AudioServerPlugin), not associated with any hardware, that copies output through to input and then set this pass through device as default output and record from its input. I've done this using open source AudioServer Plugins like BackgroundMusic and BlackHole [TODO: add more].
To tap/record from the resulting device you can simply add an AudioDeviceIOProc callback to it or set the device as the kAudioOutputUnitProperty_CurrentDevice of an kAudioUnitSubType_HALOutput AudioUnit
There are two problems with the above virtual pass through device approach:
you can't your hear output anymore, because it's being consumed by the pass through device
changing default output device will switch away from your device and the tap will fall silent.
If 1. is a problem, then a simple is to create a Multi-Output device containing the pass through device and a real output device (see screenshot) & set this as the default output device. Volume controls stop working, but you can still change the real output device's volume in Audio MIDI Setup.app.
For 2. you can add a listener to the default output device and update the multi-output device above when it changes.
You can do most of the above in swift, although for ringbuffer-stowing from the buffer delivery callbacks you'll have to use C or some other language that can respect the realtime audio rules (no locks, no memory allocation, etc). You could maybe try AVAudioEngine to do the tap, but IIRC changing input device is a vale of tears.
Related
I am trying to unmount/eject usb device programmatically on macOS.
Using IOkit I tried to register to IOServiceMatching(kIOUSBInterfaceClassName) and iterate over all devices and for each device i tried getting the BSD name and go from there:
IORegistryEntrySearchCFProperty(usbDevice,kIOServicePlane,CFSTR(kIOBSDNameKey),kCFAllocatorDefault,kIORegistryIterateRecursively);
But i found that on Intel based devices that regestry search dosnt work.
I do have Vendor id, product id etc..
So my quistion:
Is there diffrent alternative?
Is there a syscall i can use?
Maybe diffrent approch and not use IoKit?
Thanks
I tried to register using Iokit to:
IOServiceMatching(kIOUSBHostDeviceClassName)
and
IOServiceMatching(kIOUSBInterfaceClassName);
and
IOServiceMatching(kIOUSBDeviceClassName);
First of all, there's no concept of "ejecting" in USB itself. Mounting, unmounting, ejecting, etc. are all storage device/volume concepts, and USB mass storage devices are just one type of storage device on which you can perform these operations.
You therefore need to look at the Disk Arbitration framework, specifically the DADiskEject function for ejecting. There is a certain mapping between I/O Kit and Disk Arbitration objects, but not all DADisk objects will necessarily have corresponding I/O Kit objects, as they also exist for APFS snapshot volumes, network mounts, etc. If looking for the device via I/O Kit is natural (for example because you're interested in a specific vendor+product ID pair) then you can easily find an IOMedia object's corresponding DADisk using DADiskCreateFromIOMedia.
For searching the I/O Kit registry for USB devices, use one of the documented matching dictionary formats.
For example, something like:
#{
#kIOProviderClassKey: #kIOUSBHostDeviceClassName,
#kUSBVendorID : #1234,
#kUSBProductID: #5678,
}
I know this is not directly programming related, but is there a way to purposely limit the signal strength on a testing mobile device to determine how your app performs under weak signal conditions?
I have an app that streams video and audio to a server, and need to test how it performs in low signal areas.. Any suggestions please?
One realistic way to do it is put it in a weak Faraday cage. You can make one or buy a bag or other pre-manufactured cage that protects against radio transmissions. As long as it's not too strong, it should weaken but not completely block the signal.
you can use a software like network link conditioner on OSX and netlimiter on windows, they have options for bandwidth limiting and even packet loss and presets for different typical situations plus the ability to create some yourself, you can just create a wifi network on your machine and connect to it from the device you want to test
please not that iOS has network link conditioner built-in (you can find it under the developer menu in settings), while android may have something on a rooted device (never tried anything though)
If run run your app in a simulator, many have options for emulating poor signal conditions.
There is at least one open source project whose aim is to simulate different network conditions for exactly the type of testing you are describing:
https://github.com/facebook/augmented-traffic-control
This can work in a cellular network but in this would most likely require your own base stations etc. This is possible via other open source projects (e.g. http://openbsc.osmocom.org/trac/), but is likely not necessary as you can probably simulate the same affect with the WiFi test set up.
I want to write a usb touchscreen kext for usb touch screen .
I have read the Kernel Extension Programming Topics and the I/O Kit Fundamentals etc,
My question is,
1 . how to get the input report messages from touch screen ?
2 . how to post the coordinate info to system ?
I have no idea, anybody help?
It depends on the hardware; moreover, this question is quite broad - you'll need to be more specific in your question to get more specific answers. I'll try to provide a broad overview:
A touchscreen has 2 parts:
Output: showing the image coming from the computer on the display
Input: the touch events to feed back into the computer
As you haven't asked about (1) at all, I assume your device just plugs into a display port on the Mac and is already displaying correctly. If not, you'll want to look into the IOFramebuffer API.
For (2) - Pretty much all USB input devices are HID devices of some form. If you're new to HID in general, you'll probably want to read and understand the USB HID specification and related documentation as you'll be using that information throughout.
OSX already comes with comprehensive support for the standard HID device classes such as keyboards, mice, touchpads, graphics tablets, etc. If your device claims to be any kind of HID device, OSX should already be detecting it and attaching its generic HID driver to it. You should see a IOUSBHIDDriver instance in the I/O Registry (eg. using Apple's IORegistryExplorer tool, or ioreg on the command line).
I'd also expect your device to conform to HID's absolute pointing device profile, so at least single touches should already be working properly. If it's a multitouch device, or you need other extra features, you'll probably want to implement a IOUSBHIDDriver subclass that generates or converts the necessary multitouch events.
If your device for some reason isn't already a HID USB device, you'll need to write a custom USB driver for it, and convert the events coming from it into HID events, as the HID events are passed directly into userspace and processed there. You can actually write USB drivers and generate HID events from userspace, so you might be able to avoid writing any kernel code at all if you prefer.
Apple provides some documentation on HID:
The HID Class Device Interface Guide covers some general concepts and the userspace interfaces.
The Kernel Framework Reference has API documentation for the various IOHID* classes in the kernel.
If you're going to be writing your own kernel HID device driver, your best bet is probably the IOHIDFamily source code. You can probably also find some open source examples around the web.
Apple's USB mailing lists is probably also worth checking, both for the archives and if you have questions. The darwin-kernel and darwin-drivers lists are also relevant.
Further to this question, I'm looking for a device that will allow me to connect two USB hosts, while still being fully programmable. I would like something that can do the following:
Masquerade as an arbitrary USB device
Take input from a PC and do nothing but pass it on to the other host.
I've been looking for a microcontroller (preferably pre-assembled) that will allow me to do this, but have so far come up blank. Does anyone know of a controller (preferably cheap) that will allow me to do this?
Take input from a PC and do nothing but pass it on to the other host.
This is non-sensical from a USB perspective. USB is a host-based protocol: a device will never send data unless a host requests it first. Keep in mind here, 'host' and 'device' have specific meanings here within the protocol itself; you can think of a 'host' as the master and the 'device' as the slave. These roles are baked into a USB controller. There is no way to convince a standard USB controller in any given PC or peripheral to swap roles. There are add-in cards for PCs that are USB device controllers (making your PC act as a device), but 'cheap' is not a word I would use to describe them.
What you really are trying to do is create something that is a USB device to device bridge. So, alright, you need to have two USB(2.0) device controllers (maybe not that expensive, some micros already have to on-the-go controllers). Then you have to get them to pass something meaningful to each other. That's really hard because, as I mentioned above, hosts must tell a device to send data, and can send data to a device whenever it wants. Assuming a game controller shows up as a HID device (assuming the console doesn't listen for some weird, custom descriptor, and use some weird, custom protocol), interrupt pipes will be used to transfer data. This pipe is guaranteed to be polled at some minimum rate. So you have the console requesting data at some rate, which is not fixed, and a host-as-gamepad sending data at some rate. It's going to impossible for the two to sync up, so you'll need some kind of decent sized buffer on the gadget you're trying to create, which adds more $$ and more complexity.
USB is also pretty fast. In high-speed (USB2.0), frames are 125 microseconds long. That means you have to be completing requests at around 8KHz, which seems slow compared to the clock speed of a microcontoller, but keep in mind you have to be doing everything else at once. I'm not sure if there's a hobbyist-level microcontroller that's going to have everything you need, especially one for which you don't need to roll your own USB stack.
Try this chip -> FTDI 232 they are protocols chips, it will translate the data to i2c, spi, serial, whatever u want. nice, easy and cheap :) . FTDI firm, have even better ones (vinculum), with otg and everything u need but I would start with the FTDI232. U just need to use your favorite uC to do the work u want. ... on the other hand, u have to do a little board, maybe some soldering, :). good luck!
You will need $$$$ in equipment and $$$$$ in development work to achieve things the way you imagine. You should better tell us what do you want to emulate, and take a look here if someone has already done it for you. If not then use LUFA library with some bigger USB AVR that can behave as USB host and connect two of them (one as USB guest and the other as USB host) via some other protocol (I2C/SPI/UART).
In the meantime there is a great solution for this Problem. Using the FaceDancer Library together with one of the boards supported by this great piece of software (i.E. GreatFET One) you get exactly what you want:
The GreatFET One has two USB connectors: the first one is used to simulate ANY kind of USB Device, while the second one is used to forward all requests/responses received/send via the first connector.
Of course this tool requires that you know the USB protocol of the device you want to simulate. Although there are some code samples you still have to know what you are doing as soon as you customize them.
I'm looking into writing an app that runs as a background process and detects when an app (say, Safari) is playing audio. I can use NSWorkspace to get the process ID's of the currently running applications but I'm at a loss when it comes to detecting what those processes are doing. I assume that there is a way to listen in on a process and detect what public messages the objects are sending. I apologize for my ignorance on the subject.
Has anyone attempted anything like this or are aware of any resources that can help?
I don't think that your "answer" is an answer at all...
and there IS an answer (which is not "42")
your best bet for doing this would be to write a pass-through audio output device. Much like soundflower, actually. so your audio output device would then load the actual (physical) audio output device and pass the audio data along to it directly (after first having a look at the audio stream, of course!). then you only need to convince your users to configure your audio device as the default audio output device so that the majority of applications which play sound will use it automatically. and voila...
your audio processing function will probably just do a quick RMS on the buffer before passing it along to the actual output device. and when the audio power crosses a certain threshold (probably something like -54dB with apple audio hardware), then you know that some app is making sound.
|K<
SoundFlower is an open-source project that allows Mac OS X applications to pass audio to each other. It almost certainly does something similar to what you describe.
I've been informed on another thread that while this is possible, it is an extremely advanced technique and not recommended. It would involve using Application Enhancer (APE) and is considered a not 'nice' thing to do. Looks like that app idea is destined for the big recycling bin in the sky :)