Re: Qsynth midi latency not low enough... what to do?
Am Sonntag, Dezember 02, 2018 10:17 CET, Alexandre Ratchov schrieb: > On Sat, Dec 01, 2018 at 01:19:00PM -0600, Adam Thompson wrote: > > PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces > > ~1/4sec delay between keypress and sound. > > > [...] > > > Is sndio(4) suitable for real-time(-ish) performance? Or do I need > > a (OS) platform that does ASIO or JACK? (I mostly play by ear so > > I'm targeting <<0.1sec latency.) > > Yes, sndiod is usable (actually designed for) low-latency usage. You > need to change the sndiod buffer size to whatever your system can > handle (depends on CPU, audio interface). I'd recommend to set in > /etc/rc.conf.local > > sndiod_flags=-z240 > > Let us know how it works. If it works, you could try -z120, that's > what I use on my machines. -z120 is a bit too much for my box, but -z240 does the trick for me. Thanks, Sebastian > > -z240 sets the block size to 240 samples, at 48000Hz sample frequency, > this corresponds to 48000Hz / 240 = 5ms block. The total end-to-end > latency is typically 3 blocks, so I'd get 5ms * 3 = 15ms. > > FWIW, for music, you shouldn't exceed few tenths of ms of latency. > > > > > Dmesg follows, just in case anyone spots anything useful in there… > > > > Hardware setup, broadly: > > * Dell Latitude E6430 laptop > > - booting in EFI mode to work around a weird bootloader bug > > * onboard azalia(4) audio (for now) using onboard speakers (for now) > > * Roland A500PRO MIDI controller, connected via USB > > * M-audio Uno USB-MIDI, nothing connected to it yet > > * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet > > - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected > > makes no difference) > > > > The "ABC" USB devices are unlikely to work with small blocks, but > there are fixes comming soon (hopefully). >
Re: Qsynth midi latency not low enough... what to do?
On Sat, Dec 01, 2018 at 01:19:00PM -0600, Adam Thompson wrote: > PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces ~1/4sec > delay between keypress and sound. > [...] > Is sndio(4) suitable for real-time(-ish) performance? Or do I need > a (OS) platform that does ASIO or JACK? (I mostly play by ear so > I'm targeting <<0.1sec latency.) Yes, sndiod is usable (actually designed for) low-latency usage. You need to change the sndiod buffer size to whatever your system can handle (depends on CPU, audio interface). I'd recommend to set in /etc/rc.conf.local sndiod_flags=-z240 Let us know how it works. If it works, you could try -z120, that's what I use on my machines. -z240 sets the block size to 240 samples, at 48000Hz sample frequency, this corresponds to 48000Hz / 240 = 5ms block. The total end-to-end latency is typically 3 blocks, so I'd get 5ms * 3 = 15ms. FWIW, for music, you shouldn't exceed few tenths of ms of latency. > > Dmesg follows, just in case anyone spots anything useful in there… > > Hardware setup, broadly: > * Dell Latitude E6430 laptop > - booting in EFI mode to work around a weird bootloader bug > * onboard azalia(4) audio (for now) using onboard speakers (for now) > * Roland A500PRO MIDI controller, connected via USB > * M-audio Uno USB-MIDI, nothing connected to it yet > * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet > - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected > makes no difference) > The "ABC" USB devices are unlikely to work with small blocks, but there are fixes comming soon (hopefully).
Re: Qsynth midi latency not low enough... what to do?
Am Samstag, Dezember 01, 2018 20:19 CET, "Adam Thompson"
schrieb:
> PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces ~1/4sec
> delay between keypress and sound.
>
> NARRATIVE:
>
> I finally got Qsynth working under Xfce (it freezes X under twm!) so I can
> control fluidsynth in a reasonably-obvious way... but I am now experiencing
> substantial latency.
good you like it, I added it only a few months ago to the ports/packages. I
haven't heard of any trouble with it, I use it
under Windowmaker, where it's just flawlessly.
> The good news is that it feels just like playing an old pneumatic or tracker
> organ, where there’s a ~0.25sec delay between keypress and sound.
> The bad news is that it feels just like playing an old pneumatic or tracker
> organ...
>
> I’m not a good enough musician to handle the roughly quarter-second delay
> when playing live. I know from many musicians that near-zero-latency from
> MIDI softsynths (even when using soundfonts) is possible... although no-one I
> know of uses OpenBSD.
>
> Is sndio(4) suitable for real-time(-ish) performance? Or do I need a (OS)
> platform that does ASIO or JACK? (I mostly play by ear so I'm targeting
> <<0.1sec latency.)
>
> If sndio core or umidi(4) support isn’t the problem, the only obvious thing
> to blame is FluidSynth... but the CPU in this laptop should be more than up
> to the task, and – again – I know this particular piece of software handles
> low-latency live performance in other configurations (i.e. on Linux, using
> JACK).
> I don't suspect Qsynth at the moment, as it only controls how fluidsynth
> launches, it doesn't put itself in the data path.
>
> Unsurprisingly, I’ve been unable to find any useful information on running
> this kind of setup under OpenBSD. But as mentioned before, I’m trying to
> avoid the (to me) insanity that is JACK.
I also use qsynth/fluidsynth, and I use midish to connect my USB midi
controller (FAME Digital KC61 I got el-cheapo on ebay)
and I also experienced bad delays as what you describe, or even worse.
However, when using fluidsynth/midish without qsynth, I see the same.
Additionally what I see, my controller has touch sensitive keys, and I can also
configure the curve of sensitivity of the keys
in the controller, but it doesn't matter how hard I hit the keys, it's nearly
impossible to get the velocity to 127.
I'm more or less absolute beginner with MIDI, and also can't compare to other
OS or setups, so first was looking in the manual
of that midi controller, only where I can change curve of velocity.
So then I checked midish, after some experiments, I found when I disable the
touch sensitivity, I can play
easily.
Also, when I disable the touch sensitivity in midish, the delay between
keypress and sound got down considerably.
That's what I have in my .midishrc:
# Disable touch sensitivity of keys
fvcurve {} (63)
If there is a better way to get the delay down I'm all ears, also at some point
in time, I'd love to get touch sensitivity
of the keys back ;)
cheers,
Sebastian
>
> Dmesg follows, just in case anyone spots anything useful in there…
>
> Hardware setup, broadly:
> * Dell Latitude E6430 laptop
> - booting in EFI mode to work around a weird bootloader bug
> * onboard azalia(4) audio (for now) using onboard speakers (for now)
> * Roland A500PRO MIDI controller, connected via USB
> * M-audio Uno USB-MIDI, nothing connected to it yet
> * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet
> - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected
> makes no difference)
>
>
> Advice / pointers gratefully accepted, including pointers to documentation or
> threads I may have missed.
>
> Thanks,
> -Adam
>
>
> Dmesg << __EOF__ (so to speak)
> OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018
>
> r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8471482368 (8079MB)
> avail mem = 8205459456 (7825MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf40 (101 entries)
> bios0: vendor Dell Inc. version "A21" date 05/08/2017
> bios0: Dell Inc. Latitude E6430
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG SSDT HPET SSDT SSDT SSDT ASF! SLIC
> BGRT SSDT
> acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3)
> USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4)
> RP06(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2193.29 MHz, 06-3a-09
> cpu0:
>
Re: Qsynth midi latency not low enough... what to do?
On Sat, Dec 01, 2018 at 01:19:00PM -0600, Adam Thompson wrote: > PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces ~1/4sec > delay between keypress and sound. > > NARRATIVE: > > I finally got Qsynth working under Xfce (it freezes X under twm!) so I can > control fluidsynth in a reasonably-obvious way... but I am now experiencing > substantial latency. > The good news is that it feels just like playing an old pneumatic or tracker > organ, where there’s a ~0.25sec delay between keypress and sound. > The bad news is that it feels just like playing an old pneumatic or tracker > organ... > > I’m not a good enough musician to handle the roughly quarter-second delay > when playing live. I know from many musicians that near-zero-latency from > MIDI softsynths (even when using soundfonts) is possible... although no-one I > know of uses OpenBSD. > > Is sndio(4) suitable for real-time(-ish) performance? Or do I need a (OS) > platform that does ASIO or JACK? (I mostly play by ear so I'm targeting > <<0.1sec latency.) > > If sndio core or umidi(4) support isn’t the problem, the only obvious thing > to blame is FluidSynth... but the CPU in this laptop should be more than up > to the task, and – again – I know this particular piece of software handles > low-latency live performance in other configurations (i.e. on Linux, using > JACK). > I don't suspect Qsynth at the moment, as it only controls how fluidsynth > launches, it doesn't put itself in the data path. > > Unsurprisingly, I’ve been unable to find any useful information on running > this kind of setup under OpenBSD. But as mentioned before, I’m trying to > avoid the (to me) insanity that is JACK. > > Dmesg follows, just in case anyone spots anything useful in there… > > Hardware setup, broadly: > * Dell Latitude E6430 laptop > - booting in EFI mode to work around a weird bootloader bug > * onboard azalia(4) audio (for now) using onboard speakers (for now) > * Roland A500PRO MIDI controller, connected via USB > * M-audio Uno USB-MIDI, nothing connected to it yet > * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet > - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected > makes no difference) > > > Advice / pointers gratefully accepted, including pointers to documentation or > threads I may have missed. > > Thanks, > -Adam > > > Dmesg << __EOF__ (so to speak) > OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018 > > r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8471482368 (8079MB) > avail mem = 8205459456 (7825MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf40 (101 entries) > bios0: vendor Dell Inc. version "A21" date 05/08/2017 > bios0: Dell Inc. Latitude E6430 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT MCFG SSDT HPET SSDT SSDT SSDT ASF! SLIC > BGRT SSDT > acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3) > USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4) > RP06(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2193.29 MHz, 06-3a-09 > 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2192.89 MHz, 06-3a-09 > 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2192.89 MHz, 06-3a-09 > cpu2: >
Qsynth midi latency not low enough... what to do?
PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces ~1/4sec delay between keypress and sound. NARRATIVE: I finally got Qsynth working under Xfce (it freezes X under twm!) so I can control fluidsynth in a reasonably-obvious way... but I am now experiencing substantial latency. The good news is that it feels just like playing an old pneumatic or tracker organ, where there’s a ~0.25sec delay between keypress and sound. The bad news is that it feels just like playing an old pneumatic or tracker organ... I’m not a good enough musician to handle the roughly quarter-second delay when playing live. I know from many musicians that near-zero-latency from MIDI softsynths (even when using soundfonts) is possible... although no-one I know of uses OpenBSD. Is sndio(4) suitable for real-time(-ish) performance? Or do I need a (OS) platform that does ASIO or JACK? (I mostly play by ear so I'm targeting <<0.1sec latency.) If sndio core or umidi(4) support isn’t the problem, the only obvious thing to blame is FluidSynth... but the CPU in this laptop should be more than up to the task, and – again – I know this particular piece of software handles low-latency live performance in other configurations (i.e. on Linux, using JACK). I don't suspect Qsynth at the moment, as it only controls how fluidsynth launches, it doesn't put itself in the data path. Unsurprisingly, I’ve been unable to find any useful information on running this kind of setup under OpenBSD. But as mentioned before, I’m trying to avoid the (to me) insanity that is JACK. Dmesg follows, just in case anyone spots anything useful in there… Hardware setup, broadly: * Dell Latitude E6430 laptop - booting in EFI mode to work around a weird bootloader bug * onboard azalia(4) audio (for now) using onboard speakers (for now) * Roland A500PRO MIDI controller, connected via USB * M-audio Uno USB-MIDI, nothing connected to it yet * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected makes no difference) Advice / pointers gratefully accepted, including pointers to documentation or threads I may have missed. Thanks, -Adam Dmesg << __EOF__ (so to speak) OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018 r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8471482368 (8079MB) avail mem = 8205459456 (7825MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf40 (101 entries) bios0: vendor Dell Inc. version "A21" date 05/08/2017 bios0: Dell Inc. Latitude E6430 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT HPET SSDT SSDT SSDT ASF! SLIC BGRT SSDT acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2193.29 MHz, 06-3a-09 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2192.89 MHz, 06-3a-09 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2192.89 MHz, 06-3a-09 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2192.89 MHz,
