USB MIDI device does not show up on MacOS

[stuffmatic]

Describe the bug I've adapted the example code from the readme to run on an STM32F3DISCOVERY board. When I connect the board to my macbook, the USB MIDI device does not show up in the Audio MIDI Setup utility, which is used to configure MIDI I/O on macOS. However, the board does show up in the list of connected USB devices, with metadata matching what I've specified in my code. I've also added code for flashing a led while polling, and the led keeps flashing, so I doesn't seem like the application crashes. This leads me to believe that there might be something wrong with get_configuration_descriptors.

Has anyone used this library to successfully implement a USB MIDI device that is recognised as such by the host?

To Reproduce

1. Adapt the example in the README to the STM32F3DISCOVERY board
2. Connect the board to a macbook pro and notice that the board does not show up as a MIDI device in Audio MIDI Setup.

Expected behavior The board should appear as a USB MIDI device in Audio MIDI Setup utility.

Desktop macOS Mojave 10.14.6

[btrepp]

Hi.

I'm not 100% about the readme code, @p4ddy1 might be able to help there. He contributed the midi-out code.

As far as it being recognizable, yes :). https://github.com/btrepp/rust-midi-stomp is a project that works on a bluepill. It was for a friend and it works in mainstage on mac for his purposes. However that is midi-in for the host.

EDIT: It might be helpful if you can link to modifications you did to adapt it to STM32FDISCOVERY

[stuffmatic]

Thanks for the pointer to rust-midi-stomp. Using .device_class(USB_CLASS_NONE) when building the USB device makes it show up as expected. The code in the readme uses .device_class(USB_AUDIO_CLASS).device_sub_class(USB_MIDISTREAMING_SUBCLASS) which seems to be the problem.

I'll see if I can find the time to put together a proper cargo example for the STM32F3DISCOVERY board to help future newcomers.

[p4ddy1]

Hi. I don't own a Mac so unfortunately I could not test if the code works on MacOS. On Linux and Windows it worked so I thought it will be no problem on MacOS either, but I was not 100% sure if the device classes were correct (seems like the were not :D). Feel free to change it to a more appropriate value. Proper examples would be a great addition too!

[btrepp]

Thanks for the pointer to rust-midi-stomp. Using .device_class(USB_CLASS_NONE) when building the USB device makes it show up as expected. The code in the readme uses .device_class(USB_AUDIO_CLASS).device_sub_class(USB_MIDISTREAMING_SUBCLASS) which seems to be the problem.

I'll see if I can find the time to put together a proper cargo example for the STM32F3DISCOVERY board to help future newcomers.

Yeah this makes sense. Thanks for this too :).

USB is a bit of a beast, I think maybe what is happening here is that with USB_AUDIO_CLASS, OSX is probably assuming there is an input/output device, and when those descriptors don't come it thinks the whole item is broken.

On the windows side there was even interesting things around 'how quick you must respond by' hence why the rust stomp box prioritizies the usb comms stack over everything else in the RTIC handlers

[x37v]

I just verified the same osx behavior as @stuffmatic saw, the default example code in the README doesn't make my device show up as a MIDI device on osx but this does:

let usb_dev = UsbDeviceBuilder::new(usb_bus, UsbVidPid(0x16c0, 0x5e4))
    .product("daisy midi")
    .device_class(USB_CLASS_NONE)
    .build();

I haven't gone back to my linux machine to test to see if the same device works there as well

[stuffmatic]

I just had a look at the spec and it looks like using .device_class(USB_CLASS_NONE) is correct. At the top of page 11, the spec states that

As is the case for all audio functionality, USB-MIDI functionality resides at the interface level in the USB Device Framework hierarchy

Also, in the Simple MIDI Adapter example on page 37 bDeviceClass is set to 0x00, with the comment Device defined at Interface level.

[sourcebox]

Closed via 726f67768a9243b56baffa13b2b4c91d7965a37e