You could create a MIDIServerPlugin that communicates with your PCIe audio device kext via a custom userclient API that you would create.
Your PCI device driver handles the MIDI data from hardware and queues it for receive in your plugin. Your plugin ‘writes’ midi data to your PCIe driver. The midi driver and pcie driver are separate binaries that communicate through the user client API. You should look into AudioDriverKit to see if you can do this with a dext instead of trying to do this with a kext. Matt > On Dec 11, 2022, at 12:05 PM, Gagan Sidhu via Coreaudio-api > <[email protected]> wrote: > > someone shared some helpful information regarding CoreMIDI and also some code > for a USB device using it. > > however, i don’t think that can work here. > > after some preliminary testing, i’m not sure i can implement MIDI in a PCI > device. > > there are header conflicts between IOKit/pci/IOPCIdevice.h and CoreMIDI/*.h > > this is disappointing, but right now i’m getting header conflicts. > >> Showing All Messages >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:228:7: >> Functions that differ only in their return type cannot be overloaded >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:287:41: >> Typedef redefinition with different types ('UnsignedWide' vs 'UInt64' (aka >> 'unsigned long long')) >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:309:41: >> Typedef redefinition with different types ('unsigned char' vs 'bool') >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:596:9: >> Unknown type name 'wide' >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:689:9: >> Unknown type name 'wide' >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/MacTypes.h:708:1: >> Conflicting types for 'Debugger' > > > relevant includes are: > >> #include <IOKit/pci/IOPCIDevice.h> >> #include <CoreMIDI/MIDIServices.h> >> #include <IOKit/audio/IOAudioControl.h> >> #include <IOKit/audio/IOAudioLevelControl.h> >> #include <IOKit/audio/IOAudioToggleControl.h> >> #include <IOKit/audio/IOAudioDefines.h> >> #include <IOKit/audio/IOAudioPort.h> > > > i recall getting this kind of error early-on (with other headers) but > obviously it got resolved. i’m hoping there is something similar i can do > this time. > > i don’t know if it’d be possible to communicate with the CFBundle in an > interrupt context the way apple is suggesting. > > i am thinking CoreMIDIServer.h is what i need, but unsurprisingly there is no > header in the frameworks directory. > > i’ll keep you guys updated, but there has to be a way around this. of course > apple would make it difficult given their direction in the past 2+ years. > > midi in a pci audio device is too obvious of a “need” > > Thanks, > Gagan > >> On Dec 11, 2022, at 7:08 AM, Gagan Sidhu via Coreaudio-api >> <[email protected] <mailto:[email protected]>> wrote: >> >> hi again all, >> >> before i begin my testing, i wanted to ask about handling rudimentary MIDI >> calls. >> >> the documentation reads: >> >>> "Note: MIDI device drivers are not I/O Kit drivers. The MIDI device driver >>> model is based on the CFPlugIn architecture and typically loads a CFPlugIn >>> bundle from /System/Library/Extensions or Library/Audio/MIDI Drivers. >>> >>> For MIDI devices that cannot be directly addressed from a user-space device >>> driver (for example, a MIDI interface built into a PCI card), you must >>> split your driver into two parts: an I/O Kit device driver that matches >>> against the device and a CFPlugIn bundle that manipulates the I/O Kit >>> driver using a user client.” >> >> (https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/WritingAudioDrivers/AudioOnMacOSX/AudioOnMacOSX.html#//apple_ref/doc/uid/TP30000730-TPXREF103) >> >> this is exactly the case i’m trying to handle, but i’m not sure if a >> PCIAudioDevice driver is considered user-space or not. >> -this may sound like a noobish confession, but i understand this line >> is drawn differently for BSD and Linux, and i don’t know where exactly it >> was at the time these docs were writen. >> -i do know that the newer (bad) SampleIOAudioDevice (from >> wwdc21) driver highlights being more “user-space”, so maybe a driver written >> for IOKit is considered “kernel space” >> >> anyways, i have a MIDI device that should be accessible within the device >> driver, as Clemens does here with the creation of am MPU401 device: >> >> https://elixir.bootlin.com/linux/v4.14.298/source/sound/pci/oxygen/oxygen_lib.c#L702 >> >> i have googled around the terms “ioaudiodevice” and midi, only to find >> nothing. >> >> the OS-X and Kernel Programming book by halvorson and clarke says: >> >> "Core MIDI / MIDI Server framework contains APIs for working MIDI.” >> >> i was hoping one of the readers could point me to some documentation that >> may be helpful on this topic. i am hopeful the midi/uart interface can be >> dealt with inside the driver. >> >> and if it can’t, i am hoping this bundle i’d need to write wouldn’t be that >> bad. but i already have all of the uart stuff put in the right spot, so it’s >> just a matter of having a way to handle a uart interrupt on the workloop for >> a midi device. >> >> see the interrupt handling for the driver here: >> https://elixir.bootlin.com/linux/v4.14.298/source/sound/pci/oxygen/oxygen_lib.c#L117 >> >> >> i just converted this function to the IOWorkLoop-equivalent. >> >> >> Thanks, >> Gagan >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Coreaudio-api mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/coreaudio-api/broly%40mac.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/mxmora%40apple.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
