Permission to access USB Midi Device

[mario...@gmail.com]

Hi

I have tried the example apps from https://github.com/philburk/android-midisuite
on a Samsung Tab 3 running android 7.

They work but they do not list a USB attached Roland M-ONE device.

The device works properly because another app (USB Midi Monitor)

https://play.google.com/store/apps/details?id=com.extreamsd.usbmidimonitor&hl=en_GB

is able to use it.

What I see is that when I run the USB Midi Monitor it asks for permissions to access the USB Midi,
while the apps in the midisuite never ask for it and cal only list the virtual midi devices.

Nothing about USB permissions is mentioned here

https://developer.android.com/reference/android/media/midi/package-summary.html

I must be missing something really basic.

Cheers

[mario...@gmail.com]

Answering my own post.

Things seem more complicated than they should.


So, my USB Midi has a switch to be in Tablet or Desktop mode? Why? I thought the linux kernel in the android was more or less the same as a desktop. And I am using a OnTheGo adaptor.
Anyway, when it is Desktop mode, only works in USB Midi Monitor.

In tablet mode works for the midisuite-like apps as well, but (of this I am not 100% sure) I had to select which USB Connection type I wanted to activate (Midi, MTP, PPTP....) otherwise it would not work.


Moreover, I found this app on github

https://github.com/google/music-synthesizer-for-android

which uses the midi framework, but NOT using MidiManager & Co.
They seem to access USB directly.


How much I miss jackd! So much easier!

Anyway, I got something working now, but I feel some more comprehensive explanation from android wouldn't harm.

Andrea

[mario...@gmail.com]

This might seem like a silly question but I would like to buy a digital piano with USB Midi port,
then, will it behave like a Desktop or a Tablet?

If it behaves like a Desktop, then I cannot use "this" MIDI framework, but a different one which works for both?

Or maybe I am making a big meal out of nothing?

Andrea

[Phil Burk]

Hello Andrea,

> they do not list a USB attached Roland M-ONE device.

The Roland UM-ONE device is an older design and is not MIDI class compliant. So it does not work with the ALSA drivers and, therefore, does not work with the Android MIDI API.

A good way to tell if if a device is NOT compliant is if it comes with drivers for Mac and Windows. A class compliant devices does not need drivers.

Apps that access USB directly may or may not be able to support the Roland UM-ONE.

> So, my USB Midi has a switch to be in Tablet or Desktop mode?

What "USB MIDI"? Are you referring to an app? Or a hardware MIDI interface? Or some part of the OS? Or a MIDI device like a keyboard?

> This might seem like a silly question but I would like to buy a digital piano with USB Midi port,
> then, will it behave like a Desktop or a Tablet?

I'm sorry, I don't understand the question.

If the piano is relatively modern then it should be class compliant. Ask at the store. They should know. If not, ask if it requires drivers.

If you connect it with an OTG adapter to an Android device then it should show up as a keyboard in Android MIDI apps such as the Mobileer MIDI Scope and Synth Example. If you run the Mobileer MIDI Keyboard app then you should be able to play notes on the piano using the Android touch screen keyboard.

Note that if you connect an Android device to a computer without an OTG adapter then you can use the Android device as a MIDI peripheral. Look in the notification for USB control.  You could use this, for example, to control a sequencer on a laptop using an Android keyboard app.

Phil Burk

[mario...@gmail.com]

I think I wasn't very precise and I would like you to help me understand the situation of MIDI on Android.
The USB Midi adaptor I have is a Roland UM-ONE mk2.
This device had a switch Tablet / Desktop mode

I have used it for a while in Desktop mode and it works very well in Linux and is immediately recognised by ALSA and I have been using in Jackd via a2jmidi.

This device has the usual type-A USB connector which plugs into a computer port.

For an Android tablet I need an adapter which I believe is called USB-OTG adapter. I have one and when I use it I see the following behaviour

1) The apps from https://github.com/philburk/android-midisuite only work with this Midi adaptor if it is switched to Tablet mode
2) Other apps like "USB Midi Monitor" work no matter what the switch is set to
3) This 2nd type of app requires me to grant USB access permission which I do not need for the type 1) above

my questions are

1) why has the industry come up with the need to have a switch on these devices? what problem is it solving?
2) what if I get a digital piano with no switch, which of the 2 behaviours will I get? and I much prefer the API of https://github.com/philburk/android-midisuite rather than some direct USB access
3) can the Android / Linux kernel do something so that it works in both cases?

Hope my questions make sense.

Cheers

[Phil Burk]

Hello Andrea,

> 1) why has the industry come up with the need to have a switch on these devices? what problem is it solving?

I have never seen a switch like that before.  So I can only guess why Roland did that.

An earlier version of the Roland UM-ONE was NOT class compliant. But the mk2 can apparently be class compliant because it works sometimes with Android. So I suspect the switch toggles between the new class compliant mode or the old mode. But this is just a guess. You might need to ask Roland.

> 1) The apps from https://github.com/philburk/android-midisuite only work with this Midi adaptor if it is switched to Tablet mode

Then Tablet mode must be class compliant. In Desktop mode, a custom driver may be loaded from the Roland device for Windows desktops. Android Tablets will not load a custom driver.

> 2) Other apps like "USB Midi Monitor" work no matter what the switch is set to

Some apps support old custom devices and class compliant devices. That is great but it is a lot of work for them. Most new apps only support class compliant devices.

> 3) This 2nd type of app requires me to grant USB access permission which I do not need for the type 1) above

That is because they have to access the USB library directly. That can be a problem and can interfere with other apps. That is why they need permission.

> 2) what if I get a digital piano with no switch, which of the 2 behaviours will I get? and I much prefer the API of https://github.com/philburk/android-midisuite rather than some direct USB access

Almost ALL of the new USB-MIDI devices are class compliant. So a new digital piano product should work fine with Android. But if it is an old design, then maybe not. To be sure, you need to ask the store if the piano is "MIDI class compliant". 

If they don't know then ask if it comes with a CD that contains "drivers". If yes then it requires custom drivers and is not class compliant. Note that some products may come with applications on a CD. That is fine. You just want to avoid "drivers" on a CD.

> 3) can the Android / Linux kernel do something so that it works in both cases?

It is too difficult to support all of the old non-compliant devices. That is why the industry switched to MIDI class compliant drivers.

I hope this helps.

Phil Burk

--
You received this message because you are subscribed to the Google Groups "android-midi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-midi+unsubscribe@googlegroups.com.
To post to this group, send email to androi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-midi/d08da403-df34-4b17-938a-5da31dda9226%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Pedro Lopez-Cabanillas]

On Friday 02 March 2018 12:26:14 'Phil Burk' via android-midi wrote:

> > 1) why has the industry come up with the need to have a switch on these

> devices? what problem is it solving?

>

> I have never seen a switch like that before. So I can only guess why

> Roland did that.

>

> An earlier version of the Roland UM-ONE was NOT class compliant. But the

> mk2 can apparently be class compliant because it works sometimes with

> Android. So I suspect the switch toggles between the new class compliant

> mode or the old mode. But this is just a guess. You might need to ask

> Roland.

 

There is little need for guessing. There is a document explaining how the switch works:

https://static.roland.com/assets/media/pdf/UM-ONEmk2_l_iPad_e02_W.pdf

 

The switch was provided for connecting the UM-ONE to the Apple iPad, thru the Apple's camera adapter.

 

MIDI has been neglected in Android for so long that it was irrelevant for Roland or their customers when the device was launched.

> Almost ALL of the new USB-MIDI devices are class compliant. So a new

> digital piano product should work fine with Android. But if it is an old

> design, then maybe not. To be sure, you need to ask the store if the

> piano is "MIDI class compliant".

>

> If they don't know then ask if it comes with a CD that contains

> "drivers". If yes then it requires custom drivers and is not class

> compliant. Note that some products may come with applications on a CD.

> That is fine. You just want to avoid "drivers" on a CD.

 

Roland products often require a special driver for their enhanced USB-MIDI protocol called "high-performance FPT processing". Sometimes their products also work as class compliant USB-MIDI devices. Looks like this is the case for the UM-ONE mk2.

 

> > 3) can the Android / Linux kernel do something so that it works in both

> cases?

>

> It is too difficult to support all of the old non-compliant devices. That

> is why the industry switched to MIDI class compliant drivers.

 

It has been happening to the ALSA USB driver that many devices (non class compliant) require special "quirks" to make them work in Linux. The standard USB-MIDI protocol was supported from day one. For other devices, here is the quirks table ("In a perfect world, this file would be empty."):

https://github.com/torvalds/linux/blob/master/sound/usb/quirks-table.h

 

Most of the time, when a new device is not supported by Linux, users ask to the ALSA project for support, in which case they are requested to run a simple command after the device is plugged:

 

$ lsusb -v

 

This command provides detailed information about of the USB descriptors of the plugged devices. Upon receiving the listing, a developer (usually Clemens Ladisch) adds the corresponding quirks to the table and after successful testing the next release of Linux shall work with the device. That is how Linux grows, folks.

 

Anyway, because Android does not use all of the ALSA/MIDI infrastructure, these non class compliant devices remain unsupported in Android unless the quirks are rewritten in Java. Sorry, but I find this situation lamentable, and I don't think it improves the relevancy of Android for serious MIDI users.

 

Regards,

Pedro

 

[Phil Burk]

Hello Pedro,

Thanks for sharing this information.

On Friday, March 2, 2018 at 3:59:43 PM UTC-8, Pedro Lopez-Cabanillas wrote:
> There is little need for guessing. There is a document explaining how the switch works:
> https://static.roland.com/assets/media/pdf/UM-ONEmk2_l_iPad_e02_W.pdf
> The switch was provided for connecting the UM-ONE to the Apple iPad, thru the Apple's camera adapter. 

Thanks for the link. They say the TAB setting is "For connecting an iPad. [snip] Driver installation is not necessary."

The key part is that the driver does not need to be installed. That means it will operate as a class compliant device, which will work with iPad, and also with Android M and later.

> It has been happening to the ALSA USB driver that many devices (non class compliant) require special "quirks" to make them work in Linux. The standard USB-MIDI protocol was supported from day one. For other devices, here is the quirks table

If a device requires a completely custom driver then the quirks table is not enough. The driver must be installed. The quirks table is helpful when a device is class compliant but has some minor oddity or "quirk" that needs to be corrected.

> Anyway, because Android does not use all of the ALSA/MIDI infrastructure, these non class compliant devices remain unsupported in Android unless the quirks are rewritten in Java. 

Android uses the USB quirk table. 

   https://android.googlesource.com/kernel/msm/+/android-7.1.0_r0.2/sound/usb/quirks-table.h

The ALSA MIDI code runs at the native code level. Only the API and high level service runs in Java.

Android supports quirks but not custom drivers because that would be a security risk.

Phil Burk

[mario...@gmail.com]

Thank you guys for the answer.
The Tablet Mode is the Device compliant and comparing the output of lsusb I see a lot of Audio / Midi etc and no "Vendor Specific" as in the Desktop mode.

It goes without saying (and I should really have tested before) that on a Linux PC, they both work.
I always read that switch the other way round: Desktop = Good, Tablet = some special stuff for iPads. But it was exactly the opposite.

So I am happy now, that you a lot.

The only piece of forensic for the advanced reader is why in Linux the legacy mode works and not in Android. There is no custom driver installed in linux, it all happens inside the kernel (e.g. quirks), unless it is a cooperation Kernel / Alsa which is missing in Android.
But, since I found the answer I wanted, I am happy and won't bother you further.

About the piano, it is (will be) a new Kawai and I hope they have moved to Device Compliant, but I know what to check now.

Back to development now.

Thank you guys.

[Pedro Lopez-Cabanillas]

On Friday 02 March 2018 23:51:59 mario...@gmail.com wrote:

> The only piece of forensic for the advanced reader is why in Linux the

> legacy mode works and not in Android. There is no custom driver installed

> in linux, it all happens inside the kernel (e.g. quirks), unless it is a

> cooperation Kernel / Alsa which is missing in Android.

 

Both modes of the switch work in Linux because the quirk for supporting the COMP mode of the UM-ONE was included long time ago in ALSA's snd-usb-audio kernel driver stack:

 

https://www.mail-archive.com/alsa...@lists.sourceforge.net/msg27914.html

 

ALSA in Linux is both the driver layer (in kernel) and the userspace library layer (libasound.so). The latter is missing in Android, replaced by a "tinyalsa" library providing access only to the PCM and Mixer interfaces (audio only). The raw MIDI facilities are missing, even if the modules could be built and loaded in the kernel.

 

On top of the raw MIDI interface, ALSA also provides an advanced MIDI Sequencer interface, with device sharing, scheduling, virtual ports and low latency routing (virtual MIDI cables). All of it (kernel and library) was stripped from Android.

 

Regards,

Pedro