Setting sound output/input - objective-c

I've been looking all over the web, but I don't know if it is possible: can a Cocoa Mac OS X app change the sound input/output device? If so, how come?

can a Cocoa Mac OS X app change the sound input/output device?
Yes, by setting the relevant Audio System Object property.
If so, how come?
Probably because the user might want to change the default input or output device from within an application, rather than having to jump over to the Sound prefpane before and after or use the Sound menu extra.

I know this is an old post but I've been struggling these days trying to find a way of changing the sound input/output device using code and I finally found how to do it. In case someone else runs into the same problem, here's the answer!
There's a command line utility called SwitchAudio-OSX (https://code.google.com/p/switchaudio-osx/) that allows you to switch the audio source from the terminal. It is open-source and you can find the latest version here: https://github.com/deweller/switchaudio-osx.
Anyway, you can use these lines to change the sound input/output device:
UInt32 propertySize = sizeof(UInt32);
AudioHardwareSetProperty(kAudioHardwarePropertyDefaultInputDevice, propertySize, &newDeviceID); // To change the input device
AudioHardwareSetProperty(kAudioHardwarePropertyDefaultOutputDevice, propertySize, &newDeviceID); // To change the output device
AudioHardwareSetProperty(kAudioHardwarePropertyDefaultSystemOutputDevice, propertySize, &newDeviceID); // To change the system output device
Where newDeviceID is an instance of AudioDeviceID and represents the id of the device you want to select. Also, a list of all available devices can be obtained using this code:
AudioDeviceID dev_array[64];
AudioHardwareGetProperty(kAudioHardwarePropertyDevices, &propertySize, dev_array);
int numberOfDevices = (propertySize / sizeof(AudioDeviceID));

Related

Issue in implementing capacitive touch in PIC18F26K40 microcontroller using mTouch library

i currently working on PIC microcontroller. I have PIC18F26K40. I want to use CVD (Capacitive Voltage Divider) technique to implement capacitive touch button. I am using mTouch library of MCC (Microchip Code Configurator) library for that. I am doing same as per microchip documentation (links are here and here ). PIC is not detecting the touch. Here is my main method below:
void main(void)
{
// Initialize the device
SYSTEM_Initialize();
INTERRUPT_GlobalInterruptEnable();
INTERRUPT_PeripheralInterruptEnable();
LED_TRIS = OUTPUT;
while (1)
{
if(MTOUCH_Service_Mainloop())
{
/* Button API*/
if (MTOUCH_Button_isPressed(0))
LED_LAT = HIGH;
else
LED_LAT = LOW;
}
}
}
I have some doubts:
What is differential CVD.
What is driver shield. Do i need it?
Do i need to use two analog channels.
I have worked and tested CTMU mode of PIC18F26K22. Is there any way use CVD like CTMU.
If you have any solutions with or without library then let me know.
I am attaching some screenshot of my MCC configurations. Please go through it.
Help needed!
Note:
MPlab IDE: v5.50
Analog pin used for sensing: RB0
Programmer: PICKIT3
I came across your post whilst researching another issue with PIC mTouch on the same MPU you're using (or, rather the low voltage version, PIC18LF26K40). I am also using MPLAB X v5.50 with the mTouch plugin. Just wanted you to know that I was able to set up a single touch button with no problem on this chip, actually compiled and worked on the first try. So, you're on the right track!
You do not need to use the "driven shield" that is presented as an mTouch output (this is for improving signal integrity later when you're concerned about such things, see the various app notes on this). I used the "CS" (capacitive sensor) output only and it works fine.
This video helped me get started: https://www.youtube.com/watch?v=CCW3g9RqpZk
Hope this helps a bit.

What is correct "Path" usage for startRecordingVideo in distriqt camera ANE?

I'm trying to record a short video using the camera ANE from Distriqt and one of the params for startRecordingVideo() is "path".
I can't figure out what a valid path would be when saving on iOS (and probably Android when I get to it)
Unfortunately the documentation is somewhat lacking...
http://docs.airnativeextensions.com/camera/docs/com/distriqt/extension/camera/Camera.html#startRecordingVideo%28%29
An invalid path stops the device from even starting to record.
OK that was me just having a stupid 5 min...
var file:File = File.applicationStorageDirectory.resolvePath("sample.mp4");
Camera.instance.startRecordingVideo(file.nativePath);

Problems receiving Notifications from IOKit (CoreFoundation) for plugged Devices

I'm currently developing an application on 10.6.7 which should receive notifications when a new usb device is plugged in. I found out that there is a IOKit function which handles such stuff 'IOServiceAddMatchingNotification'. Because the return value from this specific function is 0, I think that the problem perhaps is in my matching Dictionary, which is given into this function. I declare the Dictionary that way:
CFMutableDictionaryRef matchingDict = IOServiceMatching(kIOUSBDeviceClassName);
Because I wan't to receive a notification for each device, I don't know if this is the right way to create this particular dictionary.
My complete code look like this:
ioKitNotificationPort = IONotificationPortCreate(kIOMasterPortDefault);
notificationRunLoopSource = IONotificationPortGetRunLoopSource(ioKitNotificationPort);
CFRunLoopAddSource(CFRunLoopGetCurrent(), notificationRunLoopSource, kCFRunLoopDefaultMode);
CFMutableDictionaryRef matchingDict = IOServiceMatching(kIOUSBDeviceClassName);
addMatchingNotificationResult = IOServiceAddMatchingNotification(ioKitNotificationPort,
kIOPublishNotification,
matchingDict,
deviceAdded,
NULL,
Does anyone has a idea why this won't work?
(Note: The Callback function is a static void c function and the rest is wrapped ins
ide a Obj-C class).
Thanks
Xcode 4, 10.6.7
Weirdly, you must empty the iterator returned by IOServiceAddMatchingNotification before the notification will be armed. I don't see that in the code provided, so that could be in the issue. That iterator is actually what you need to keep around to keep the notification running.
io_iterator_t ioNotification;
addMatchingNotificationResult = IOServiceAddMatchingNotification(ioKitNotificationPort,
kIOPublishNotification,
matchingDict,
deviceAdded,
NULL,
&ioNotification);
while ((service = IOIteratorNext(ioNotification)))
{
NSLog(#"Hey, I found a service!");
IOObjectRelease(service); // yes, you have to release this
}
In my opinion, u should download the source code form IOUSBFamily on opensource.apple.com, and then find the code for USB Prober, this application does exactly the same thing as u described, listening the USB Device attachment.(Further, USB Prober also get the general device and configuration descriptor, maybe it is also the things u need.)
Did you add the VID and PID of the device you wish to look for to your matching dictionary? For the dictionary you have, and VID= yourVid, PID= yourPid, it would be:
CFDictionaryAddValue(matchingDict, usbVendorId, yourVid);
CFDictionaryAddValue(matchingDict, usbProductId, yourPid);
Another thing - after the call to IOServiceAddMatchingNotification succeeds, you need to call your device-added handler with the iterator that was set in the call. That will arm the notification and check for existing devices.
the easiest way to do what i think you are describing is to hook into the DiskArbitration Framework. DA is relatively new to OSX and allows userland applications to examine devices as they get attached. it is what is used to open iTunes when an iPod is attached, launch iPhoto when a camera is attached, etc... if the USB device you are looking for is a storage device then this will work for you. otherwise you will need to go the matching dictionary route...

What's the modern equivalent of GetNextEvent in Cocoa?

I'm porting an archaic C++/Carbon program to Obj-C and Cocoa. The current version uses asynchronous usb reads and GetNextEvent to read the data.
When I try to compile this in Objective C, GetNextEvent isn't found because it's in the Carbon framework.
Searching Apple support yields nothing of use.
EDIT TO ADD:
Ok, so what I'm trying to do is run a document scanner through USB. I have set up the USBDeviceInterface and the USBInterfaceInterface (who came up with THAT name???) and I call (*usbInterfaceInterface)->WritePipeTO() to ask the scanner to scan. I believe this works. AT least the flatbed light moves across the page...
Then I try to use *(usbInterfaceInterface))->ReadPipeAsyncTO() to read data. I give this function a callback function, USBDoneProc().
The general structure is:
StartScan()
WaitForScan()
StartScan() calls the WritePipeTO and the ReadPipeAsyncTO
WaitForScan() has this:
while (deviceActive) {
EventRecord event;
GetNextEvent(0,&event);
if (gDataPtr != saveDataPtr) { // more data up the timeout
timeoutTicks = TickCount() + 60 * 60;
saveDataPtr = gDataPtr;
}
if (TickCount() > timeoutTicks) {
deviceActive = false;
}
}
Meanwhile, USBDoneProc incrementing gDataPtr to be the end of the data that we've read so far. It gets called several times during the asynchronous read, called automatically by the callback, as far as I can tell.
If I cake out the GetNextEvent() call in the WORKING code the USBDoneProc doesn't get called until the asynchronous readpipe timesout.
So it looks to me that I need something to give control back to the event handler so that the USBRead interrupts can actually interrupt and make the USBDoneProcget called...
Does that make any sense?
thanks.
I suppose the nearest thing to a Cocoa equivalent would be -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]. But bear in mind that GetNextEvent is archaic even for Carbon. The preferred way of handing events is the "don't call us, we'll call you" scheme, where the app calls NSApplicationMain or RunApplicationEventLoop and events are dispatched to you.
EDIT to add: Does you app have a normal event loop? If so, maybe WaitForScan could start a Carbon timer and return to the event loop. Each time the timer fires, do what you did in the WaitForScan loop.
there is a USB hidapi that works for mac on windows.
http://www.signal11.us/oss/hidapi/
may this could be of help to you?
It works fine (I can list the connected USB devices and connect/write/read to a device);
however, if i USB device is connected/disconnected during the runtime of the application, I don't see the new connected/disconnected devices.
See: https://github.com/signal11/hidapi/issues/14
If I add the following code to hidapi, then hidapi detects the new USB devices.
#include <Carbon/Carbon.h>
void check_apple_events() {
printf("check_apple_events\n");
RgnHandle cursorRgn = NULL;
Boolean gotEvent=TRUE;
EventRecord event;
while (gotEvent) {
gotEvent = WaitNextEvent(everyEvent, &event, 0L, cursorRgn);
}
}
I need to compile this on OSX10.5 because it uses Carbon instead of Cocoa.
I am currently looking how to transform this to Cocoa.
you are also trying to move your code to cocoa, right?
let me know if you find out; I'll post it here if I get it.
regards,
David
Have you considered throwing the whole thing out and using Image Kit's new-in-10.6 scanner support instead? Even if it's custom, writing a TWAIN driver for it might be easier (and is certainly better) than trying to twist Cocoa into a GetNextEvent shape.

How to know a video source (webcam) is available or not without creating capture window?

It is quite tricky because I wanna to take the result as a sign for later process. If a window flashes, it would be weird to user.
(This is not an answer, just refreshing the question and adding some details:)
Suppose you need to open a video capture driver (webcam) with code like this (delphi, but easy understandable):
result:= SendMessage(hCapWnd, WM_CAP_DRIVER_CONNECT, FDriverNo, 0);
It works fine, except when camera/webcam is busy (opened by another application, for example moviemaker). Then the capture driver suddenly shows a "select video source" window that blocks your application (but not moviemaker, which keeps recording). SendMessage function becomes modal and will not return until undesired window is closed.
Is there a way to detect if a capture driver is busy with another application before connecting to it?
Thanks
This function return number of available webcams and scanners on your mashine(с++).
int GetNumCam()
{
int MemberIndex = 0;
HDEVINFO dev;
SP_DEVINFO_DATA DeviceInfoData;
DeviceInfoData.cbSize = sizeof(DeviceInfoData);
dev = SetupDiGetClassDevsA(&GUID_DEVINTERFACE_IMAGE, NULL,NULL,DIGCF_PRESENT);
if (dev == NULL)
{
MessageBoxA(0,"it is null..","vse propalo",0);
return -1;
}
else
{
while(SetupDiEnumDeviceInfo(dev,MemberIndex, &DeviceInfoData))
{
MemberIndex++;
}
}
return MemberIndex;
}
I wonder if sending a broadcast message could do. I mean, suppose you send a VFW info request message to all windows in system. Then, all windows actually doing VFW processing will answer their status info and you will know which of them are doing video processing; some kind of shouting "anybody here...?"
But it looks like brute force, or even hacking. May be I'll test it... may be not. I am sure there must be a smarter way to know if a video capture driver is busy with another application.
(btw... anybody here?)
I was afraid it would happen.
First I enumerated all opened windows in system, then executed this instruction for each HWND, which just asks for driver information (pascal syntax):
SendMessage(h, WM_CAP_DRIVER_GET_NAME, length(driver)*sizeof(char), LPARAM(PChar(driver))
According to Msdn help, WM_CAP_DRIVER_GET_NAME results are:
"Returns TRUE if successful or FALSE if the capture window is not connected to a capture driver"
(Bold is mine). So it appears a good way to know:
1-If the window is capturing. So it is applyable to ALL windows, don't matter if they are capturing or not.
2-And if so, it tells you which driver is using.
However, after first test round, the results were:
- Task Manager (it was running) crashed and closed
- Explorer crashed and closed (reopened again automatically)
- Belkin Wireless monitor (my pc's WiFi driver) crashed and closed
- Eset Nod32 antivirus crashed, did not closed
The first conclussion can be that this is a bad way to locate which applications are capturing video in a system. But I must ensure to dismiss the possibility of a bug.
I'll keep reporting.
This is not a good solution my any means but I found out that if you disable and enable the camera in device manager immediately before sending the WM_CAP_DRIVER_CONNECT message then for some reason the video source window does not appear and the function returns and works OK.
So for a script I was working on I had to download devcon.exe and I put "devcon disable *PID_3450*MI_00*" and "devcon enable *PID_3450*MI_00*" immediately before my WM_CAP_DRIVER_CONNECT and it seems to work consistently. Unfortunately you need to run as administrator to be able to disable/enable devices. Again not a proper fix by any means...
(Hardware ID of my cam is USB\VID_0AC8&PID_3450&MI_00)