FS#21031 - [fluidsynth] jack ports don't show up in qjackctl
Attached to Project:
Arch Linux
Opened by Dieter Plaetinck (Dieter_be) - Saturday, 02 October 2010, 08:50 GMT
Last edited by Ray Rashif (schivmeister) - Sunday, 17 October 2010, 11:59 GMT
Opened by Dieter Plaetinck (Dieter_be) - Saturday, 02 October 2010, 08:50 GMT
Last edited by Ray Rashif (schivmeister) - Sunday, 17 October 2010, 11:59 GMT
|
Details
$ pacman -Qi jack fluidsynth xorg-server kernel26 | grep
'Name\|Version'
Name : jack Version : 0.118.0-4 Name : fluidsynth Version : 1.1.2-2 Name : xorg-server Version : 1.9.0-1 Name : kernel26 Version : 2.6.35.7-1 jack running as (managed by qjackctl): /usr/bin/jackd -dalsa -dhw:0 -r48000 -p64 -n8 When starting fluidsynth with: fluidsynth -r 48000 -i -a jack /usr/share/soundfonts/fluidr3/FluidR3GM.SF2 Its jack output ports don't show up anymore in qjackctl. Its midi input port does show up in qjackctl. A week ago or so (~before upgrades of fluidsynth/xorg/kernel26), this still worked fine. qjackctl log: 10:47:55.689 Patchbay deactivated. 10:47:55.711 Statistics reset. 10:47:55.775 Startup script... 10:47:55.775 artsshell -q terminate 10:47:55.781 ALSA connection graph change. sh: artsshell: command not found 10:47:56.185 Startup script terminated with exit status=32512. 10:47:56.187 JACK is starting... 10:47:56.187 /usr/bin/jackd -dalsa -dhw:0 -r48000 -p64 -n8 jackd 0.118.0 Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details 10:47:56.196 JACK was started with PID=23488. Memory locking is unlimited - this is dangerous. You should probably alter the line: @audio - memlock unlimited in your /etc/limits.conf to read: @audio - memlock 771513 could not open driver .so '/usr/lib/jack/jack_firewire.so': libffado.so.2: cannot open shared object file: No such file or directory JACK compiled with System V SHM support. loading driver .. apparent rate = 48000 creating alsa driver ... hw:0|hw:0|64|8|48000|0|0|nomon|swmeter|-|32bit control device hw:0 configuring for 48000Hz, period = 64 frames (1.3 ms), buffer = 8 periods ALSA: final selected sample format for capture: 16bit little-endian ALSA: use 8 periods for capture ALSA: final selected sample format for playback: 16bit little-endian ALSA: use 8 periods for playback 10:47:56.390 ALSA connection change. 10:47:58.417 Server configuration saved to "/home/dieter/.jackdrc". 10:47:58.419 Statistics reset. 10:47:58.484 Client activated. 10:47:58.487 JACK connection change. 10:47:58.502 JACK connection graph change. 10:48:01.213 JACK connection graph change. 10:48:01.294 JACK connection change. 10:48:01.359 JACK connection graph change. 10:48:01.365 ALSA connection graph change. 10:48:01.497 ALSA connection change. 10:48:01.605 JACK connection graph change. 10:48:01.701 JACK connection change. 10:48:02.293 ALSA connection graph change. 10:48:02.305 ALSA connection change. 10:48:03.272 JACK connection graph change. 10:48:03.310 JACK connection change. 10:48:03.341 JACK connection graph change. subgraph starting at rosegarden timed out (subgraph_wait_fd=19, status = 0, state = Finished, pollret = 0 revents = 0x0) 10:48:03.366 ALSA connection graph change. 10:48:03.513 JACK connection change. 10:48:03.516 ALSA connection change. 10:48:03.993 JACK connection graph change. 10:48:05.085 JACK connection graph change. |
This task depends upon
Closed by Ray Rashif (schivmeister)
Sunday, 17 October 2010, 11:59 GMT
Reason for closing: Works for me
Sunday, 17 October 2010, 11:59 GMT
Reason for closing: Works for me
dieter@dieter-ws-a7n8x-arch ~ jack_lsp
system:capture_1
system:capture_2
system:playback_1
system:playback_2
system:playback_3
system:playback_4
system:playback_5
system:playback_6
rosegarden:master out L
rosegarden:master out R
rosegarden:record monitor out L
rosegarden:record monitor out R
rosegarden:record in 1 L
rosegarden:record in 1 R
rosegarden:record in 2 L
rosegarden:record in 2 R
It's either a kernel regression (related to hardware) or latest fluidsynth problem, since jack was last updated mid-August and no problems were reported (but of course we cannot rule it out entirely).
It'd be helpful if you could test, try and see if you are able to reproduce this with 1.1.1-2 (older build; compiled with float which was the then-default) and 1.1.2-1 (recently built with the now-default double instead of float using newer cmake build system). If you do not have their caches, then get them from http://arm.konnichi.com/search/
I had some time to test this today and conclude that fluidsynth 1.1.1 works. On my current (unreliable-for-sound) system, 1.1.2 is a hit-and-miss; on avg. 1 out of 4 times it works.
A TODO for you before we declare this as upstream:
1) Install fluidsynth 1.1.1-2 (cache or rebuild from ABS or SVN revision 71370)
2) Try to reproduce
Passing that (i.e it works; not reproducible):
3) Install fluidsynth 1.1.2-3 from [testing]
4) Try to reproduce
During all this, instead of just starting an instance, play a MIDI file:
fluidsynth -r 48000 -i -a jack -j /usr/share/soundfonts/fluidr3/FluidR3GM.SF2 $file.mid
Aside from that, I also want you to try (if your hardware supports 44.1kHz SR):
jackd -dalsa -dhw:0 -r44100 -p1024 -n3 # replace hw:0 with your hardware index
fluidsynth -r 44100 -i -a jack -j /usr/share/soundfonts/fluidr3/FluidR3GM.SF2 $file.mid
dieter@dieter-ws-a7n8x-arch lightbulb [master] fluidsynth -r 48000 -i -a jack -j /usr/share/soundfonts/fluidr3/FluidR3GM.SF2 PM1-170810.mid
FluidSynth version 1.1.1
Copyright (C) 2000-2009 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of E-mu Systems, Inc.
^C #<-- no sound plays, so after a while I ^C it
dieter@dieter-ws-a7n8x-arch lightbulb [master] fluidsynth -r 48000 -i -a jack -j /usr/share/soundfonts/fluidr3/FluidR3GM.SF2 PM1-170810.mid
FluidSynth version 1.1.1
Copyright (C) 2000-2009 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of E-mu Systems, Inc.
Segmentation fault
with 44.1kHz same problem (minus the segfault, but that's seems like an artifact/side-effect whatever)
With testing/fluidsynth-1.1.2-3 same problem, both 44.1kHz and 48kHz
subgraph starting at fluidsynth timed out (subgraph_wait_fd=9, status = 0, state = Triggered, pollret = 0 revents = 0x0)
subgraph starting at fluidsynth timed out (subgraph_wait_fd=9, status = 0, state = Triggered, pollret = 0 revents = 0x0)
1) Try 2.6.35.4-1, which was committed about 30 days ago at revision 88981 (and so falls within the working period you mentioned).
2) Failing that, go with http://aur.archlinux.org/packages.php?ID=11364 since it's pretty much a long way back. If this fails as well, then we can report upstream and hopefully they can pinpoint the root of the problem.
https://bugzilla.kernel.org/show_bug.cgi?id=16606)
I'll be trying the rt one from AUR
both 44.1kHz and 48kHz resulted in no sound and the "subgraph starting at fluidsynth (..)" messages.
(still fluidsynth 1.1.2-3 from [testing])
[1] http://sourceforge.net/apps/trac/fluidsynth/report
same problem.
jack --verbose stdout @ 44100 Hz: http://sprunge.us/gXIP
jack --verbose stdout @ 48000 Hz: http://sprunge.us/YNdK
I had again the same `subgraph starting at fluidsynth timed out` messages but those went to stderr.
http://lists.nongnu.org/archive/html/fluid-dev/2010-10/msg00011.html
Though I'm not quite sure they've got it, the new release nevertheless includes some fixes that may be related:
https://sourceforge.net/apps/trac/fluidsynth/wiki/ChangeLog1_1_3
So please test:
testing/fluidsynth-1.1.3-1
PS: 20:51 < schiv> give me 2 days and i'll fix this
:)
edit: btw, upstream changed the behaviour of -i|--no-shell in that fluidsynth will abort if there is nothing to do, i.e no MIDI file to play. So just use (from your original command):
fluidsynth -r 48000 -a jack /usr/share/soundfonts/fluidr3/FluidR3GM.SF2
And then test rosegarden.
still the same problem. fluidsynth 1.1.3-1, shows up under alsa, no jack ports.
Unfortunately, there is nothing much we can do anymore. If a non-realtime jack instance with insane buffer sizes does not work either:
jackd -R -dalsa -dhw:0 -r48000 -p2048 -n2
Then there is definitely something funny going on with the hardware. The timeout error tells me there's some sort of a catch-me-if-you-can going on between fluidsynth and jack, and this can range anywhere between an aging RTC and incompatible system software (and bless us if we can find this one out).
If you want to eliminate doubts, build jack and fluidsynth from revision control. If it works then, we have something to work on. Otherwise, we're stumped.
I'll keep this open for a while more (in case we can get someone else to reproduce this), but you should now really file a bug upstream (or continue the discussion in the mailing list). They should not be happy that there are cases where their software just refuses to work on a whim :/
In the meantime, see if you can manage with timidity. If you're not doing any MIDI recording, then up the buffers.
now it works.
I ran:
* jackd -v -dalsa -dhw:0 -r48000 -p1024 -n3
* fluidsynth -r 48000 -a jack /usr/share/soundfonts/fluidr3/FluidR3GM.SF2
which gives me the fluidsynth shell, and fluidsynths ports show up. However I can start rosegarden, connect it to fluidsynth and start playing music. and it works..
No `subgraph starting at fluidsynth timed out` messages either.