13 Dec
2011
13 Dec
'11
10:31 p.m.
Greetings all;
Still trying to sort reasons why a java app can't access the midi synth in
my sound card.
From an aplaymidi -l:
[root@coyote modprobe.d]# aplaymidi -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
16:0 SB Audigy 2 Value [SB0400] Audigy MPU-401 (UART)
16:32 SB Audigy 2 Value [SB0400] Audigy MPU-401 #2
17:0 Emu10k1 WaveTable Emu10k1 Port 0
17:1 Emu10k1 WaveTable Emu10k1 Port 1
17:2 Emu10k1 WaveTable Emu10k1 Port 2
17:3 Emu10k1 WaveTable Emu10k1 Port 3
Can I make the inference that a .mid file sent to 14:0 should find its way
to one of the 17:n ports? It only works if I -s to 17:0(thru 3)
Java, by its scanning methods, finds a huge list of ports, but only the
semi-broken, internal to java, synth actually makes a noise.
If I switch to amidi -l, the list is a bit shorter:
Dir Device Name
IO hw:0,0 Audigy MPU-401 (UART)
IO hw:0,1 Audigy MPU-401 #2
IO hw:0,2 Emu10k1 Synth MIDI (16 subdevices)
IO hw:0,3 Emu10k1 Synth MIDI (16 subdevices)
but sending a midi file to the latter pair, while taking the normal play
time for the file, is also silent. KMix gain is turned up quite a ways.
From the lengthy output of amixer contents:
numid=7,iface=MIXER,name='Synth Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=100,step=0
: values=72,72
| dBscale-min=-40.00dB,step=0.40dB,mute=1
But since aplaymidi works, I'm confused, does mute=1 mean it is live, not
off?
When java scans for synths, I get at the end of the listing, a
realtime_synth as device #68 in base 0. But I haven't a clue if that is
the audigy2's synths, but its silent in any event.
The target here is to somehow link this so the java system can actually use
the hardware synths in an Audigy2 Value card. But any attempt to send to a
(hw0:0) thru (hw0:3) path is silent, however aplaymidi always uses the same
amount of time to send the file.
Suggestions of what to check next?, please as I am lost in whatever
translations actually take place because there seems to be 2 different
methods of accessing a device and I can't find how they correlate.
Thank you.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
"The Amiga is the only personal computer where you can run a multitasking
operating system and get realtime performance, out of the box."
-- Peter da Silva
14 Dec
14 Dec
9:29 a.m.
gene heskett wrote:
# aplaymidi -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
16:0 SB Audigy 2 Value [SB0400] Audigy MPU-401 (UART)
16:32 SB Audigy 2 Value [SB0400] Audigy MPU-401 #2
17:0 Emu10k1 WaveTable Emu10k1 Port 0
17:1 Emu10k1 WaveTable Emu10k1 Port 1
17:2 Emu10k1 WaveTable Emu10k1 Port 2
17:3 Emu10k1 WaveTable Emu10k1 Port 3
Can I make the inference that a .mid file sent to 14:0 should find its way
to one of the 17:n ports?
Only if you have connected the output of 14:0 to one of the 17:n ports.
Java, by its scanning methods, finds a huge list of
ports, but only the
semi-broken, internal to java, synth actually makes a noise.
But does it find those sequencer ports?
If I switch to amidi -l, the list is a bit shorter:
Dir Device Name
IO hw:0,0 Audigy MPU-401 (UART)
IO hw:0,1 Audigy MPU-401 #2
IO hw:0,2 Emu10k1 Synth MIDI (16 subdevices)
IO hw:0,3 Emu10k1 Synth MIDI (16 subdevices)
but sending a midi file to the latter pair, while taking the normal play
time for the file, is also silent.
How are you trying to send a midi file to a raw MIDI port?
From the lengthy output of amixer contents:
numid=7,iface=MIXER,name='Synth Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=100,step=0
: values=72,72
| dBscale-min=-40.00dB,step=0.40dB,mute=1
does mute=1 mean it is live, not off?
In the dBscale line, it means that the minimum value would mute.
Regards,
Clemens
2:18 p.m.
On Wednesday, December 14, 2011 06:44:58 AM Clemens Ladisch did opine:
This java .jar logs to the screen that launched it, an error line for every
note in a file sent, except when the internal java synth is used. Example:
13 Dec 2011 17:28:25 WARN [dwproto-0-9 ] lhandler.DWProtocolHandler:
UNKNOWN OPCODE: 252
The opcode changes but nothing else.
For testing my hardware, aplaymidi -p client:port# song.mid
where
aplaymidi -p17:0 file.mid
works, and
aplaymidi -p14:0 file.mid
goes through the motions for the 29 second length of the file.mid, but
makes no sound.
amidi, otoh, returns (hw0:0) type answers and should be able to play a file
with the '-s song.mid' when the -p is one of
root@coyote Download]# amidi -l
Dir Device Name
IO hw:0,0 Audigy MPU-401 (UART)
IO hw:0,1 Audigy MPU-401 #2
IO hw:0,2 Emu10k1 Synth MIDI (16 subdevices)
IO hw:0,3 Emu10k1 Synth MIDI (16 subdevices)
The last 2 above.
However, I have no .syx files, whatever they are, to test with. Only .mid,
some of which are 20+ years old. They originate on a 'legacy' computer (a
TRS-80 Color Computer 3 running Ultimuse3 as .ume files, but which that
machine can convert to .mid by telling it to use a file as the output
device rather than its own hardware. The output device this old machine's
sw originally used was a bitbanger port running at midi's 31250 baud speed,
but the cpu in that machine has been changed to a slightly faster Hitachi
HD63C09EP, so that port now runs at about 37,000 baud and none of my
keyboards recognize the data.
So we now have a java app that runs on a 'server' box like this linux box,
which talks to this legacy machine at 115,000 baud using that bitbanger
port, which in turn allows the old machine to even access .dsk disk image
files as virtual disk drives by using the URL of the image, or service a
telnet client with up to 15 sessions, but one of those virtual paths is
accessed on the CoCo as /MIDI, with the .jar code then sending that .mid
style data someplace on this machine that knows what to do with midi data
when it comes up the cable. The .jar has an internal synth too, and can
feed its output to the sound card, but there are huge errors in the sound
because the 20 year old stuff is not GM. The melody line is a screaming
picolo being blown with a 175 psi air nozzle, very unpleasant.
The .jar reports a very lengthy list, 69 total, of potential places it can
send this rawmidi data, one of which I believe is equ to 14:0 above, listed
as choice "#68 realtime synth" in its pulldown, and which java somehow
expands most of into the "hw0:0" through "hw0:3" style. But in
testing,
only the internal java synth makes noise, and I believe the error is the
lack of coupling between the 14:0 port shown above, and one of the 4 ports
at 17:0 through 17:3, none of which show in an "ls -l /dev".
But:
[root@coyote johnny_cash]# ls -l /dev|grep 14,
crw-rw----+ 1 root audio 14, 14 Nov 17 21:02 admmidi
crw-rw----+ 1 root audio 14, 12 Nov 17 21:02 adsp
crw-rw----+ 1 root audio 14, 13 Nov 17 21:02 amidi
crw-rw----+ 1 root audio 14, 4 Nov 17 21:02 audio
crw-rw----+ 1 root audio 14, 9 Nov 17 21:02 dmmidi
crw-rw----+ 1 root audio 14, 3 Nov 17 21:02 dsp
crw-rw----+ 1 root audio 14, 2 Nov 17 21:02 midi
crw-rw----+ 1 root audio 14, 0 Nov 17 21:02 mixer
crw-rw----+ 1 root audio 14, 1 Nov 17 21:02 sequencer
crw-rw----+ 1 root audio 14, 8 Nov 17 21:02 sequencer2
So there seems to be a missing link, but where?
/rant on because its extremely frustrating:
IMO, linux has a huge disconnect in its handling of "devices", some of
which are shown above, but howinhell does a list like the above get
converted to a "hwN:N" format, IOW how or where is the lookup translation
table so that the user can trace this stuff himself without having to
pester several mailing lists in search of a solution.
Its a 17,000 pound bull elephant in full musk in the room that is being
seemingly ignored.
One should simply be able to use the udev generated listing above and be
done with it, for everything. Somehow, I am not grokking the concept of
how this actually works. My fault? Damnedifiknow. URL's to read
welcomed.
/rant off.
And now it looks like I'll have to reboot to restore udev, playing with
"cat file.mid >/dev/one of the devices listed above" I seem to have trashed
the majority of my audio system. Sigh.... Off to reboot after nearly 27
days uptime.
I see, thank you Clemens. I appreciate the help, a lot.
gene heskett wrote:
And how is this done?
# aplaymidi -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
16:0 SB Audigy 2 Value [SB0400] Audigy MPU-401 (UART)
16:32 SB Audigy 2 Value [SB0400] Audigy MPU-401 #2
17:0 Emu10k1 WaveTable Emu10k1 Port 0
17:1 Emu10k1 WaveTable Emu10k1 Port 1
17:2 Emu10k1 WaveTable Emu10k1 Port 2
17:3 Emu10k1 WaveTable Emu10k1 Port 3
Can I make the inference that a .mid file sent to 14:0 should find its
way to one of the 17:n ports?
Only if you have connected the output of 14:0 to one of the 17:n ports.
Java, by its
scanning methods, finds a huge list of ports, but only
the semi-broken, internal to java, synth actually makes a noise.
But does it find those sequencer ports? If I switch to
amidi -l, the list is a bit shorter:
Dir Device Name
IO hw:0,0 Audigy MPU-401 (UART)
IO hw:0,1 Audigy MPU-401 #2
IO hw:0,2 Emu10k1 Synth MIDI (16 subdevices)
IO hw:0,3 Emu10k1 Synth MIDI (16 subdevices)
but sending a midi file to the latter pair, while taking the normal
play time for the file, is also silent.
How are you trying to send a midi file to a raw MIDI port? From the
lengthy output of amixer contents:
numid=7,iface=MIXER,name='Synth Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=100,step=0
: values=72,72
:
| dBscale-min=-40.00dB,step=0.40dB,mute=1
does mute=1 mean it is live, not off?
In the dBscale line, it means that the minimum value would mute.
Regards,
Clemens
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
<KnaraKat> Bite me.
* TheOne gets some salt, then proceeds to nibble on KnaraKat a little
bit....
3:08 p.m.
On Wed, Dec 14, 2011 at 8:18 AM, gene heskett <gheskett(a)wdtv.com> wrote:
The .jar reports a very lengthy list, 69 total, of
potential places it can
send this rawmidi data, one of which I believe is equ to 14:0 above, listed
as choice "#68 realtime synth" in its pulldown, and which java somehow
expands most of into the "hw0:0" through "hw0:3" style.
This is a mistake on the part of Java or the Java app you are using,
which is hardly suprising since I've never met a Java app that did
audio/MIDI and played by the rules of the platform it was on. it
should be using sequencer ports and showing only the client name
almost all the time.
ALSA sequencer ports are not directly related to hardware in any
particular way. They can represent many different things, including
single pieces of hardware, multiple pieces of hardware or no pieces of
hardware.
only the internal java synth makes noise, and I
believe the error is the
lack of coupling between the 14:0 port shown above, and one of the 4 ports
at 17:0 through 17:3, none of which show in an "ls -l /dev".
But:
[root@coyote johnny_cash]# ls -l /dev|grep 14,
the "14" in the naming of the ALSA sequencer port has absolutely
nothing to do with major device numbers.
ALSA sequencer ports do not exist in the same namespace as devices,
since, as mentioned above, they are not restricted to devices. The way
ALSA numbers sequencer ports has always bothered me: it is arbitrary,
capricious and I've never met anyone who has seen it and not been a
bit confused by it. But ... its absolutely not related to major device
numbers.
In addition, the numbering of hw:N,m also has absolutely nothing to do
with major device numbers. If you want to know how it does map:
PCM: hw:N,m => playback: /dev/snd/pcmC{N}D{m}p
capture: /dev/snd/pcmC{N}D{m}c
read the device names as "pcm Card N Device M direction".
same for MIDI: hw:N,m => /dev/snd/midiC{N}D{m} etc
4:58 p.m.
On Wednesday, December 14, 2011 10:32:48 AM Paul Davis did opine:
Thank you!
Which here, after a reboot, shows:
[gene@coyote ~]$ ls -l /dev/snd/
total 0
drwxr-xr-x 2 root root 60 Dec 14 08:40 by-path/
crw-rw----+ 1 root audio 116, 11 Dec 14 08:40 controlC0
crw-rw----+ 1 root audio 116, 2 Dec 14 08:40 hwC0D0
crw-rw----+ 1 root audio 116, 12 Dec 14 08:41 hwC0D2
crw-rw----+ 1 root audio 116, 4 Dec 14 08:40 midiC0D0
crw-rw----+ 1 root audio 116, 3 Dec 14 08:40 midiC0D1
crw-rw----+ 1 root audio 116, 13 Dec 14 08:41 midiC0D2
crw-rw----+ 1 root audio 116, 14 Dec 14 08:41 midiC0D3
crw-rw----+ 1 root audio 116, 10 Dec 14 08:40 pcmC0D0c
crw-rw----+ 1 root audio 116, 9 Dec 14 10:32 pcmC0D0p
crw-rw----+ 1 root audio 116, 8 Dec 14 08:40 pcmC0D1c
crw-rw----+ 1 root audio 116, 7 Dec 14 08:40 pcmC0D2c
crw-rw----+ 1 root audio 116, 6 Dec 14 08:40 pcmC0D2p
crw-rw----+ 1 root audio 116, 5 Dec 14 08:40 pcmC0D3p
crw-rw----+ 1 root audio 116, 1 Dec 14 08:40 seq
crw-rw----+ 1 root audio 116, 33 Dec 14 08:40 timer
So, to which of these should java be sending the actual bytes exactly
as they would go down the midi cable to a midi capable keyboard?
And, is there a utility available that I can use to test send a file
to one of those midiC0Dn devices? My tests with cat just resulted
in a powerdown reboot to recover.
Thanks Paul. Maybe we (actually Aaron Wolfe, DriveWire4 author, as I
don't know enough java to even be dangerous) can sort this now.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
Debug is human, de-fix divine.
On Wed, Dec 14, 2011 at 8:18 AM, gene heskett
<gheskett(a)wdtv.com> wrote:
Rotsa ruck with that :)
Its a long list, but this is what that .jar spits out:
=========
DriveWire MIDI status:
Devices:
[0] Audigy2 [hw:0,0] (MidiInDevice)
SB Audigy 2 Value [SB0400], Audigy MPU-401 (UART), Audigy MPU-401 (UART), ALSA
(http://www.alsa-project.org) 1.0.23
[1] Audigy2 [hw:0,1] (MidiInDevice)
SB Audigy 2 Value [SB0400], Audigy MPU-401 #2, Audigy MPU-401 #2, ALSA
(http://www.alsa-project.org) 1.0.23
[2] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[3] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[4] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[5] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[6] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[7] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[8] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[9] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[10] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[11] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[12] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[13] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[14] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[15] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[16] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[17] Audigy2 [hw:0,2] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[18] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[19] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[20] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[21] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[22] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[23] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[24] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[25] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[26] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[27] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[28] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[29] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[30] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[31] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[32] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[33] Audigy2 [hw:0,3] (MidiInDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[34] Audigy2 [hw:0,0] (MidiOutDevice)
SB Audigy 2 Value [SB0400], Audigy MPU-401 (UART), Audigy MPU-401 (UART), ALSA
(http://www.alsa-project.org) 1.0.23
[35] Audigy2 [hw:0,1] (MidiOutDevice)
SB Audigy 2 Value [SB0400], Audigy MPU-401 #2, Audigy MPU-401 #2, ALSA
(http://www.alsa-project.org) 1.0.23
[36] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[37] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[38] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[39] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[40] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[41] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[42] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[43] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[44] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[45] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[46] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[47] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[48] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[49] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[50] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[51] Audigy2 [hw:0,2] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[52] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[53] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[54] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[55] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[56] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[57] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[58] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[59] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[60] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[61] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[62] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[63] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[64] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[65] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[66] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[67] Audigy2 [hw:0,3] (MidiOutDevice)
SB Audigy 2 Value [SB0400], VirMidi, Emu10k1 Synth MIDI, ALSA
(http://www.alsa-project.org) 1.0.23
[68] Real Time Sequencer (RealTimeSequencer)
Software sequencer, Sun Microsystems Version 1.0
[69] Java Sound Synthesizer (MixerSynth)
Software wavetable synthesizer and receiver, Sun Microsystems Version 1.0
Current MIDI output device: Java Sound Synthesizer
========
And it looks like I need to retest the #36 and #52 entries again.
The .jar reports a very lengthy list, 69 total,
of potential places it
can send this rawmidi data, one of which I believe is equ to 14:0
above, listed as choice "#68 realtime synth" in its pulldown, and
which java somehow expands most of into the "hw0:0" through "hw0:3"
style.
This is a mistake on the part of Java or the Java app you are using,
which is hardly suprising since I've never met a Java app that did
audio/MIDI and played by the rules of the platform it was on. it
should be using sequencer ports and showing only the client name
almost all the time. ALSA sequencer ports are not directly related to
hardware in any
particular way. They can represent many different things, including
single pieces of hardware, multiple pieces of hardware or no pieces of
hardware.
Just Absolutely Loverly...
only the
internal java synth makes noise, and I believe the error is
the lack of coupling between the 14:0 port shown above, and one of
the 4 ports at 17:0 through 17:3, none of which show in an "ls -l
/dev".
But:
[root@coyote johnny_cash]# ls -l /dev|grep 14,
the "14" in the naming of the ALSA sequencer port has absolutely
nothing to do with major device numbers.
ALSA sequencer ports do not exist in the same namespace as devices,
since, as mentioned above, they are not restricted to devices. The way
ALSA numbers sequencer ports has always bothered me: it is arbitrary,
capricious and I've never met anyone who has seen it and not been a
bit confused by it. But ... its absolutely not related to major device
numbers.
In addition, the numbering of hw:N,m also has absolutely nothing to do
with major device numbers. If you want to know how it does map:
PCM: hw:N,m => playback: /dev/snd/pcmC{N}D{m}pl
capture: /dev/snd/pcmC{N}D{m}c
read the device names as "pcm Card N Device M direction".
same for MIDI: hw:N,m => /dev/snd/midiC{N}D{m} etc
5:39 p.m.
On Wed, Dec 14, 2011 at 10:58 AM, gene heskett <gheskett(a)wdtv.com> wrote:
a reboot, shows:
[gene@coyote ~]$ ls -l /dev/snd/
[ ... ]
crw-rw----+ 1 root audio 116, 4 Dec 14 08:40
midiC0D0
crw-rw----+ 1 root audio 116, 3 Dec 14 08:40 midiC0D1
crw-rw----+ 1 root audio 116, 13 Dec 14 08:41 midiC0D2
crw-rw----+ 1 root audio 116, 14 Dec 14 08:41 midiC0D3
These are the only MIDI raw ports you have.
So, to which of these should java be sending the
actual bytes exactly
as they would go down the midi cable to a midi capable keyboard?
I have no idea because precisely what devices 0 through 3 are is
entirely device specific.
Here is my system:
crw-rw----+ 1 root audio 116, 10 Nov 17 12:15 /dev/snd/midiC1D0
crw-rw----+ 1 root audio 116, 9 Nov 17 12:15 /dev/snd/midiC1D1
the first one is the MIDI labelled "MIDI 1" on my Digiface I/O box,
the second one is the one labelled "MIDI 0" on the same box.
In your case, you will likely get a bit more insight by using:
aplaymidi -l
and
amidi -l
to see what names ALSA has managed to dig up and associate with each
port. the first command gives an ALSA sequencer view of things; the
second gives the raw MIDI view of things.
And, is there a utility available that I can use to
test send a file
to one of those midiC0Dn devices? My tests with cat just resulted
in a powerdown reboot to recover.
amidi will send stuff to a raw port.
5:40 p.m.
On Wed, Dec 14, 2011 at 11:39 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
the first one is the MIDI labelled "MIDI 1"
on my Digiface I/O box,
the second one is the one labelled "MIDI 0" on the same box.
^^^^^^^
MIDI 2, of course
(though, it linux, so you never know :)
6:58 p.m.
gene heskett wrote:
And, is there a utility available that I can use to
test send a file
to one of those midiC0Dn devices?
Raw MIDI devices require raw data; they're useful only for .syx files
where you don't care about timing.
Try this:
(echo -ne '\x90\x3c\x7f'; sleep 0.5; echo -ne '\x3c\x00') >
/dev/snd/midiC0D2
To get a sequencer port that your stupid Java runtime can access, load
the snd-virmidi module.
To test it, run
aseqdump -p "Virtual Raw MIDI":0
to show what gets sent to the corresponding raw MIDI port.
To actually use it, connect it to a synthesizer port:
aconnect "Virtual Raw MIDI":0 Emu10k1:0
Regards,
Clemens
8:01 p.m.
On Wednesday, December 14, 2011 12:28:24 PM Paul Davis did opine:
On Wed, Dec 14, 2011 at 10:58 AM, gene heskett
<gheskett(a)wdtv.com>
wrote:
a reboot, shows:
But those are the cable jacks, correct? Not a hardware synth input such as
this Audigy2 has once the proper drivers have been modprobe'd in and the
soundfont loaded to the card by awsfxload. So I should be using in my
case, the midiC0D2 and midiC0D3 devices from the list above? That of
course is assuming (oh oh that word again) the first 2 are the non-existent
5 pin din midi jacks...
[gene@coyote ~]$ ls -l /dev/snd/
[ ... ]
crw-rw----+ 1 root audio 116, 4 Dec 14 08:40
midiC0D0
crw-rw----+ 1 root audio 116, 3 Dec 14 08:40 midiC0D1
crw-rw----+ 1 root audio 116, 13 Dec 14 08:41 midiC0D2
crw-rw----+ 1 root audio 116, 14 Dec 14 08:41 midiC0D3
These are the only MIDI raw ports you have.
So, to which of these should java be sending the
actual bytes exactly
as they would go down the midi cable to a midi capable keyboard?
I have no idea because precisely what devices 0 through 3 are is
entirely device specific.
Here is my system:
crw-rw----+ 1 root audio 116, 10 Nov 17 12:15 /dev/snd/midiC1D0
crw-rw----+ 1 root audio 116, 9 Nov 17 12:15 /dev/snd/midiC1D1
the first one is the MIDI labelled "MIDI 1" on my Digiface I/O box,
the second one is the one labelled "MIDI 0" on the same box. In your case, you will likely get a bit more insight
by using:
These were in the last post IIRC.
aplaymidi -l
Port Client name
Port name
14:0 Midi Through Midi Through Port-0
16:0 SB Audigy 2 Value [SB0400] Audigy MPU-401 (UART) <-your
digiface jack 0?
16:32 SB Audigy 2 Value [SB0400] Audigy MPU-401 #2 <-your digiface
jack 1?
17:0 Emu10k1 WaveTable Emu10k1 Port 0
17:1 Emu10k1 WaveTable Emu10k1 Port 1
17:2 Emu10k1 WaveTable Emu10k1 Port 2
17:3 Emu10k1 WaveTable Emu10k1 Port 3
and
amidi -l
Dir Device Name
IO hw:0,0 Audigy MPU-401 (UART)
IO hw:0,1 Audigy MPU-401 #2
IO hw:0,2 Emu10k1 Synth MIDI (16 subdevices)
IO hw:0,3 Emu10k1 Synth MIDI (16 subdevices)
to see what names ALSA has managed to dig up and associate with each
port. the first command gives an ALSA sequencer view of things; the
second gives the raw MIDI view of things.
But refuses to move a .mid file, telling me to use aplaymidi instead.
Now, I know that
aplaymidi -p17:0 smas6984.mid
aplaymidi -p17:1 smas6984.mid
aplaymidi -p17:2 smas6984.mid
aplaymidi -p17:3 smas6984.mid
all work. Flawlessly. In fact I just used it to shut off a stuck note on,
it turns out that from that loooooong list of devices that java found, #36
and #52 actually do work, not at all well but they do make noise, notes are
off key, note off's are skipped, that sort of thing. And compared to the
aplaymidi sounds, the volume is down about 20db.
aplaymidi of course refuses to use the -phw0:2 style of finding its output
path, no help at all.
Now I think we need to see where the rawmidi data might be getting
scrambled. amidi says it has a "dump" option so I'll see if I can get
usable data from that. But no file to feed it exists on this box.
In the meantime, I had the old machine do a .mid output file from one of
the songs in its .ume format, then shipped the file to this machine and
played it. The only errors in that playback are instrument translation
errors because general midi hadn't arrived in any great force that far back
up the log, the bass pickers part came out as the 16 and 32 foot pedals on
a pipe organ for example. Volume level was normal too.
So that tells me the data scrambling is someplace in java if my normal
2+2=4 logic is still working. We'll hope anyway. ;-)
Thanks a bunch, Paul.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
Possessions increase to fill the space available for their storage.
-- Ryan
And, is there a utility available that I can use
to test send a file
to one of those midiC0Dn devices? My tests with cat just resulted
in a powerdown reboot to recover.
amidi will send stuff to a raw port.
8:21 p.m.
On Wednesday, December 14, 2011 02:03:14 PM Clemens Ladisch did opine:
gene heskett wrote:
Worked, gave a single half second tone.
And, is there a utility available that I can use
to test send a file
to one of those midiC0Dn devices?
Raw MIDI devices require raw data; they're useful only for .syx files
where you don't care about timing.
Try this:
(echo -ne '\x90\x3c\x7f'; sleep 0.5; echo -ne '\x3c\x00') >
/dev/snd/midiC0D2
To get a sequencer port that your stupid Java runtime can access, load
the snd-virmidi module.
Tis loaded already:
[gene@coyote midi]$ lsmod|grep snd_seq_virmidi
snd_seq_virmidi 3864 1 snd_emux_synth
snd_rawmidi 15287 4 snd_seq_midi,snd_seq_virmidi,snd_emu10k1
snd_seq_midi_event 4648 3 snd_seq_midi,snd_seq_virmidi,snd_seq_oss
snd_seq 42136 9
snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd 43189 19
snd_emux_synth,snd_seq_virmidi,snd_emu10k1,snd_rawmidi,snd_ac97_codec,snd_hwdep,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss
To test it, run
aseqdump -p "Virtual Raw MIDI":0
to show what gets sent to the corresponding raw MIDI port.
[gene@coyote midi]$ aseqdump -p "Virtual Raw MIDI":0
Invalid port Virtual Raw MIDI:0 - No such file or directory
Repeat for :1, :2, & :3
To actually use it, connect it to a synthesizer port:
aconnect "Virtual Raw MIDI":0 Emu10k1:0
Since I got the above error(s) I looked it up and did this:
aconnect -i
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 16: 'SB Audigy 2 Value [SB0400]' [type=kernel]
0 'Audigy MPU-401 (UART)'
32 'Audigy MPU-401 #2'
Which I think is telling me there is no thru port to the synth?
aconnect -o
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 16: 'SB Audigy 2 Value [SB0400]' [type=kernel]
0 'Audigy MPU-401 (UART)'
32 'Audigy MPU-401 #2'
client 17: 'Emu10k1 WaveTable' [type=kernel]
0 'Emu10k1 Port 0 '
1 'Emu10k1 Port 1 '
2 'Emu10k1 Port 2 '
3 'Emu10k1 Port 3 '
So I think I need something else yet?
Regards,
Clemens
Thanks Clemens, between you and Paul, I may actually be learning something.
:)
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
Law stands mute in the midst of arms.
-- Marcus Tullius Cicero
11:42 p.m.
gene heskett wrote:
On Wednesday, December 14, 2011 02:03:14 PM Clemens
Ladisch did opine:
No, the snd-virmidi module is not loaded.
... load the snd-virmidi module.
Tis loaded already:
$ lsmod|grep snd_seq_virmidi [...]
aconnect -i
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 16: 'SB Audigy 2 Value [SB0400]' [type=kernel]
0 'Audigy MPU-401 (UART)'
32 'Audigy MPU-401 #2'
Which I think is telling me there is no thru port to the synth?
This thru port isn't connected to anything by default.
(And you don't need it for anything you want to do.)
Regards,
Clemens
15 Dec
15 Dec
1:12 a.m.
On Wednesday, December 14, 2011 06:30:01 PM Clemens Ladisch did opine:
gene heskett wrote:
Oh, oh.
snd_virmidi is not the same as snd_seq_virmidi! My mistake, and looky
here:
aplaymidi -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
16:0 SB Audigy 2 Value [SB0400] Audigy MPU-401 (UART)
16:32 SB Audigy 2 Value [SB0400] Audigy MPU-401 #2
17:0 Emu10k1 WaveTable Emu10k1 Port 0
17:1 Emu10k1 WaveTable Emu10k1 Port 1
17:2 Emu10k1 WaveTable Emu10k1 Port 2
17:3 Emu10k1 WaveTable Emu10k1 Port 3
20:0 Virtual Raw MIDI 1-0 VirMIDI 1-0 (4 brand new ports!)
21:0 Virtual Raw MIDI 1-1 VirMIDI 1-1
22:0 Virtual Raw MIDI 1-2 VirMIDI 1-2
23:0 Virtual Raw MIDI 1-3 VirMIDI 1-3
and this set of tomato cans & a long string is now playing into my sound
card direct from UBox3 running on the coco in the basement, no java synth
involved. But the menu now has 64 more entries, a lot of scrolling to get
to the right one. Its #100 on the list. :)
And other than instrument miss-matches, very sweet.
Now, go put the newer .jar in & restart everything. Done.
Yup, 3.99.9 is messing it up, playing the wrong notes etc but not as bad as
before when I was using it. But after the first song in a 4 song loop, all
I am hearing is instrument miss-match, and its playing it ok on the 2nd
pass thru the first song. Playing the melody of "A whole new world", from
Aladdin using cowbells for the melody line is a new listening experience!
I'll go put one more modprobe statement in my /etc/rc.d/rc.local file and
call this usable until I learn how to translate instruments in umuse3.
Thank you both for your patience!
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
An infallible method of conciliating a tiger is to allow oneself to be
devoured.
-- Konrad Adenauer
On Wednesday, December 14, 2011 02:03:14 PM
Clemens Ladisch did opine:
No, the snd-virmidi module is not loaded.
... load the snd-virmidi module.
Tis loaded already:
$ lsmod|grep snd_seq_virmidi
4523
days inactive
4525
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
3 participants
participants (3)
-
Clemens Ladisch -
gene heskett -
Paul Davis