Thanks to all who replied. Now I am pretty sure it was
just a mixup of my sndiod connections.
I have a way now to make it work; the purpose of this mail
is to summarize and make sure I understand what my problem is/was.
There are two relevant devices (see dmesg at bottom;
sorry for not sharing it earlier) -
an "M-Audio Mobile Pre" via uaudio(4) and a MIDI keyboard
connected through an M-Audio MIDI-to-USB cable via umidi(4).
uaudio0 at uhub1 port 2 configuration 1 interface 0 "M Audio MobilePre" rev
1.10/1.03 addr 3
uaudio0: audio rev 1.00, 9 mixer controls
audio0 at uaudio0
umidi0 at uhub2 port 2 configuration 1 interface 1 "M-Audio USB Uno MIDI
Interface" rev 1.00/1.25 addr 2
umidi0: (genuine USB-MIDI)
umidi0: out=1, in=1
midi0 at umidi0: <USB MIDI I/F>
ugen0 at uhub2 port 2 configuration 1 "M-Audio USB Uno MIDI Interface" rev
1.00/1.25 addr 2
If I run sndiod without any other options, and launch fluidsynth,
the MIDI notes I play on the MIDI keyboard do not make it to
the running fluidsynth.
(For people who use a MIDI keyboard to play fluidsynth:
how do you do it, in current?)
Instead, this is what happens (sndiod -ddd).
Please comment if I am reading it wrong:
# sndiod -ddd
snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup
listen(/tmp/aucat/aucat0|ini): created
fluidsynth is started:
sock(sock|ini): created
sock,rmsg,widl: AUTH message
sock,rmsg,widl: HELLO message
sock,rmsg,widl: hello from <fluidsynth>, mode = 1, ver 7
sock,rmsg,widl: using snd0 pst=cfg.default, mode = 1
fluidsy0: overwritten slot 0
fluidsynth asks for an audio device:
snd0 pst=cfg: device requested
sio(rsnd/0|ini): created
snd0 pst=ini: 48000Hz, s16le, play 0:1, rec 0:1, 9 blocks of 960 frames
sock(sock|ini): processed in 39680us
fluidsynth negotiates audio parameters:
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: SETPAR message
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: playback channels 0:1 -> 0:1
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: 44100Hz sample rate, 882 frame
blocks
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: 1764 frame buffer
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: GETPAR message
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: GETPAR message
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: GETPAR message
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: START message
fluidsy0 vol=127,pst=ini,mmc=off: playing s16le -> s16le
fluidsy0 vol=127,pst=ini,mmc=off: allocated 1764/9702 fr buffers
fluidsy0 vol=127,pst=sta,mmc=off: 44100Hz, s16le, play 0:1, 2 blocks of 882
frames
fluidsy0 vol=127,pst=sta,mmc=off,rmsg,widl: building SETVOL message, vol = 127
fluidsynth connects again: what is this?
trying to connect to midithru/0?
sock(sock|ini): created
sock,rmsg,widl: AUTH message
sock,rmsg,widl: HELLO message
sock,rmsg,widl: hello from <fluidsynth>, mode = 8, ver 7
snd0 pst=ini: device started
snd0 pst=run: started
fluidsy0 vol=127,pst=run,mmc=off: attached at -7938
cmap: nch = 2, ostart = 0, onext = 0, istart = 0, inext= 0
resamp: 882/960
fluidsy0 vol=127,pst=run,mmc=off: set weight: 23170/23170
sock(sock|ini): processed in 11250us
sio(rsnd/0|ini): processed in 11450us
Now, without anything hapenning in fluidsynth:
snd0 pst=run: write blocked at cycle start
snd0 pst=run: rec hw xrun, rused = 1920/8640
snd0 pst=run: write blocked at cycle start
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
snd0 pst=run: write blocked at cycle start
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
[...]
snd0 pst=run: write blocked at cycle start
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
snd0 pst=run: write blocked at cycle start
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
snd0 pst=run: write blocked at cycle start
Here I exit fluidsynth:
midi1,rmsg,widl: BYE message
midi1,rmsg,widl: closing
sock(sock|bus): destroyed
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
snd0 pst=run: write blocked at cycle start
fluidsy0 vol=127,pst=run,mmc=off,rmsg,widl: STOP message
fluidsy0 vol=127,pst=run,mmc=off: stopping
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
snd0 pst=run: write blocked at cycle start
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
snd0 pst=run: write blocked at cycle start
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: stopped
snd0 pst=run: write blocked at cycle start
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: building STOP message
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: BYE message
fluidsy0 vol=127,pst=ini,mmc=off,rmsg,widl: closing
snd0 pst=run: device released
sock(sock|bus): destroyed
snd0 pst=run: play hw xrun, pused = 6720/8640
snd0 pst=run: rec hw xrun, rused = 1920/8640
snd0 pst=run: device stopped
snd0 pst=run: stopped, load avg = 119135 / 6179276
snd0 pst=ini: closing
snd0 pst=cfg: closed
sio(rsnd/0|bus): destroyed
sio(rsnd/0|bus): processed in 50941us
Here I exit sndiod:
^Clisten(/tmp/aucat/aucat0|bus): destroyed
snd0 pst=cfg: draining
nothing to do...
snd0 pst=cfg: deleting
Occasionaly, I also see the above
with mplayer or ffplay playing a movie.
On Apr 02 10:05:31, a...@caoua.org wrote:
> > snd0: write blocked at cycle start
> > snd0: write blocked at cycle start
>
> The device didn't accept data to play when it was supposed to;
> probably a driver bug; is this uaudio?
Yes.
> If so, you can try this
> magic rate and block size options:
>
> sndiod -r 44100 -z 2940 <your_options>
Yes; with these magic options, the above error messages disappear.
Fluidsynth can connect and disconnect repeatedly (while other clients
connect and disconnect), and the above never happens _with_fludisynth_
- thank you. However, I still occasionally see it with ffplay or
mplayer.
If this is a bug in uaudio(4), what can I do to help debug it?
(I have this M-Audio Mobile Pre, and an M-Audio Mobile MK II to test on.)
Anyway, this does not solve the original problem, which is
a different issue: the MIDI events are not getting
to the running fluidsynth.
> you could also try:
> export MIDIDEVICE=rmidi/0
> in case fluidsynth uses the "default" device.
Yes it does (see below). Making fluidsynth listen to
MIDIDEVICE=rmidi/0 results in notes being played.
> When I reroute audio in fluidsynth I'm using 'fluidsynth -o
> audio.sndio.device=...', so for MIDI 'fluidsynth -o midi.sndio.device=...'
> might work.
This works too.
midi0 is indeed the MIDI keyboard. So:
sndiod exposes "midithru/0", fluidsynth listens to it,
but nothing ever happens on midithru/0;
fluidsynth needs to listen to rmidi/0
- which happens automatically if sndiod is not running.
Right?
> > I'm suspecting that without sndiod fluidsynth connects directly to the MIDI
> > port your keyboard is connected to.
> > I think you may be missing the proper connections between your keyboard, a
> > sndio MIDI through box, and fluidsynth.
That is probably the case here.
Is there a way to tell (from sndiod debug, preferably)
to which exact midi port an application has connected?
The debug is detailed about _audio_ devices, as in
snd0 pst=cfg: device requested
sio(rsnd/0|ini): created
snd0 pst=ini: 48000Hz, s16le, play 0:1, rec 0:1, 9 blocks of 960 frames
sock(sock|ini): processed in 39680us
- is there a way to get such a detailed info
about connections (and disconnections) to the
exposed midi ports and midithru boxes?
> > e.g.: (this is on OpenBSD 5.2)
> > I run sndiod with the -M option. AFAICT this gives me a MIDI through box
> > (midithru/0).
This is supposed to happen automagically in current, right?
At least, there is no -M option to sndiod, and the manpage says
sndiod exposes MIDI thru boxes (hubs), allowing programs to
send MIDI messages to each other or to hardware MIDI ports in
a uniform way.
> > fluidsynth will automatically connect to its output.
Looking at the fluid_sndio.c patch file:
/* get the device name. if none is specified, use the default device. */
if (!fluid_settings_getstr(settings, "midi.sndio.device", &device)) {
device = NULL;
}
/* open the default hardware device. only use midi in. */
dev->hdl = mio_open(device, MIO_IN, 0);
In fluidsynth's settings, midi.sndio.device is "default".
So we are mio_open()ing "default", which by sndio(7) means
"any audio device or MIDI port".
So the reason it connects to "midithru/0"
involves some _precedence_ in the following, right?
rsnd Raw audio(4) device.
rmidi Raw midi(4) port.
snd Audio device exposed by sndiod(1).
midithru MIDI thru box created with sndiod(1).
midi MIDI port exposed by sndiod(1).
default Any audio device or MIDI port.
On Apr 02 12:54:09, s...@spacehopper.org wrote:
> > > My cases all involve sending midi messages, they're generated from a
> > > program rather than a controller, but definitely sent via sndiod to
> > > fluidsynth.
> >
> > Would you please kindly share your sndiod line?
> >
> > Do you simply start sndiod, launch fludisynth,
> > and then other apps can send midi messages to
> > (the sndio-exposed) midithru/0 and that gets
> > them to fluidsynth who plays them?
>
> Yes, this is all using default settings, I'm running sndiod as a
> system daemon with no flags, then in two terminals I run these:
>
> $ fluidsynth /usr/local/share/generaluser-gs/GeneralUser_GS.sf2
>
> $ midiplay -vv -x
>
> (midiplay -x plays an internal test file, I can also explicitly
> force the device e.g. "-f midithru/0", it works either way.)
> Does this work for you?
Yes it does. Which means fluidsynth really must be
listening to midithru/0, if that's what midiplay plays to
(it mio_open()s NULL).
Which probably means that midithru/0 as exposed by sndiod
is not interconnected with rmidi/0 (which is the keyboard);
so an application that listens to midithru/0 cannot hear
the keyboards.
> > In my mind all you have to do is use a tool (aucat/midish)
> > to connect your keyboard to the MIDI through box.
Yes.
> > aucat -M -q midithru/0 -q rmidi/0
Yes, this works.
But there should be a way to connect the output
of the MIDI keyboard (midi0) as an input to
midithru/0 (so that applications listening
to midithru/0, such as fluidsynth, can hear it)
_without_ running a separate 'aucat -M', right?
My problem is not specific to fluidsynth after all:
any other MIDI application (conecting to midithru/0)
will be interested in listening to those MIDI keyboards
(or any other MIDI HW for that matter).
Starting sndiod with '-q rmidi/0' doesn't do it - it exposes rmidi/0,
but does not connect it to the midithru/0 box
where I would like fluidsynth to find it.
Please excuse the length,
I am still new to this whole MIDI thing.
Thank you for your time
Jan
OpenBSD 5.3-current (GENERIC.MP) #55: Sun Mar 31 17:38:40 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80<clock_battery>
real mem = 1038864384 (990MB)
avail mem = 1003556864 (957MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe4410 (25 entries)
bios0: vendor Intel Corp. version "MOPNV10J.86A.0175.2010.0308.0620" date
03/08/2010
bios0: Intel Corporation D510MO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT
acpi0: wakeup devices SLPB(S4) PS2M(S4) PS2K(S4) UAR1(S4) UAR2(S4) P32_(S4)
ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) UHC1(S3) UHC2(S3) UHC3(S3)
UHC4(S3) EHCI(S3) AZAL(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.94 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: apic clock running at 168MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1683.36 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF
cpu1: 512KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1683.36 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF
cpu2: 512KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1683.36 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF
cpu3: 512KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 8 pa 0xfec00000, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
acpimcfg0 at acpi0 addr 0xf8000000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 5 (P32_)
acpiprt1 at acpi0: bus 0 (PCI0)
acpiprt2 at acpi0: bus 1 (PEX0)
acpiprt3 at acpi0: bus 2 (PEX1)
acpiprt4 at acpi0: bus 3 (PEX2)
acpiprt5 at acpi0: bus 4 (PEX3)
acpicpu0 at acpi0: C1, PSS
acpicpu1 at acpi0: C1, PSS
acpicpu2 at acpi0: C1, PSS
acpicpu3 at acpi0: C1, PSS
acpibtn0 at acpi0: SLPB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xe0000000, size 0x10000000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: apic 8 int 16
intel_overlay_map_regs partial stub
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D (0x2800),
apic 8 int 16, address 00:27:0e:07:09:9f
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: msi
pci4 at ppb3 bus 4
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 8 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 8 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 8 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 8 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 8 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe1
pci5 at ppb4 bus 5
pcib0 at pci0 dev 31 function 0 "Intel NM10 LPC" rev 0x01
ahci0 at pci0 dev 31 function 2 "Intel 82801GR AHCI" rev 0x01: msi, AHCI 1.1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD6400BPVT-0, 01.0> SCSI3 0/direct
fixed naa.50014ee25979e46a
sd0: 610480MB, 512 bytes/sector, 1250263728 sectors
sd1 at scsibus0 targ 1 lun 0: <ATA, WDC WD10TPVT-00H, 01.0> SCSI3 0/direct
fixed naa.50014ee2aed8deca
sd1: 953869MB, 512 bytes/sector, 1953525168 sectors
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 8 int 19
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-6400CL5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x4e/2: W83627THF rev 0x84
lm1 at wbsio0 port 0x290/8: W83627THF
mtrr: Pentium Pro MTRR support
umass0 at uhub0 port 5 configuration 1 interface 0 "RICOH USB2.0-FLASH Media"
rev 2.00/0.01 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd2 at scsibus1 targ 1 lun 0: <RICOH, R5U880FlashMedia, 0000> SCSI2 0/direct
removable serial.05ca1880R5U880-00003
sd2: 15614MB, 512 bytes/sector, 31978496 sectors
uhidev0 at uhub1 port 1 configuration 1 interface 0 "Genius Optical Mouse" rev
1.10/1.00 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
uaudio0 at uhub1 port 2 configuration 1 interface 0 "M Audio MobilePre" rev
1.10/1.03 addr 3
uaudio0: audio rev 1.00, 9 mixer controls
audio0 at uaudio0
umidi0 at uhub2 port 2 configuration 1 interface 1 "M-Audio USB Uno MIDI
Interface" rev 1.00/1.25 addr 2
umidi0: (genuine USB-MIDI)
umidi0: out=1, in=1
midi0 at umidi0: <USB MIDI I/F>
ugen0 at uhub2 port 2 configuration 1 "M-Audio USB Uno MIDI Interface" rev
1.00/1.25 addr 2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd2a (9dbfde9a4bdbbac7.a) swap on sd2b dump on sd2b
