Discussion:
USB MIDI keyboard Miditech Garagekey Mini - works with Linux only if connected after powerup
(too old to reply)
w***@gmail.com
2015-07-30 12:43:11 UTC
Permalink
Hi,

Last time I've bought a USB MIDI keyboard Miditech Garagekey Mini
http://www.miditech.de/211-produkte-i2-garage-key-mini

The device works perfectly with Windows 7 and Windows 8.1, however when I boot the Linux O/S, it works only when gets connected after the system is fully started.
If the device is connected before the computer is switched on, it is recognized correctly, and reported by lsusb correctly, but it does not send any MIDI messages.

I've checked the dmesg contents and haven't noticed any suspicious messages.
Below I attach the device descriptors as reported by "lsusb -v" (with serial number partially masked for privacy reasons).

With best regards,
WZab

Bus 003 Device 009: ID 1acc:1a0f
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1acc
idProduct 0x1a0f
bcdDevice 2.00
iManufacturer 1 miditech
iProduct 2 GarageKey mini
iSerial 3 miditech-97-1A0F-XXXXXXXX-miniG
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 101
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 9
bInCollection 1
baInterfaceNr( 0) 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 3 MIDI Streaming
bInterfaceProtocol 0
iInterface 0
MIDIStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 65
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 1
iJack 0
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 2 External
bJackID 2
iJack 0
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 3
bNrInputPins 1
baSourceID( 0) 2
BaSourcePin( 0) 1
iJack 0
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 2 External
bJackID 4
bNrInputPins 1
baSourceID( 0) 1
BaSourcePin( 0) 1
iJack 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
MIDIStreaming Endpoint Descriptor:
bLength 5
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 1
baAssocJackID( 0) 1
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
MIDIStreaming Endpoint Descriptor:
bLength 5
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 1
baAssocJackID( 0) 3
Device Status: 0x0002
(Bus Powered)
Remote Wakeup Enabled
Mike
2015-07-30 22:37:11 UTC
Permalink
Post by w***@gmail.com
Last time I've bought a USB MIDI keyboard Miditech Garagekey Mini
http://www.miditech.de/211-produkte-i2-garage-key-mini
when I boot the Linux O/S, it works only when gets connected after the system is fully started.
If the device is connected before the computer is switched on, it is recognized correctly, and reported by lsusb correctly, but it does not send any MIDI messages.
Are you using udev? (Or some similar device managing technology?)

I have a MIDI port device like that, that is a USB paperweight until it gets
some firmware kicked into it.

Yes it showed up on lsusb, but didn't actually WORK.

It took a bit of fiddling about to get it to work at bootup AND on reconnect,
but it was all down to not having the correct udev rules and support to force the
firmware blob into it.

It always worked if you booted Windows and then soft-booted into to Linux, as
the firmware was already in.

Cold PC power up and straight into Linux: No firmware, no work.

Was working, disconnect USB and reconnect in Linux: Lost power, no firmware,
no work.

In the end I needed to add "fxload" to my system, and a udev rule, then
the device worked under all conditions.

Maybe that's where you're failing -- the udev rule (or similar) isn't firing
for the device when it's discovered at bootup, only on a reconnect.
--
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk

--- news://freenews.netfront.net/ - complaints: ***@netfront.net ---
w***@gmail.com
2015-07-30 23:35:00 UTC
Permalink
Post by Mike
Post by w***@gmail.com
Last time I've bought a USB MIDI keyboard Miditech Garagekey Mini
http://www.miditech.de/211-produkte-i2-garage-key-mini
when I boot the Linux O/S, it works only when gets connected after the system is fully started.
If the device is connected before the computer is switched on, it is recognized correctly, and reported by lsusb correctly, but it does not send any MIDI messages.
Are you using udev? (Or some similar device managing technology?)
Yes of course. This is a standard Debian/testing system, so udev is installed.
Post by Mike
I have a MIDI port device like that, that is a USB paperweight until it gets
some firmware kicked into it.
Yes it showed up on lsusb, but didn't actually WORK.
It took a bit of fiddling about to get it to work at bootup AND on reconnect,
but it was all down to not having the correct udev rules and support to force the
firmware blob into it.
It always worked if you booted Windows and then soft-booted into to Linux, as
the firmware was already in.
Cold PC power up and straight into Linux: No firmware, no work.
Was working, disconnect USB and reconnect in Linux: Lost power, no firmware,
no work.
In the end I needed to add "fxload" to my system, and a udev rule, then
the device worked under all conditions.
Maybe that's where you're failing -- the udev rule (or similar) isn't firing
for the device when it's discovered at bootup, only on a reconnect.
No. The problem is not related to firmware loading.
The device works perfectly if I power up the machine booting Linux (no Windows booted previously), and then I connect the MIDI keyboard.

However when I connect the keyboard to the switched off computer, and then power it up booting Linux it doesn't work.

The device also doesn't use any firmware blob.
I have even tried to reset the USB device by calling
ioctl(fd, USBDEVFS_RESET, 0);
(as described here: http://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line )

I have tried manual unbinding and rebinding the driver:
https://lwn.net/Articles/143397/

None of the above helped.

Thanks & regards,
WZab
Henrik Carlqvist
2015-07-31 08:25:03 UTC
Permalink
Post by w***@gmail.com
The device works perfectly if I power up the machine booting Linux (no
Windows booted previously), and then I connect the MIDI keyboard.
However when I connect the keyboard to the switched off computer, and
then power it up booting Linux it doesn't work.
When you get a working keyboard after connecting it after the machine has
booted, do you find any keyboard related messages at the end of the
output of dmesg? If so, is it possible to find exactly the same, or maybe
only a part of those messages somewhere in the output of dmesg without a
working keyboard when booted with keyboard connected at power on?

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
***@localhost ***@localhost
w***@gmail.com
2015-07-31 09:48:30 UTC
Permalink
Post by Henrik Carlqvist
Post by w***@gmail.com
The device works perfectly if I power up the machine booting Linux (no
Windows booted previously), and then I connect the MIDI keyboard.
However when I connect the keyboard to the switched off computer, and
then power it up booting Linux it doesn't work.
When you get a working keyboard after connecting it after the machine has
booted, do you find any keyboard related messages at the end of the
output of dmesg? If so, is it possible to find exactly the same, or maybe
only a part of those messages somewhere in the output of dmesg without a
working keyboard when booted with keyboard connected at power on?
In both cases the dmesg contains the same messages:
[ 2.570488] usb 3-7: New USB device found, idVendor=1acc, idProduct=1a0f
[ 2.570489] usb 3-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.570490] usb 3-7: Product: GarageKey mini
[ 2.570491] usb 3-7: Manufacturer: miditech
[ 2.570492] usb 3-7: SerialNumber: miditech-97-1A0F-XXXXXXXX-miniG

I have even blacklisted the snd-usb-audio module to avoid its loading during the powerup, to load it later on manually.
This also didn't cure the problem...

I suspected that it may be a problem related with the timing during powering up of the device, but the same problem should then appear in Windows...

Thanks & Regards,
Wojtek
Henrik Carlqvist
2015-07-31 14:40:28 UTC
Permalink
Post by w***@gmail.com
In both cases the dmesg contains the same messages
What about the output of lsmod? Does it differ?

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
***@localhost ***@localhost
w***@gmail.com
2015-07-31 21:37:10 UTC
Permalink
Post by Henrik Carlqvist
Post by w***@gmail.com
In both cases the dmesg contains the same messages
What about the output of lsmod? Does it differ?
This is output from my simple sythesizer based on Odroid C1 board:

When system is booted with GarageKey connected:

***@odroid:~# lsmod
Module Size Used by
snd_usb_audio 121702 0
snd_hwdep 5788 1 snd_usb_audio
snd_usbmidi_lib 17199 1 snd_usb_audio
snd_seq_oss 30070 0
snd_seq_midi 4678 0
snd_seq_midi_event 5819 2 snd_seq_oss,snd_seq_midi
snd_seq 51023 5 snd_seq_midi_event,snd_seq_oss,snd_seq_midi
snd_rawmidi 19419 2 snd_usbmidi_lib,snd_seq_midi
snd_seq_device 5964 4 snd_seq,snd_rawmidi,snd_seq_oss,snd_seq_midi
w1_gpio 3287 0
wire 20827 1 w1_gpio
fuse 70879 0
nls_cp437 5125 1

***@odroid:~# amidi -l
Dir Device Name
IO hw:2,0,0 GarageKey mini MIDI 1
***@odroid:~# amidi -d -p hw:2,0,0
6D

and then nothing, pressing the keys in the MIDI keyboard does not produce any output

Then I disconnect and reconnect the GarageKey. The output looks as below:
***@odroid:~# lsmod
Module Size Used by
snd_usb_audio 121702 0
snd_hwdep 5788 1 snd_usb_audio
snd_usbmidi_lib 17199 1 snd_usb_audio
snd_seq_oss 30070 0
snd_seq_midi 4678 0
snd_seq_midi_event 5819 2 snd_seq_oss,snd_seq_midi
snd_seq 51023 5 snd_seq_midi_event,snd_seq_oss,snd_seq_midi
snd_rawmidi 19419 2 snd_usbmidi_lib,snd_seq_midi
snd_seq_device 5964 4 snd_seq,snd_rawmidi,snd_seq_oss,snd_seq_midi
w1_gpio 3287 0
wire 20827 1 w1_gpio
fuse 70879 0
nls_cp437 5125 1

***@odroid:~# amidi -l
Dir Device Name
IO hw:2,0,0 GarageKey mini MIDI 1

***@odroid:~# amidi -d -p hw:2,0,0

6D
90 34 11
80 34 00
90 37 13
80 37 00
90 39 36
80 39 00
90 3B 32
80 3B 00

So there is absolutely no difference, except that in the second case the device
is working.
The interesting thing in case of the Odroid C1 board, is that rebooting of
the board sometimes causes the GarageKey to operate correctly.
And after it happens, further reboots do not cause the keyboard to stop
working.
The strange thing is that the device in Windows works reliably...

Regards,
Wojtek
Henrik Carlqvist
2015-08-01 08:53:43 UTC
Permalink
Unfortunately I am not very familiar with midi hardware. I first thought
that the GarageKey was connected by USB and that connecting it to your
computer would cause udev to load some modules.

But where does this Odroid C1 board come into the picture? Is the
GarageKey connected to the Odroid C1 board? If so, I would guess that the
driver used for Odroid C1 does not behave as wanted.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
***@localhost ***@localhost
w***@gmail.com
2015-08-01 12:29:38 UTC
Permalink
Post by Henrik Carlqvist
Unfortunately I am not very familiar with midi hardware. I first thought
that the GarageKey was connected by USB and that connecting it to your
computer would cause udev to load some modules.
But where does this Odroid C1 board come into the picture? Is the
GarageKey connected to the Odroid C1 board? If so, I would guess that the
driver used for Odroid C1 does not behave as wanted.
First tests were done in my Linux DAW which runs under debian/testing.
However it is the full fledged system which loads multiple modules.
Therefore when you asked if there is any difference in the lsmod output,
I have selected another, more "sterile" environment. Which is a simple
portable MIDI synthesizer, which is based on the Odroid C1 board running Ubuntu.

So: The problem occures in three different systems:
1. Debian/testing running on stationary DAW
2. Debian/testing running on laptop (Dell Vostro 3750)
3. Ubuntu 14.04.2 LTS (GNU/Linux 3.10.70-74 armv7l) running on Odroid C1

In all above systems the GarageKey keybord does not respond to pressing keys,
when system is booted with keyboard connected.
The endpoint 0 works, as device gets enumerated and recognized.
When I run "amidi -l" I get the device MIDI port (e.g. like below):
$ amidi -l
Dir Device Name
IO hw:2,0,0 GarageKey mini MIDI 1
And when I later on run
$ amidi -d -p h2:2,0,0

I either get no output at all, or just a single 0x6D

In all above systems hot disconnecting and reconnecting of the keyboard fixes
the problem (in the Odroid C1, once (for ca. 100 tests) the device still was not working after dis/reconnection.

Only in the Odroid C1 board, rebooting the system with the keyboard connected usually fixes the problem.

The device is always recognized in the same way, so it is not a problem with incorrect reading of descriptors.
Also the same set of drivers is loaded in the same order.
The device does not use any firmware blob.

BTW. My Odroid C1 based synthesizer starts the script shown below from the /etc/rc.local:

#!/bin/sh
(
/usr/sbin/rtkitctl --start
/bin/sleep 10
if [ -n "` aconnect -i | grep Xboard49 `" ] ; then
su -c "/usr/bin/yoshimi -a -Ahw:1,0 -i -l /home/odroid/synth/wzab.xmz" odroid &
/bin/sleep 8
/usr/bin/python /home/odroid/synth/router_xboard.py &
elif [ -n "` aconnect -i | grep LPK25 `" ] ; then
strace /usr/bin/yoshimi -a -Ahw:1,0 -i -l /home/odroid/synth/wzab.xmz &
/bin/sleep 8
/usr/bin/python /home/odroid/synth/router_lpk25.py &
fi
exit 0
)

where for example the MIDI routing script for Xboard 49 is defined as follows:

# cat /home/odroid/synth/router_xboard.py
from mididings import *
config (
backend='alsa',
client_name='xboard_router',
out_ports=[('synth','yoshimi.*'),],
in_ports=[('xboard','.*Xboard49.*'),],
)

run(
Velocity(curve=1)
)

The /home/odroid/synth/wzab.xmz is the Yoshhimi configuration
generated using the Yoshimi's GUI (e.g. after logging
via "ssh -X" to the synthesizer.

Regards,
Wojtek
Henrik Carlqvist
2015-08-01 14:51:12 UTC
Permalink
Post by w***@gmail.com
1. Debian/testing running on stationary DAW
2. Debian/testing running on laptop (Dell Vostro 3750)
3. Ubuntu 14.04.2 LTS (GNU/Linux 3.10.70-74 armv7l) running on Odroid C1
So those are your host computers and the GarageKey is connected by USB to
the host computer.

What if you don't connect the GarageKey at all, do you find any
difference in your loaded modules? If so, that or those missing modules
might be the ones causing the unwanted behavior.

Are you really sure that the module isn't loading any firmware into the
device? Maybe the firmware isn't in a separate .fw file but built into
the module. A loaded firmware would explain why the GarageKey works even
when connected after a reboot without power off.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
***@localhost ***@localhost
w***@gmail.com
2015-08-01 15:29:51 UTC
Permalink
Post by Henrik Carlqvist
Post by w***@gmail.com
1. Debian/testing running on stationary DAW
2. Debian/testing running on laptop (Dell Vostro 3750)
3. Ubuntu 14.04.2 LTS (GNU/Linux 3.10.70-74 armv7l) running on Odroid C1
So those are your host computers and the GarageKey is connected by USB to
the host computer.
What if you don't connect the GarageKey at all, do you find any
difference in your loaded modules? If so, that or those missing modules
might be the ones causing the unwanted behavior.
Are you really sure that the module isn't loading any firmware into the
device? Maybe the firmware isn't in a separate .fw file but built into
the module. A loaded firmware would explain why the GarageKey works even
when connected after a reboot without power off.
regards Henrik
--
The problem is obviously related to the firmware of the GarrageKey.
Except of the Python based experiment described in the next message,
I've done the following:
1. With loaded snd-usb-audio, dis/reconnection of the GarrageKey results in correct operation
2. With unloaded snd-usb-audio, dis/reconnection of the GarrageKey followed by loading of snd-usb-audio results in correct operation
3. With unloaded snd-usb-audio, dis/reconnection of the GarrageKey followed by playing on the keyboard (so that the Endpoint buffer gets overflown) and then loading of snd-usb-audio results in frozen keyboard.

So the question is: how Windows is able to clear this frozen Endpoint, and why Linux is not?
w***@gmail.com
2015-08-01 15:33:58 UTC
Permalink
Post by w***@gmail.com
Post by Henrik Carlqvist
Post by w***@gmail.com
1. Debian/testing running on stationary DAW
2. Debian/testing running on laptop (Dell Vostro 3750)
3. Ubuntu 14.04.2 LTS (GNU/Linux 3.10.70-74 armv7l) running on Odroid C1
So those are your host computers and the GarageKey is connected by USB to
the host computer.
What if you don't connect the GarageKey at all, do you find any
difference in your loaded modules? If so, that or those missing modules
might be the ones causing the unwanted behavior.
Are you really sure that the module isn't loading any firmware into the
device? Maybe the firmware isn't in a separate .fw file but built into
the module. A loaded firmware would explain why the GarageKey works even
when connected after a reboot without power off.
regards Henrik
--
The problem is obviously related to the firmware of the GarrageKey.
Except of the Python based experiment described in the next message,
1. With loaded snd-usb-audio, dis/reconnection of the GarrageKey results in correct operation
2. With unloaded snd-usb-audio, dis/reconnection of the GarrageKey followed by loading of snd-usb-audio results in correct operation
3. With unloaded snd-usb-audio, dis/reconnection of the GarrageKey followed by playing on the keyboard (so that the Endpoint buffer gets overflown) and then loading of snd-usb-audio results in frozen keyboard.
So the question is: how Windows is able to clear this frozen Endpoint, and why Linux is not?
One small update. It is not the matter of the snd-usb-audio, but of amidi.
If I do not start "amidi -d -p hw:....." and play the keyboard, further starting of "amidi -d -p hw:...." shows that it got frozen.

Anyway the problem is related to the firmware, and the question is how Windows can recover state of the firmware without powering it off.

In Linux i've tried (via pyusb): dev.reset() and ep.clear_halt() without any success.

Regards,
Wojtek
w***@gmail.com
2015-08-01 17:15:34 UTC
Permalink
Post by w***@gmail.com
Post by w***@gmail.com
Post by Henrik Carlqvist
Post by w***@gmail.com
1. Debian/testing running on stationary DAW
2. Debian/testing running on laptop (Dell Vostro 3750)
3. Ubuntu 14.04.2 LTS (GNU/Linux 3.10.70-74 armv7l) running on Odroid C1
So those are your host computers and the GarageKey is connected by USB to
the host computer.
What if you don't connect the GarageKey at all, do you find any
difference in your loaded modules? If so, that or those missing modules
might be the ones causing the unwanted behavior.
Are you really sure that the module isn't loading any firmware into the
device? Maybe the firmware isn't in a separate .fw file but built into
the module. A loaded firmware would explain why the GarageKey works even
when connected after a reboot without power off.
regards Henrik
--
The problem is obviously related to the firmware of the GarrageKey.
Except of the Python based experiment described in the next message,
1. With loaded snd-usb-audio, dis/reconnection of the GarrageKey results in correct operation
2. With unloaded snd-usb-audio, dis/reconnection of the GarrageKey followed by loading of snd-usb-audio results in correct operation
3. With unloaded snd-usb-audio, dis/reconnection of the GarrageKey followed by playing on the keyboard (so that the Endpoint buffer gets overflown) and then loading of snd-usb-audio results in frozen keyboard.
So the question is: how Windows is able to clear this frozen Endpoint, and why Linux is not?
One small update. It is not the matter of the snd-usb-audio, but of amidi.
If I do not start "amidi -d -p hw:....." and play the keyboard, further starting of "amidi -d -p hw:...." shows that it got frozen.
Anyway the problem is related to the firmware, and the question is how Windows can recover state of the firmware without powering it off.
In Linux i've tried (via pyusb): dev.reset() and ep.clear_halt() without any success.
Regards,
Wojtek
Yet another update. I've made a test with device connected to my laptop.
I've booted Linux. The GarageKey entered the "frozen" state.
Then I've rebooted it into Windows (without powering off).
The situation was the same as in Linux - the device is recognized as the MIDI keyboard, but doesn't send any note on /note off commands when the user plays.

So:
1. Windows is also not able to recover the GarageKey firmware to the correct state without power cycling
2. Somehow Windows avoids overflowing of the MIDI_IN Endpoint buffer during the system booting.

Regards,
Wojtek
Henrik Carlqvist
2015-08-01 18:08:31 UTC
Permalink
Post by w***@gmail.com
2. Somehow Windows avoids overflowing of the MIDI_IN Endpoint buffer
during the system booting.
It seems as if you have narrowed it down pretty well, I hope you will be
able to solve the problem.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
***@localhost ***@localhost
w***@gmail.com
2015-08-01 18:18:57 UTC
Permalink
So finally I've got the GarageKey working with my Odroid C1 based mini synthesizer.
For more complex Linux based systems it is necessary to connect it after the system is configured.

It seems, that the problem is really caused by the fact, that GarageKey sends periodic Active Sensing messages. If they overflow the Endpoint 0x81 packet buffer, the firmware partially freezes (the device enumerates correctly, but endpoint 0x81 - MIDI IN does not send any further note on/note off messages).
In fact after "device reset" is performed, a packe with single AutoSensing message is transmitted.

So to avoid firmware malfunction, it is necessary, that something starts to receive MIDI messages from the GarageKey, before the buffer is overflown.

In my Odroid C1 based setup, this is ensured by starting the MIDI router and the yoshimi synthesizer from /etc/rc.local

In case of my Linux DAW may be it will be sufficent to start the JACK server automatically (to be investigated yet). However up to now, the boot time, and the time before the user logs in and starts the MIDI software is so long, that the GarageKey keyboard gets locked.

If anybody is interested, here are the essential files I used in my Odroid C1 synthesizer:

$ cat /home/odroid/synth/start2
#!/bin/sh
(
/usr/sbin/rtkitctl --start
/bin/sleep 10
#Find the output ALSA device
#CARDNUM=`cat /proc/asound/cards | grep : | grep bcm2835 | cut -d ' ' -f 2`
#AHW="hw:$CARDNUM,0,0"
if [ -n "` aconnect -i | grep Xboard49 `" ] ; then
su -c "/usr/bin/yoshimi -a -Ahw:1,0 -i -l /home/odroid/synth/wzab.xmz" odroid &
/bin/sleep 8
/usr/bin/python /home/odroid/synth/router_xboard.py &
elif [ -n "` aconnect -i | grep GarageKey `" ] ; then
su -c "/usr/bin/yoshimi -a -Ahw:1,0 -i -l /home/odroid/synth/wzab.xmz" odroid &
/bin/sleep 8
/usr/bin/python /home/odroid/synth/router_garagekey.py &
elif [ -n "` aconnect -i | grep LPK25 `" ] ; then
su -c "/usr/bin/yoshimi -a -Ahw:1,0 -i -l /home/odroid/synth/wzab.xmz" odroid &
/bin/sleep 8
/usr/bin/python /home/odroid/synth/router_lpk25.py &
fi
exit 0
)
# > /tmp/rep.txt 2>&1

$ cat /home/odroid/synth/router_garagekey.py
from mididings import *
config (
backend='alsa',
client_name='xboard_router',
out_ports=[('synth','yoshimi.*'),],
in_ports=[('xboard','.*GarageKey.*'),],
)

run(
Velocity(curve=1)
)

The /home/odroid/synth/wzab.xmz is a Yoshimi setup generated with GUI and saved in a xmz format.

With best regards,
Wojtek

PS. I have notified the Miditech support about the issue, let's see if they
find a reasonable workaround or fix the firmware.
I think, that in certain conditions the problem may also affect operation of the GarageKey in Windows :-(.
Henrik Carlqvist
2015-08-01 20:24:02 UTC
Permalink
Post by w***@gmail.com
So to avoid firmware malfunction, it is necessary, that something starts
to receive MIDI messages from the GarageKey, before the buffer is
overflown.
PS. I have notified the Miditech support about the issue,
Good work, problem solved!

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
***@localhost ***@localhost
Mike
2015-07-31 22:09:26 UTC
Permalink
[ 2.570488] usb 3-7: New USB device found, idVendor=3D1acc, idProduct=3D=
1a0f
[ 2.570489] usb 3-7: New USB device strings: Mfr=3D1, Product=3D2, Seria=
lNumber=3D3
[ 2.570490] usb 3-7: Product: GarageKey mini
[ 2.570491] usb 3-7: Manufacturer: miditech
[ 2.570492] usb 3-7: SerialNumber: miditech-97-1A0F-XXXXXXXX-miniG
Do you end up with more than one midi device on your system?

e.g. /dev/midi0 /dev/midi1 ...

because something else is hijacking the /dev/midi you expect it to turn
up as? Could that be the difference?
--
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk

--- news://freenews.netfront.net/ - complaints: ***@netfront.net ---
w***@gmail.com
2015-08-01 00:10:11 UTC
Permalink
No, each time I have verified, that I'm trying to receive from the proper device (those "amidi -l" calls).
In most tests it was the only MIDI input device.
Of course to verify that the whole setup works correctly, I have connected also other keybords: akai lpk25 and xboard 49.
Only GarageKey had problems.
It seems that it is sensitive to certain subtle differrence between USB initialization in Windows and in Linux.

Regards,
Wojtek
w***@gmail.com
2015-08-01 14:31:39 UTC
Permalink
I have written a simple Python script (used in a system with blacklisted
snd-usb-audio driver), which allows me to compare LPK25 and GarageKey behaviours.


import usb
dev = usb.core.find(idVendor=0x1acc, idProduct=0x1a0f)
cfg = dev.get_active_configuration()
intf = cfg[(1,0)]
ep = usb.util.find_descriptor(intf,custom_match = \
lambda e: \
usb.util.endpoint_direction(e.bEndpointAddress) == \
usb.util.ENDPOINT_IN)

Then I can run
b=dev.read(ep,64,10000); print [hex(i) for i in b]
To check what packets are transmitted by both keyboards.
b=dev.read(ep,64,10000); print [hex(i) for i in b]
['0xf', '0xfe', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0']
Then each execution of the above line ends with timeout. Until I reset the device with dev.reset()
dev.reset()
b=dev.read(ep,64,10000); print [hex(i) for i in b]
['0xf', '0xfe', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0']
b=dev.read(ep,64,10000); print [hex(i) for i in b]
['0x8', '0x81', '0x39', '0x7f', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0']
b=dev.read(ep,64,10000); print [hex(i) for i in b]
['0x9', '0x91', '0x35', '0x55', '0x8', '0x81', '0x35', '0x7f', '0x9', '0x91', '0x35', '0x3c', '0x8', '0x81', '0x35', '0x7f', '0x9', '0x91', '0x30', '0x69', '0x8', '0x81', '0x30', '0x7f', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0']
b=dev.read(ep,64,10000); print [hex(i) for i in b]
['0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0']
b=dev.read(ep,64,10000); print [hex(i) for i in b]
['0xf', '0xfe', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0']
b=dev.read(ep,64,10000); print [hex(i) for i in b]
['0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0']
b=dev.read(ep,64,10000); print [hex(i) for i in b]
['0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0xf', '0xfe', '0x0', '0x0', '0x9', '0x90', '0x30', '0x49', '0xf', '0xfe', '0x0', '0x0', '0x8', '0x80', '0x30', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0', '0x0']

The 0xfe is the ActiveSensing command ( http://www.midi.org/techspecs/midimessages.php ):

"...Active Sensing. This message is intended to be sent repeatedly to tell the receiver that a connection is alive. Use of this message is optional. When initially received, the receiver will expect to receive another Active Sensing message each 300ms (max), and if it does not then it will assume that the connection has been terminated. At termination, the receiver will turn off all voices and return to normal (non- active sensing) operation. ..."

However I don't know if it is in any way associated with the strange behaviour of the device...
w***@gmail.com
2015-08-01 14:32:44 UTC
Permalink
Post by w***@gmail.com
I have written a simple Python script (used in a system with blacklisted
snd-usb-audio driver), which allows me to compare LPK25 and GarageKey behaviours.
import usb
dev = usb.core.find(idVendor=0x1acc, idProduct=0x1a0f)
Of course in case of the LPK25 the above line is:

dev = usb.core.find(idVendor=0x09e8, idProduct=0x0076)
w***@gmail.com
2015-08-01 15:17:19 UTC
Permalink
With my Python code I have discovered, that the problem occures, if the endpoint buffer in the GarrageKey gets completely filled (I've triggered it by delaying the calls to dev.read).
If I do not read data from the 0x81 endpoint, and the amount of accumulated data
is above 64 bytes, the device enters that state.
So the question is why Windows is able to clear this problem, while Linux is not.

I have tried to call ep.clear_halt, but it ends with USBError: [Errno None] Other error
b***@gmail.com
2015-08-10 20:31:10 UTC
Permalink
It's offtopic but I simply can't make it work with my Ubuntu 14.04

Can you give me some advice please?

Thank you very much,
Csongor
w***@gmail.com
2015-08-11 12:52:03 UTC
Permalink
Post by b***@gmail.com
It's offtopic but I simply can't make it work with my Ubuntu 14.04
Can you give me some advice please?
Thank you very much,
Csongor
I assume, that you have installed "amidi" utility. If not, please install the approriate package (in debian "alsa-utils").
Connect the GarageKey to the running system, run the terminal (konsole).
Afterwards please run "amidi -l", it shoudl display something like this:
$ amidi -l
Dir Device Name
IO hw:2,0,0 GarageKey mini MIDI 1
So it means that GarageKey is recognized as hw:2,0,0 device

Then run (of course you may need to replace "hw:2,0,0" with "hw:1,0,0" or with another ID reported by "amidi -l")

$ amidi -d -p hw:2,0,0
It may display single "6D" byte right after starting (sometimes it doesn't).
When yo press and realease keys on the GarageKey, amidi should dump MIDI messages:
90 4A 67
80 4A 00
90 45 34
90 47 13
80 47 00
80 45 00
90 4F 5A
80 4F 00
90 4C 5A

Please note, that if you wait too long, the GarageKey gets locked due to the firmware bug I have described in previous posts. In this case disconnect it and reconnect again, and repeat both steps described above.

If you get MIDI messages dumped as shown above, it means that GarageKey is working. So now you should start jack (e.g. with qjackctl), start your favorite synthesizer and so on. Please read the jack related documentation to learn how to do it ( http://jackaudio.org/ )

Please note, that GarageKey gets locked quite soon if nothing receives MIDI messages from it. So I'd suggest to start jack first and only after that to connect GarageKey.

If you can suggest Miditech to fix their firmware so that it does not get locked when MIDI messages are not received, it may also be good.
I've send them a report, but it would be good if they see that there is not only a single person affected by that problem...
b***@gmail.com
2015-08-11 13:29:39 UTC
Permalink
Thank you very much,


it helped a lot ... especially the amidi -d -p hw:2,0,0 command and to know that the controller hangs after a while ...

still no sound with jack, fluidsynth and qsynth but probably that's another issue not suitable for this forum.

Thank again,
Csongor
b***@gmail.com
2015-08-11 14:08:16 UTC
Permalink
BTW I made it to work with qjackctl and qsynth

The previous problem was pulseaudio. I though I've killed it but it was respawn in the background.

Also Qsynth and QjackCtl is easy to use. No config just connect the midi to the synth with QjackCtl.

Forget the cli just start qsynth then qjackctl and make the connection.
w***@gmail.com
2015-08-12 09:32:27 UTC
Permalink
Post by b***@gmail.com
Thank you very much,
it helped a lot ... especially the amidi -d -p hw:2,0,0 command and to know that the controller hangs after a while ...
still no sound with jack, fluidsynth and qsynth but probably that's another issue not suitable for this forum.
Thank again,
Csongor
Hi,
Of course you don't need to start amidi -d -p ....
It was just to make sure, that your GarageKey is working, and taht you don't have tha hardware problem.
After you are sure that hardware is OK, you can simply:
1. Start jackd (with qjackctl, BTW, you can configure it to kill pulseaudio when starting, however I don't have to do it in my current debian/testing setup)
2. Connect the GarageKey whan jackd is started (GarageKey should appear on the list of ALSA devices in qjacktl's "Connections" window). Jackd will receive MIDI messages, so keybord should not lock
3. Start your synthesizers (Qsynth, Zynaddsubfx or whatever)/

With best regards,
Wojtek

Loading...