Status Update
Comments
vi...@google.com <vi...@google.com> #2
What steps are needed to reproduce this issue?
Can you provide the API document where this expected behavior is explained?
Screen Record of the Issue
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the bug report and screenshot to google drive and share the folder to android-bugreport@google.com, then share the link here.
al...@gmail.com <al...@gmail.com> #3
vi...@google.com <vi...@google.com> #4
Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.
jd...@gmail.com <jd...@gmail.com> #5
There are no exceptions being thrown, no crash happening or anything that would require capturing a bug report. The system simply does not report the correct number of ports on USB devices that have more than one. This is a regression. As mentioned, things worked as expected before.
For API documents see android.media.midi docs.
Steps to reproduce: Connect multi-IO interface and look at the MidiDeviceInfos the MidiManager reports (two of which I pasted into the original report)
In terms of changes to reported device names: That's just a very unsensitive change in behavior, not a "bug". Both the Android assigned ID (#...) and "MIDI 1.0" are certainly not part of a USB device's name. The transferred information should be made available via getters if needed at all.
vi...@google.com <vi...@google.com> #6
We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
vi...@google.com <vi...@google.com> #7
Thanks again for the feedback! Our product and engineering teams have evaluated the request and responded:
The following needs to be done:
Query the number of input/output jacks for each endpoint and the ids. We can add the class specific descriptor to the endpoint descriptor and query it. When data is sent through the UsbMidiPacketConverter, both the input and output sides of this assumes that packets use cable number 0. Clearly this is not the case given this bug. For USB -> raw MIDI, we can parse out the cable number out. Instead of returning a byte array, we should just return the number of bytes outputted. After, the caller should get pull each output string. For raw MIDI -> USB, there should be an additional input parameter of which jack id to use. Since each jack id's inputs should be independent, there should be some logic to make sure there is not cross-contamination. In UsbDirectMidiDevice, we should now query the class specific endpoint descriptor for MIDI 1.0 devices. Creating the device in regards to MidiService should use the new input/output count. When reading from USB, no new threads should be created. After the USB data comes in, the jack id will tell us where to pipe the data. When sending to USB, new threads should be created. One set of threads should get MIDI events and add it to a queue. Another thread should read from the queue to send this to USB.
It seems like there are external and embedded ports. We can simply use the ids of the embedded ports.
If the ports are not exposed, we just use a jack id of 0 for everything like we do now.
If the ports are exposed, we should use those jack ids.
Thanks
vi...@google.com <vi...@google.com> #8
The development team has fixed the issue and it will be available in a future build.
Description
Here are DeviceInfos as seen by a Pixel 4A (running Android 13 Build Nr TP1A.2205.002) for two USB interfaces with multiple ports:
MidiDeviceInfo[mType=1,mInputPortCount=1,mOutputPortCount=1,mProperties=Bundle[{manufacturer=iConnectivity, product=iConnectMIDI4+, name=iConnectivity iConnectMIDI4+#889 MIDI 1.0, serial_number=00001395, version=1.00, usb_device=Supplier{VAL_PARCELABLE@368+1332}}],mIsPrivate=false,mDefaultProtocol=-1
MidiDeviceInfo[mType=1,mInputPortCount=1,mOutputPortCount=1,mProperties=Bundle[{manufacturer=M-Audio, product=MIDISPORT 2x2 Anniv, name=M-Audio MIDISPORT 2x2 Anniv#349 MIDI 1.0, serial_number=null, version=1.00, usb_device=Supplier{VAL_PARCELABLE@340+832}}],mIsPrivate=false,mDefaultProtocol=-1
The M-Audio MIDISPORT 2x2 as the name suggests has two IO pairs, the iConnectivity box has 16 per USB port.
Also: Changes to the reported device name, which now includes the ID ("#...') and "MIDI 1.0", are breaking peoples' code...