Long audio_control_interface_name appears to be incompatible with Windows

[stanelie]

CircuitPython version

Adafruit CircuitPython 9.2.0 on 2024-10-28; Waveshare ESP32-S3-Zero with ESP32S3

Code/REPL

import usb_hid, usb_midi

usb_hid.disable()
usb_midi.enable()
usb_midi.set_names(streaming_interface_name="new_streaming_interface_name", audio_control_interface_name="new_audio_control_interface_name", in_jack_name="new_in_jack_name", out_jack_name="new_out_jack_name")

Behavior

On my device, if I input this code in the boot.py file, it does indeed change the midi device name in the windows device manager. However, the device does not show up in windows midi software anymore.

If I comment out the line that starts with usb_midi.set_names, the midi device works again, with the default name (CircuitPython Audio).

I'm using the example code from #9146

Description

No response

Additional information

No response

[stanelie]

Update :
If I use usb_midi.set_names(audio_control_interface_name="potato_midi") (if I do not use all the parameters), it works. The name changes, and the device works.

[dhalbert]

The pasted code above has a broken line, with missing text at the end. Maybe this is just a copy-paste error into the issue? Could you check that and edit your original post, if necessary?

Any errors in boot.py will be reported in boot_out.txt.

[stanelie]

It was a copy/paste error, I corrected the above post.
No error reported in boot_out.txt

[jepler]

Just as a data point, I put the updated code in the boot.py of my Metro M4 Grand Central and reset it with the reset button. Using Linux lsusb to list information about USB devices I can see that all 4 of the strings are shown as supplied:

$ sudo lsusb -vv -d 239a:8032 | grep new_
      iInterface              8 new_audio_control_interface_name
      iInterface              7 new_streaming_interface_name
        iJack                   9 new_in_jack_name
        iJack                  10 new_out_jack_name

The device also appears in the devices I can use with Linux command-line MIDI playback software like aplay.

Did you try more than one piece of MIDI software on Windows? Do you mind saying what software you did try? What if you specify a name, but make it the exact same name that CircuitPython uses?

-      iInterface              9 CircuitPython Audio
+      iInterface              9 new_audio_control_interface_name
-      iInterface              8 CircuitPython MIDI
+      iInterface              8 new_streaming_interface_name
-        iJack                  10 CircuitPython usb_midi.ports[0]
+        iJack                  10 new_in_jack_name
-        iJack                  11 CircuitPython usb_midi.ports[0]
+        iJack                  11 new_out_jack_name

Two more random notes:

• Normally CircuitPython was using the same string for both the in and out jacks. What if you give the in and out jacks the same name?
• what if it's a problem with cached device info? It's a different scenario than described here but maybe using USBDeview to remove the cached info would allow your MIDI software to pick up the correct data.

I only use Linux and am a only a MIDI dabbler so feel free to take any of the above with a huge grain of salt.

[stanelie]

I used MidiOX, MidiView and Bome to verify I could talk to the midi device or not. Every time I change the name, I delete the device from the device manager so that it can be detected again with the proper name. Otherwise, the old name "sticks".

I will try more scenarios and report back.

[stanelie]

Using the same names that CircuitPython uses by default, it works :
usb_midi.set_names(streaming_interface_name="CircuitPython MIDI", audio_control_interface_name="CircuitPython Audio", in_jack_name="CircuitPython usb_midi.ports[0]", out_jack_name="CircuitPython usb_midi.ports[0]")

[jepler]

OK, it's helpful to know it's not specific to a single piece of Windows software, and that it's probably not a problem with cached device info (unless all three of those programs have device info caches with the exact same bug which is unlikely)

I tested on a different microcontroller than you did (just because of what was at my workspace), but the USB descriptor code is the same for every kind of device as far as I know.

[dhalbert]

I spent a long time debugging a similar problem on macOS : https://forums.adafruit.com/viewtopic.php?t=212247. I think I replicated your problem, using MIDITools to list the devices. I also deleted the device from Device Manager each time, and even rebooted once.

It might be worth searching the Windows Registry for the original jack names after deleting the device. The fact that it works when you restore the original jack names, even explicitly, suggests to me some kind of caching problem.

[stanelie]

If I reduce the length audio_control_interface_name="new_audio_control_interface_name" by 1 character, it works.
Example :
usb_midi.set_names(streaming_interface_name="new_streaming_interface_name", audio_control_interface_name="new_udio_control_interface_name", in_jack_name="new_in_jack_name", out_jack_name="new_out_jack_name")

[stanelie]

Not really sure what else I can try. Is there a way to confirm if it's a length issue for the fields in usb_midi.set_names?

[dhalbert]

It seems like there is a length issue. If you use a shorter name, it's working fine for you now? We'll look at the length issue and fix it.

[stanelie]

Correct. If I do not use the provided example and use shorter values instead, it works. So, this is solved for me.

[jepler]

USB limits "string descriptors" to 126 Unciode code points. I skimmed the USB MIDI standard and did not see any additional restriction imposed on the interface names. However, we also can't effectively argue with whatever it is Windows is doing.

Is the "fix" to note in the documentation that "some operating systems (Windows) require descriptors be at most 31 ASCII letters or 31 Unicode code points"? It'd be too bad to break someone's working project on Linux, which did not appear to have any such limitation.