You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
(11) |
May
(36) |
Jun
(13) |
Jul
(44) |
Aug
(12) |
Sep
(40) |
Oct
(130) |
Nov
(61) |
Dec
(29) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(64) |
Feb
(40) |
Mar
(41) |
Apr
(63) |
May
(76) |
Jun
(121) |
Jul
(123) |
Aug
(60) |
Sep
(74) |
Oct
(160) |
Nov
(82) |
Dec
(57) |
2009 |
Jan
(78) |
Feb
(72) |
Mar
(105) |
Apr
(62) |
May
(52) |
Jun
(55) |
Jul
(28) |
Aug
(14) |
Sep
(77) |
Oct
(48) |
Nov
(104) |
Dec
(47) |
2010 |
Jan
(53) |
Feb
(57) |
Mar
(32) |
Apr
(25) |
May
(71) |
Jun
(29) |
Jul
(34) |
Aug
(48) |
Sep
(28) |
Oct
(87) |
Nov
(29) |
Dec
(55) |
2011 |
Jan
(85) |
Feb
(84) |
Mar
(127) |
Apr
(27) |
May
(16) |
Jun
(53) |
Jul
(89) |
Aug
(36) |
Sep
(22) |
Oct
(15) |
Nov
(17) |
Dec
(35) |
2012 |
Jan
(57) |
Feb
(20) |
Mar
(63) |
Apr
(55) |
May
(115) |
Jun
(14) |
Jul
(61) |
Aug
(36) |
Sep
(97) |
Oct
(37) |
Nov
(39) |
Dec
(91) |
2013 |
Jan
(75) |
Feb
(37) |
Mar
(92) |
Apr
(45) |
May
(93) |
Jun
(15) |
Jul
(25) |
Aug
(99) |
Sep
(50) |
Oct
(117) |
Nov
(34) |
Dec
(89) |
2014 |
Jan
(77) |
Feb
(54) |
Mar
(73) |
Apr
(61) |
May
(29) |
Jun
(37) |
Jul
(17) |
Aug
(16) |
Sep
(54) |
Oct
(171) |
Nov
(13) |
Dec
(41) |
2015 |
Jan
(63) |
Feb
(34) |
Mar
(28) |
Apr
(100) |
May
(125) |
Jun
(14) |
Jul
(11) |
Aug
(16) |
Sep
(27) |
Oct
(12) |
Nov
(97) |
Dec
(31) |
2016 |
Jan
(43) |
Feb
(39) |
Mar
(20) |
Apr
(58) |
May
(114) |
Jun
(45) |
Jul
(37) |
Aug
(137) |
Sep
(8) |
Oct
(14) |
Nov
(24) |
Dec
(37) |
2017 |
Jan
(133) |
Feb
(53) |
Mar
(63) |
Apr
(53) |
May
(44) |
Jun
|
Jul
(14) |
Aug
(25) |
Sep
(19) |
Oct
|
Nov
(6) |
Dec
(21) |
2018 |
Jan
(58) |
Feb
(8) |
Mar
(14) |
Apr
(2) |
May
(13) |
Jun
(7) |
Jul
(16) |
Aug
(31) |
Sep
(5) |
Oct
|
Nov
(22) |
Dec
(37) |
2019 |
Jan
|
Feb
(5) |
Mar
(8) |
Apr
|
May
(5) |
Jun
|
Jul
(16) |
Aug
|
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
2020 |
Jan
(28) |
Feb
(1) |
Mar
|
Apr
(37) |
May
(10) |
Jun
(29) |
Jul
(46) |
Aug
(11) |
Sep
(3) |
Oct
(8) |
Nov
(25) |
Dec
(6) |
2021 |
Jan
(5) |
Feb
(21) |
Mar
(17) |
Apr
(1) |
May
|
Jun
(18) |
Jul
|
Aug
|
Sep
(16) |
Oct
(23) |
Nov
(11) |
Dec
(5) |
2022 |
Jan
|
Feb
(41) |
Mar
(9) |
Apr
(22) |
May
(13) |
Jun
(6) |
Jul
(4) |
Aug
(11) |
Sep
|
Oct
|
Nov
(1) |
Dec
(3) |
2023 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(2) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2024 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Roy <ap...@vi...> - 2022-02-15 23:23:29
|
I spoke too soon. Sometimes Qjackctl does not connect, though FFADO mixer does start but Audacity does not see Firewire. A minute ago jack was failing, now it started. Is this normal behaviour? Roy |
From: Roy <ap...@vi...> - 2022-02-15 23:06:18
|
After adding the blacklist lines, rebooted and tried again. QJackctl: Started! Hooray. FFADO Mixer: Started! Double Hooray! Audacity connects to Firewire and monitors sound. Bravo for the team. Thanks guys! |
From: Jonathan W. <jw...@ju...> - 2022-02-15 22:48:10
|
Hi Daniel On Tue, Feb 15, 2022 at 11:21:42AM +0100, mail wrote: > When do you think that the new Version will be released? Soon - probably within the next week or so. I might give it a few days in case others have feedback about the recent changes. Regards jonathan |
From: David K. <da...@gn...> - 2022-02-15 22:42:40
|
Roy <ap...@vi...> writes: > Thanks David. Here's what I have > > blacklist ohci1394 > blacklist sbp2 > blacklist dv1394 > blacklist raw1394 > blacklist video1394 > > #blacklist firewire-ohci > #blacklist firewire-sbp2 > > So I should add blacklist lines for the 3 snd items? Likely just snd-bebob will do the trick for you since that is the loaded module. The others are for different cards of mine that work better with ffado. -- David Kastrup |
From: Jonathan W. <jw...@ju...> - 2022-02-15 22:42:36
|
On Tue, Feb 15, 2022 at 08:58:35PM +0100, David Kastrup wrote: > Roy <ap...@vi...> writes: > > > Thanks David. Is this what you are looking form=? > > : > > snd_bebob 45056 4 > > : > > Yup. Prime suspect snd_bebob . Indeed. With that module loaded the device will be unavailable for use with FFADO. Well spotted. > I have > > cat /etc/modprobe.d/blacklist-firewire.conf > : > blacklist snd-dice > blacklist snd-oxfw > blacklist snd-bebob > > #blacklist firewire-ohci > #blacklist firewire-sbp2 > > which has a lot more in it than I remember. If you haven't a > preexisting file like that, the blacklists that would definitely count > would be the three starting with snd- here: those are all Firewire > chipsets. Yes. In Roy's case, the blacklist snd-bebob would be the critical one (Roy's system doesn't have devices which utilise snd-dice or snd-oxfw as far as I can tell). I would recommend that blacklist entries only be created on an as-needs basis. I would therefore start only with the snd-bebob entry - odds are that this will resolve the problem. The name of the file used in /etc/modprobe.d/ is mostly arbitrary but it must end with ".conf". Regards jonathan |
From: Roy <ap...@vi...> - 2022-02-15 22:28:48
|
Thanks David. Here's what I have blacklist ohci1394 blacklist sbp2 blacklist dv1394 blacklist raw1394 blacklist video1394 #blacklist firewire-ohci #blacklist firewire-sbp2 So I should add blacklist lines for the 3 snd items? Cheers, Roy On 2/15/22 14:58, David Kastrup wrote: > > Yup. Prime suspect snd_bebob . > > I have > > cat /etc/modprobe.d/blacklist-firewire.conf > # Select the legacy firewire stack over the new CONFIG_FIREWIRE one. > > blacklist ohci1394 > blacklist sbp2 > blacklist dv1394 > blacklist raw1394 > blacklist video1394 > blacklist snd-dice > blacklist snd-oxfw > blacklist snd-bebob > > #blacklist firewire-ohci > #blacklist firewire-sbp2 > > which has a lot more in it than I remember. If you haven't a > preexisting file like that, the blacklists that would definitely count > would be the three starting with snd- here: those are all Firewire > chipsets. > > After putting this in there, you'll need to reboot and/or restart > services and/or modprobe -r snd-bebob once in order to get rolling. > You'll not be able to remove the module while the card is connected. > Once the blacklist is active and the module is removed, it should not > get reloaded and should not interfere with Ffado operation. > |
From: Jonathan W. <jw...@ju...> - 2022-02-15 22:23:25
|
Hi Roy On Tue, Feb 15, 2022 at 01:36:21PM -0500, Roy wrote: > The output file is attached. It doesn't look good! Thanks for sending this through. The output proves a few things: 1. Jackd can start. 2. FFADO can be loaded. 3. The lack of access to RT scheduling is not the reason why jackd fails to initialise (although it's something that will need to be addressed later for performance reasons). 4. The targetted Firewire device appears to be busy. The last point was subsequently picked up by David so I'll leave this reply at that and respond to the later posts as necessary. Regards jonathan |
From: David K. <da...@gn...> - 2022-02-15 19:58:55
|
Roy <ap...@vi...> writes: > Thanks David. Is this what you are looking form=? > > *snd_seq_dummy 16384 0 > snd_hda_codec_realtek 147456 1 > snd_hda_codec_generic 81920 1 snd_hda_codec_realtek > ledtrig_audio 16384 1 snd_hda_codec_generic > snd_hda_codec_hdmi 61440 1 > snd_hda_intel 53248 10 > snd_intel_dspcfg 28672 1 snd_hda_intel > snd_intel_sdw_acpi 20480 1 snd_intel_dspcfg > snd_hda_codec 147456 4 > snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek > snd_bebob 45056 4 > snd_hda_core 94208 5 > snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek > snd_firewire_lib 45056 1 snd_bebob > snd_hwdep 16384 2 snd_hda_codec,snd_bebob > snd_pcm 118784 11 > snd_hda_codec_hdmi,snd_hda_intel,snd_firewire_lib,snd_hda_codec,snd_bebob,snd_hda_core > snd_seq_midi 20480 0 > snd_seq_midi_event 16384 1 snd_seq_midi > snd_rawmidi 36864 3 snd_seq_midi,snd_firewire_lib,snd_bebob > snd_seq 73728 3 > snd_seq_midi,snd_seq_midi_event,snd_seq_dummy > snd_seq_device 16384 3 snd_seq,snd_seq_midi,snd_rawmidi > snd_timer 40960 4 snd_seq,snd_pcm > snd 94208 33 > snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_bebob,snd_pcm,snd_rawmidi > soundcore 16384 1 snd > firewire_core 69632 23 snd_firewire_lib,firewire_ohci,snd_bebob > * Yup. Prime suspect snd_bebob . I have cat /etc/modprobe.d/blacklist-firewire.conf # Select the legacy firewire stack over the new CONFIG_FIREWIRE one. blacklist ohci1394 blacklist sbp2 blacklist dv1394 blacklist raw1394 blacklist video1394 blacklist snd-dice blacklist snd-oxfw blacklist snd-bebob #blacklist firewire-ohci #blacklist firewire-sbp2 which has a lot more in it than I remember. If you haven't a preexisting file like that, the blacklists that would definitely count would be the three starting with snd- here: those are all Firewire chipsets. After putting this in there, you'll need to reboot and/or restart services and/or modprobe -r snd-bebob once in order to get rolling. You'll not be able to remove the module while the card is connected. Once the blacklist is active and the module is removed, it should not get reloaded and should not interfere with Ffado operation. -- David Kastrup |
From: Roy <ap...@vi...> - 2022-02-15 19:35:48
|
Thanks David. Is this what you are looking form=? *snd_seq_dummy 16384 0 snd_hda_codec_realtek 147456 1 snd_hda_codec_generic 81920 1 snd_hda_codec_realtek ledtrig_audio 16384 1 snd_hda_codec_generic snd_hda_codec_hdmi 61440 1 snd_hda_intel 53248 10 snd_intel_dspcfg 28672 1 snd_hda_intel snd_intel_sdw_acpi 20480 1 snd_intel_dspcfg snd_hda_codec 147456 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek snd_bebob 45056 4 snd_hda_core 94208 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek snd_firewire_lib 45056 1 snd_bebob snd_hwdep 16384 2 snd_hda_codec,snd_bebob snd_pcm 118784 11 snd_hda_codec_hdmi,snd_hda_intel,snd_firewire_lib,snd_hda_codec,snd_bebob,snd_hda_core snd_seq_midi 20480 0 snd_seq_midi_event 16384 1 snd_seq_midi snd_rawmidi 36864 3 snd_seq_midi,snd_firewire_lib,snd_bebob snd_seq 73728 3 snd_seq_midi,snd_seq_midi_event,snd_seq_dummy snd_seq_device 16384 3 snd_seq,snd_seq_midi,snd_rawmidi snd_timer 40960 4 snd_seq,snd_pcm snd 94208 33 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_bebob,snd_pcm,snd_rawmidi soundcore 16384 1 snd firewire_core 69632 23 snd_firewire_lib,firewire_ohci,snd_bebob * |
From: David K. <da...@gn...> - 2022-02-15 18:44:30
|
Roy <ap...@vi...> writes: > Good day Jonathan, thank you for your further guidance. > > The output file is attached. It doesn't look good! > > Roy > > >> As a final test before addressing the RT thing, perhaps run >> >> jackd -v -r -d firewire -p512 -n3 -v3 >> Maybe the device is blocked by some ALSA driver? lsmod | grep snd If there is a module for your card in the list, it may need to get blacklisted to let ffado at the card. -- David Kastrup |
From: Roy <ap...@vi...> - 2022-02-15 18:36:32
|
Good day Jonathan, thank you for your further guidance. The output file is attached. It doesn't look good! Roy > As a final test before addressing the RT thing, perhaps run > > jackd -v -r -d firewire -p512 -n3 -v3 > |
From: Jonathan W. <jw...@ju...> - 2022-02-15 10:19:06
|
Hi Daniel On Sun, Feb 13, 2022 at 09:07:00PM +1030, Jonathan Woithe wrote: > Given that python 3.10 is starting to roll out now I will see about getting > a release out soon that includes at least the fixes we have identified as > necessary. I will also take a look at your crash trace-back to see it if > reveals any further locations in the code where a patch might be needed. FYI I committed what will hopefully be a fix for this problem as r2821. It will be in FFADO 2.4.5 when it's released. Regards jonathan |
From: Jonathan W. <jw...@ju...> - 2022-02-15 04:29:59
|
On Mon, Feb 14, 2022 at 11:18:08PM -0500, Roy wrote: > which jackd ==> /usr/bin/jackd That's good. I was checking to make sure that jackd wasn't an alias. I am rather puzzled as to why the "-r" option is seemingly not having an effect. Perhaps it only affects the audio threads, in which case the RT messages you're seeing are informational only. As a final test before addressing the RT thing, perhaps run jackd -v -r -d firewire -p512 -n3 -v3 and see what you get. Regards jonathan |
From: Roy <ap...@vi...> - 2022-02-15 04:18:15
|
Hi Jonathan, I shall do as you suggest. Meanwhile. which jackd ==> /usr/bin/jackd which jackdmp yields no response Roy |
From: Jonathan W. <jw...@ju...> - 2022-02-15 03:58:30
|
Hi Roy On Mon, Feb 14, 2022 at 10:36:44PM -0500, Roy wrote: > Thanks for the input. I did not find pipewire, and moreover was not able to > start it. Ok, thanks for checking. > Libavc1394-0 is installed but libavc1394-tools is not. But I gather the > latter is not a dependency. Yes, I think you are correct. > Jackd does appear to be running, or perhaps not. > > agamemn+ 64886 0.0 0.0 9148 2464 pts/0 S+ 22:30 0:00 grep > --color=auto jackd If this is the only result of the grep pipeline I sent earlier, then jackd is not running. Wht you're seeing here is the "grep" process that you ran. It matches itself because it includes the search term (jackd) as part of its command line. Hmm. I wonder why it reports a default server to be running then. > running jackd -r produces the same error as before, as it appears to be > attempting to do RT: > > Cannot create RT messagebuffer thread: Operation not permitted (1) > Retrying messagebuffer thread without RT scheduling > Messagebuffer not realtime; consider enabling RT scheduling for user > no message buffer overruns I thought that jackdmp would still attempt to run without access to RT scheduling. If that's true then these RT messages wouldn't be the reason why things weren't working. That's odd - why would it still try to do RT with the "-r" option? Maybe it's worth setting up access to RT scheduling. There is some discussion about this in the "Real-time scheduling" section of http://subversion.ffado.org/wiki/UsingJackWithFFADO Out of interest, what does which jackd and which jackdmp report? Regards jonathan |
From: Roy <ap...@vi...> - 2022-02-15 03:36:54
|
Thanks for the input. I did not find pipewire, and moreover was not able to start it. Here is the output pipewire [E][85541.842477][module-protocol-: 609 lock_socket()] server 0x5602cb2e5850: unable to lock lockfile '/run/user/1000/pipewire-0.lock': Resource temporarily unavailable (maybe another daemon is running) [E][85541.842628][ conf.c: 332 load_module()] config 0x5602cb2cb0a0: could not load mandatory module "libpipewire-module-protocol-native": Resource temporarily unavailable [E][85541.842729][ pipewire.c: 117 main()] failed to create context: Resource temporarily unavailable Libavc1394-0 is installed but libavc1394-tools is not. But I gather the latter is not a dependency. Jackd does appear to be running, or perhaps not. agamemn+ 64886 0.0 0.0 9148 2464 pts/0 S+ 22:30 0:00 grep --color=auto jackd running jackd -r produces the same error as before, as it appears to be attempting to do RT: Cannot create RT messagebuffer thread: Operation not permitted (1) Retrying messagebuffer thread without RT scheduling Messagebuffer not realtime; consider enabling RT scheduling for user no message buffer overruns |
From: Jonathan W. <jw...@ju...> - 2022-02-15 01:41:33
|
Hi David, Roy On Tue, Feb 15, 2022 at 02:10:24AM +0100, David Kastrup wrote: > Jonathan Woithe <jw...@ju...> writes: > > I don't have a whole lot of experience with jackdmp, but taking the above > > messages at face value it seems that jackd thinks there was already a jackd > > running on the system when you did the test. Is this possible? Running > > > > ps auxw | grep jackd > > > > will show it up if it's running. If there is a jackd running, could you try > > shutting it down and then trying the manual run again? If not we will need > > to work out the reason for the "`default' server already active" message. > > > > Because your manually started jackd believes there's a jackd already active > > it doesn't proceed to even try starting FFADO. > > Just to make working with audio even simpler than it already is, > depending on the configuration the new kid on the block "pipewire" may > also act as an active jackd. Ah yes. That's an excellent point. I'd forgotten about pipewire, which is starting to show up on recent distributions. It is worth checking for a running pipewire on the system and shutting it down before attempting to manually start jackd. > But then other jack clients like qjackctl should be able to see it and > talk about it. True, but the resulting system won't see FFADO-based firewire audio devices because (AFAIK) pipewire doesn't make use of libffado to provide access to them. The only firewire devices pipewire will be able to see are those accessible through alsa. If one must use FFADO on their system for one reason or another, pipewire can't be used (unless it's possible for pipewire to connect to an external jackd/ffado instance). I haven't yet had any time to investigate pipewire myself, so there may be some inaccuracies in what I have written about it. Please correct these as necessary. Regards jonathan |
From: David K. <da...@gn...> - 2022-02-15 01:10:47
|
Jonathan Woithe <jw...@ju...> writes: > I don't have a whole lot of experience with jackdmp, but taking the above > messages at face value it seems that jackd thinks there was already a jackd > running on the system when you did the test. Is this possible? Running > > ps auxw | grep jackd > > will show it up if it's running. If there is a jackd running, could you try > shutting it down and then trying the manual run again? If not we will need > to work out the reason for the "`default' server already active" message. > > Because your manually started jackd believes there's a jackd already active > it doesn't proceed to even try starting FFADO. Just to make working with audio even simpler than it already is, depending on the configuration the new kid on the block "pipewire" may also act as an active jackd. But then other jack clients like qjackctl should be able to see it and talk about it. -- David Kastrup |
From: Jonathan W. <jw...@ju...> - 2022-02-15 00:57:07
|
Hi Roy On Sun, Feb 13, 2022 at 10:02:34AM -0500, Roy wrote: > Thank you for your response. Sorry for the delay but I broke my system and > had to do a complete installation. Not a problem. > Attached are the outputs from the two tests you requested. I wonder if the > firewire kernel is at the root of the problem, although yesterday jack was > able to access the Firebox. Thanks for the output. The ffado-diag looks mostly okay. > Build time info /usr/lib/x86_64-linux-gnu/libffado/static_info.txt > : > jackd None Not having jackd at compile time is not an issue. It only affects the choice of API version offered, and for most users this is of no consequence. > libavc1394 not found I'll need to check whether the lack of this library has any effect on the resulting FFADO library. > kernel version 5.13.0-19-generic > Preempt (low latency) False > RT patched False While there may be performance limits due to the kernel not being a "Preempt" kernel, it won't prevent jackd/ffado from at least trying to work. > jackdmp 1.9.19 > Copyright 2001-2005 Paul Davis and others. > Copyright 2004-2016 Grame. > Copyright 2016-2021 Filipe Coelho. > jackdmp 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 > Cannot create RT messagebuffer thread: Operation not permitted (1) > Retrying messagebuffer thread without RT scheduling > Messagebuffer not realtime; consider enabling RT scheduling for user > no message buffer overruns > Cannot create RT messagebuffer thread: Operation not permitted (1) > Retrying messagebuffer thread without RT scheduling > Messagebuffer not realtime; consider enabling RT scheduling for user > no message buffer overruns > Cannot create RT messagebuffer thread: Operation not permitted (1) > Retrying messagebuffer thread without RT scheduling > Messagebuffer not realtime; consider enabling RT scheduling for user > no message buffer overruns The complaints about RT messagebuffer can be put to one side for now. These messages indicate that your user does not have permission to create RT threads. This will need to be addressed eventually to maximise performance, but at present things aren't getting far enough to matter. > `default' server already active > Failed to open server I don't have a whole lot of experience with jackdmp, but taking the above messages at face value it seems that jackd thinks there was already a jackd running on the system when you did the test. Is this possible? Running ps auxw | grep jackd will show it up if it's running. If there is a jackd running, could you try shutting it down and then trying the manual run again? If not we will need to work out the reason for the "`default' server already active" message. Because your manually started jackd believes there's a jackd already active it doesn't proceed to even try starting FFADO. Regards jonathan |
From: Roy <ap...@vi...> - 2022-02-13 15:03:29
|
Good day Jonathan, Thank you for your response. Sorry for the delay but I broke my system and had to do a complete installation. Attached are the outputs from the two tests you requested. I wonder if the firewire kernel is at the root of the problem, although yesterday jack was able to access the Firebox. Kind regards, Roy On 2/12/22 19:48, Jonathan Woithe wrote: > Hi Roy > > On Sat, Feb 12, 2022 at 04:47:13PM -0500, Roy Keys wrote: >> I am experiencing the problem you see in the subject line. Can the source of >> the problem be identified from the partial output of ffado-diag below? >> >> QJackCtl also produces an error. (see below) > This is interesting. It would be good if you could send through the > entire ffado-diag output. There are two types of reports in that output: > compile-time and runtime. The full output will make it easier to determine > whether the ffado-diag that you sent through is relevant. > > All that said, if libraw1394 and the others reported as "not found" really > are missing, then FFADO won't run. However, Ubuntu tracks package > dependencies, so I can't immediately see how you could have ended up with > FFADO installed without any of its dependencies. > >> QJack >> Cannot connect to server socket err = No such file or directory >> Cannot connect to server request channel >> jack server is not running or cannot be started >> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping >> unlock > This error indicates that the jackd server couldn't start but it doesn't > tell us why. Could you perhaps run > > jackd -d firewire -p512 -n3 -v3 > > in the first instance and send through the output that's produced? > > Regards > jonathan |
From: Jonathan W. <jw...@ju...> - 2022-02-13 00:48:53
|
Hi Roy On Sat, Feb 12, 2022 at 04:47:13PM -0500, Roy Keys wrote: > I am experiencing the problem you see in the subject line. Can the source of > the problem be identified from the partial output of ffado-diag below? > > QJackCtl also produces an error. (see below) This is interesting. It would be good if you could send through the entire ffado-diag output. There are two types of reports in that output: compile-time and runtime. The full output will make it easier to determine whether the ffado-diag that you sent through is relevant. All that said, if libraw1394 and the others reported as "not found" really are missing, then FFADO won't run. However, Ubuntu tracks package dependencies, so I can't immediately see how you could have ended up with FFADO installed without any of its dependencies. > QJack > Cannot connect to server socket err = No such file or directory > Cannot connect to server request channel > jack server is not running or cannot be started > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > unlock This error indicates that the jackd server couldn't start but it doesn't tell us why. Could you perhaps run jackd -d firewire -p512 -n3 -v3 in the first instance and send through the output that's produced? Regards jonathan |
From: Roy K. <ap...@vi...> - 2022-02-12 22:04:51
|
Dear friends, I am experiencing the problem you see in the subject line. Can the source of the problem be identified from the partial output of ffado-diag below? QJackCtl also produces an error. (see below) Thank you, Roy gcc /usr/bin/gcc gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0 g++ /usr/bin/g++ g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0 pyuic4 None pyuic5 None jackd /usr/bin/jackd jackdmp version 1.9.19 tmpdir /dev/shm protocol 9 pkg-config /usr/bin/pkg-config jack not found libraw1394 not found libavc1394 not found libiec61883 not found libxml++-2.6 not found dbus-1 not found Build time info /usr/lib/x86_64-linux-gnu/libffado/static_info.txt gcc /usr/bin/gcc gcc (Ubuntu 10.2.1-6ubuntu2) 10.2.1 20210121 g++ /usr/bin/g++ g++ (Ubuntu 10.2.1-6ubuntu2) 10.2.1 20210121 pyuic4 None pyuic5 /usr/bin/pyuic5 Python User Interface Compiler 5.15.2 for Qt version 5.15.2 jackd None pkg-config /usr/bin/pkg-config jack not found libraw1394 2.1.2 -lraw1394 libavc1394 not found libiec61883 1.2.0 -liec61883 -lraw1394 libxml++-2.6 2.40.1 -I/usr/include/libxml++-2.6 -I/usr/lib/x86_64-linux-gnu/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lglib-2.0 -lsigc-2.0 dbus-1 1.12.20 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -ldbus-1 QJack Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock |
From: Jonathan W. <jw...@ju...> - 2022-02-12 21:12:08
|
Hi Daniel On Sat, Feb 12, 2022 at 04:29:33PM +0100, ma...@ba... wrote: > since a few days, i am not able to open the FFADO mixer. > The window opens for a second and then closes again. Do you know what might have changed on the system between now and when it was working? > When i open via terminal, i get the following output: > [basementmedia@basementmedia ~]$ sudo ffado-mixer > QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to > '/tmp/runtime-root' > Traceback (most recent call last): > File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line > 460, in updatePanels > self.addPanel(idx) > : > File "/usr/lib/python3.10/site-packages/ffado/widgets/matrixmixer.py", > line 303, in __init__ > font.setPointSize(font.pointSize()/1.5) > TypeError: setPointSize(self, int): argument 1 has unexpected type > 'float' > Abgebrochen This looks like it's a type issue, possibly related to the use of a recent python version. > Part of the FFADO project -- www.ffado.org > Version: 2.4.4 Good to know. > I use Linux Manjaro (5.15.18-2-rt28-MANJARO) Does Linux Manjaro use python 3.10 by any chance? Regards jonathan |
From: <ma...@ba...> - 2022-02-12 15:48:22
|
Hi, since a few days, i am not able to open the FFADO mixer. The window opens for a second and then closes again. When i open via terminal, i get the following output: [basementmedia@basementmedia ~]$ sudo ffado-mixer QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line 460, in updatePanels self.addPanel(idx) File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line 339, in addPanel mixerwidget.initValues() File "/usr/lib/python3.10/site-packages/ffado/mixer/rme.py", line 441, in initValues self.inputmatrix = MatrixMixer(self.hw.servername, self.hw.basepath+"/Mixer/InputFaders", self, "Columns_are_inputs", 0x8000, self.hw.basepath+"/Mixer/InputMutes", self.hw.basepath+"/Mixer/InputInverts", True) File "/usr/lib/python3.10/site-packages/ffado/widgets/matrixmixer.py", line 1256, in __init__ self.matrix = MatrixControlView(servername, basepath, self, sliderMaxValue, mutespath, invertspath, smallFont, self.short_names_bool, "In", "Out", self.transpose) File "/usr/lib/python3.10/site-packages/ffado/widgets/matrixmixer.py", line 381, in __init__ ch = MixerChannel(i, self, self.getColName(i, self.shortname), smallFont) File "/usr/lib/python3.10/site-packages/ffado/widgets/matrixmixer.py", line 303, in __init__ font.setPointSize(font.pointSize()/1.5) TypeError: setPointSize(self, int): argument 1 has unexpected type 'float' Abgebrochen I already deinstalled and reinstalled FFADO but no change. Same fault ;-( ffado-test ListDevices gives following output: sudo ffado-test ListDevices [sudo] Passwort fuer basementmedia: ----------------------------------------------- FFADO test and diagnostic utility Part of the FFADO project -- www.ffado.org Version: 2.4.4 (C) 2008, Daniel Wagner, Pieter Palmers This program comes with ABSOLUTELY NO WARRANTY. ----------------------------------------------- === 1394 PORT 0 === Node id GUID VendorId ModelId Vendor - Model 0 0x000a350051d124f4 0x00000A35 0x00101800 RME - Fireface 800 1 0x000acd1200002cb6 0x00000ACD 0x00000000 Linux Firewire - no message buffer overruns Do you have any suggestions, what could be the problem? I use Linux Manjaro (5.15.18-2-rt28-MANJARO) Best wishes Daniel Baeuerlein |
From: Jonathan W. <jw...@ju...> - 2021-12-22 01:16:47
|
Hi all On Wed, Dec 22, 2021 at 09:14:57AM +1030, Jonathan Woithe wrote: > On Tue, Dec 21, 2021 at 11:39:12PM +0100, Wargreen wrote: > > It appear that the subversion web frontend at > > http://subversion.ffado.org/ seem down, with an error 500. > > Thanks. I'll look into it. I think the problem has now been fixed. Our web host upgraded mysql at some point, and the new version introduced a reserved word which happened to be the same as a table name used by trac ("system"). I have worked around the issue within the trac source code. Thanks again for alerting us to the problem Wargreen. Regards jonathan |