|
»
Jack2 and FFADO, bug ??
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
Jack2 and FFADO, bug ??
by Tinram
::
Rate this Message:
Hi devs,
I'm running jack2 (1.9.3) with a firewire soundcard through FFADO. If I run it without realitme capability I get periodical xruns witch doesn't seem to be linked to latency... If I run it with realtime capability, it just fail like that : tinram@PcMartin:~/Son/Compil/jack-1.9.3$ jackd -R -dfirewire > jackdmp 1.9.3 > Copyright 2001-2005 Paul Davis and others. > Copyright 2004-2009 Grame. > 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 > no message buffer overruns > no message buffer overruns > JACK server starting in realtime mode with priority 10 > 02007203650: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0-1700 built Nov 4 2009 23:09:34 > firewire ERR: FFADO: Error creating virtual device > Cannot attach audio driver > no message buffer overruns > JackServer::Open() failed with -1 > no message buffer overruns > Failed to start server > > well with jack1 (0.116.2) with a 4ms latency, and jack2 is OK with realtime on my internal soudcard and with my USB console. Don't know if it's a bug or so in jack2 but it's wired. Jack output doesn't help a lot to solve this... Thanks for your help. Martin. _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Re: Jack2 and FFADO, bug ??
by Stéphane Letz
::
Rate this Message:
Le 6 nov. 2009 à 17:58, Tinram a écrit : > Hi devs, > > I'm running jack2 (1.9.3) with a firewire soundcard through FFADO. > If I run it without realitme capability I get periodical xruns witch > doesn't seem to be linked to latency... If I run it with realtime > capability, it just fail like that : > > > tinram@PcMartin:~/Son/Compil/jack-1.9.3$ jackd -R -dfirewire >> jackdmp 1.9.3 >> Copyright 2001-2005 Paul Davis and others. >> Copyright 2004-2009 Grame. >> 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 >> no message buffer overruns >> no message buffer overruns >> JACK server starting in realtime mode with priority 10 >> 02007203650: (ffado.cpp)[ 92] ffado_streaming_init: libffado >> 2.999.0-1700 built Nov 4 2009 23:09:34 >> firewire ERR: FFADO: Error creating virtual device >> Cannot attach audio driver >> no message buffer overruns >> JackServer::Open() failed with -1 >> no message buffer overruns >> Failed to start server >> >> > The problem has nothing to do with my system, I guess, because, it > runs just > well with jack1 (0.116.2) with a 4ms latency, and jack2 is OK with > realtime on my internal soudcard > and with my USB console. Don't know if it's a bug or so in jack2 but > it's wired. > Jack output doesn't help a lot to solve this... > > Thanks for your help. > Martin. Can you produce a log in "verbose" mode (-v)? jackd -v -R -dfirewire Thanks Stéphane _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Re: Jack2 and FFADO, bug ??
by Stéphane Letz
::
Rate this Message:
> Jack: JackFFADODriver::Attach fBufferSize 1024 fSampleRate 48000 > 06071389163: (ffado.cpp)[ 92] ffado_streaming_init: libffado > 2.999.0-1700 built Nov 4 2009 23:09:34 > firewire ERR: FFADO: Error creating virtual device Ok this happens in JACK2 FFADO backend line 472 and it caused by a "ffado_streaming_init" falling... I don't know exactly if JACK2 FFADO backend completely follows JACK1 FFADO backend (ppalmers wrote that code). I guess the best is now to report the issue to FFDAO developers. Thanks. Stéphane _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
|
|
|
|
|
|
Re: Jack2 and FFADO, bug ??
by Jonathan Woithe
::
Rate this Message:
Hi Martin
> I'm running jack2 (1.9.3) with a firewire soundcard through FFADO. As far as I am aware, FFADO is not targeting jack2 at present. > If I run it without realitme capability I get periodical xruns witch > doesn't seem to be linked to latency... If I run it with realtime > capability, it just fail like that : As mentioned, this *may* be due to the fact that FFADO and jack2 are not entirely happy together at present. However, others on the ffado-devel list may well have a more up-to-date view on this so I'll forward this message to that list as well for comments. Please subscribe to ffado-dvel to see the answers. :-) That's not to say that this is a ffado issue. There may well be something odd happening in jack2 which is causing this. That's for those more familiar with jack to comment on. > The problem has nothing to do with my system, I guess, because, it runs > just well with jack1 (0.116.2) with a 4ms latency, and jack2 is OK with > realtime on my internal soudcard and with my USB console. Obviously neither the built-in card or the USB interface utilises FFADO, so the FFADO+jack2 combination isn't being used in these cases. doesn't Regards jonathan _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Re: Jack2 and FFADO, bug ??
by Jonathan Woithe
::
Rate this Message:
Hi again
I just noticed this later reply. > > Ok this happens in JACK2 FFADO backend line 472 and it caused by a > > "ffado_streaming_init" falling... > > > > I don't know exactly if JACK2 FFADO backend completely follows JACK1 > > FFADO backend (ppalmers wrote that code). I guess the best is now to > > report the issue to FFDAO developers. > > I found the solution : FFADO creates (one of ??) its thread with > a priority of 16 and my limits.conf was set to: > > @audio - rtprio 16 > > so FFADO wasn't allowed to do such a thing. But it's wired that it > hasn't the same behavior on Jack1... It should be better that FFADO > uses the priority set with -Pxx from jack no ?? It's a bit more complicated than that. FFADO requires multiple threads and a very specific priority order to ensure that the right threads can always run at the correct time. The jackd "-P" argument (or the default level if "-P" isn't specified) is used as a starting point, but because multiple priority levels are needed (some above jackd's, some below) it is at best a guide. The reason for the differences between jack 1 and 2 might be due to architectual differences - the FFADO threads and their required priorities may differ between the two for that reason. As was commented earlier, Pieter Palmers (who wrote the respective backends along with most of the FFADO streaming infrastructure) would be in the best position to comment on this. > Or at least to add a priority parameter to the backend... This won't help because the FFADO thread priorities must be set relative to the jackd priorities. We certainly agree that this is a messy situation but it's at least partly due to the need to have very fine control over timing in userspace - something which is required by the needs of the interfaces. The problem will eventually be solved using an in-kernel FFADO streaming engine, but for now we've got to make use of the RT mechanism as best we can. By the way, in my experience one needs to use a priority somewhat higher than 15 for successful FFADO use. I personally use "-P60" while others use "-P70". Obviously this requires a change to limits.conf to allow these levels. The need for the high number comes about because the default level used by kernel interrupt routines (particularly in RT kernels) is 50, and jackd/FFADO needs to run above this for best results. If you encounter stability issues while running at the default jackd priority level you may want to try "-P60" or "-P70" and see if it improves things. Further discussion on this matter is probably best conducted in ffado-devel. Regards jonathan _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Re: Jack2 and FFADO, bug ??
by Stéphane Letz
::
Rate this Message:
Le 7 nov. 2009 à 04:42, Jonathan Woithe a écrit : > Hi again > > I just noticed this later reply. > >>> Ok this happens in JACK2 FFADO backend line 472 and it caused by a >>> "ffado_streaming_init" falling... >>> >>> I don't know exactly if JACK2 FFADO backend completely follows JACK1 >>> FFADO backend (ppalmers wrote that code). I guess the best is now to >>> report the issue to FFDAO developers. >> >> I found the solution : FFADO creates (one of ??) its thread with >> a priority of 16 and my limits.conf was set to: >> >> @audio - rtprio 16 >> >> so FFADO wasn't allowed to do such a thing. But it's wired that it >> hasn't the same behavior on Jack1... It should be better that FFADO >> uses the priority set with -Pxx from jack no ?? > > It's a bit more complicated than that. FFADO requires multiple > threads and > a very specific priority order to ensure that the right threads can > always > run at the correct time. The jackd "-P" argument (or the default > level if > "-P" isn't specified) is used as a starting point, but because > multiple > priority levels are needed (some above jackd's, some below) it is at > best a > guide. > > The reason for the differences between jack 1 and 2 might be due to > architectual differences - the FFADO threads and their required > priorities > may differ between the two for that reason. As was commented earlier, > Pieter Palmers (who wrote the respective backends along with most of > the > FFADO streaming infrastructure) would be in the best position to > comment on > this. I don't see any important architectual differences between jack1 and jack2 that could explain what is seen. AFAICS both use the "blocking" version of FFADO API and the backend is then "wrapped" in an RT thread that drives the JACK engine. (Ppalmers told me at LAC 2008 that FFADO could possibly work in a "callback" model, thus making this "wrapping" thread unneeded, an having the FFADO backend then looking like the CoreAudio backend on OSX or PortAudio backend on WIndows... but this change has never been done since) > >> Or at least to add a priority parameter to the backend... > > This won't help because the FFADO thread priorities must be set > relative to > the jackd priorities. jack2 uses a default value of 10 for the RT priority thread. I've just checked again jack1 code and this seems the same (line 60 in jackd.c file..), although Jörn told some days ago that something was different concerning default values of RT thread? (Jörn can you comment on that?) > > We certainly agree that this is a messy situation but it's at least > partly > due to the need to have very fine control over timing in userspace - > something which is required by the needs of the interfaces. The > problem > will eventually be solved using an in-kernel FFADO streaming engine, > but for > now we've got to make use of the RT mechanism as best we can. > > By the way, in my experience one needs to use a priority somewhat > higher > than 15 for successful FFADO use. I personally use "-P60" while > others use > "-P70". Obviously this requires a change to limits.conf to allow > these > levels. The need for the high number comes about because the > default level > used by kernel interrupt routines (particularly in RT kernels) is > 50, and > jackd/FFADO needs to run above this for best results. If you > encounter > stability issues while running at the default jackd priority level > you may > want to try "-P60" or "-P70" and see if it improves things. > > Further discussion on this matter is probably best conducted in > ffado-devel. > > Regards > jonathan > _______________________________________________ Stéphane _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
|
|
|
Re: Jack2 and FFADO, bug ??
by Jörn Nettingsmeier-5
::
Rate this Message:
Tinram wrote:
> I understand the problem, but I think the -P is a bit confusing. -P should > set the *higher* allowed priority and jack should set priorities taking > care that the -P value is the max one he uses, don't you think ? from a user POV, that's correct. but note that the jack server and the driver backend can be (and are, in this case) developed separately. all jackd "knows" is that -P X is the maximum priority it can use. it happens that some ffado threads need a priority higher than that, but jack cannot know this unless some very messy notifications are being passed around. i guess this is better solved by user documentation, and by ffado spitting out a useful error message in that case. -- Jörn Nettingsmeier Meister für Veranstaltungstechnik Audio and event engineer Ambisonic surround recordings http://stackingdwarves.net +49 177 7937487 _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Re: Jack2 and FFADO, bug ??
by Jörn Nettingsmeier-5
::
Rate this Message:
Stéphane Letz wrote:
> > jack2 uses a default value of 10 for the RT priority thread. I've just > checked again jack1 code and this seems the same (line 60 in jackd.c > file..), although Jörn told some days ago that something was different > concerning default values of RT thread? (Jörn can you comment on that?) when invoked with -R but no explicit -P, current jackd1 uses these priorities: nettings@kleineronkel:~> ps -eLo pid,nice,pri,cls,rtprio,command | grep jack 32166 0 19 TS - jackd -R -d alsa -d hw:1 32166 0 19 TS - jackd -R -d alsa -d hw:1 32166 0 19 TS - jackd -R -d alsa -d hw:1 32166 - 60 FF 20 jackd -R -d alsa -d hw:1 32166 - 50 FF 10 jackd -R -d alsa -d hw:1 i.e. jackd1 uses an rtprio of 20 by default. i guess the confusion comes from mixing up pri and rtprio fields. in any case the default rtprio in real-time mode should be changed imho, to at least 51, so that the jackd realtime threads take precedence over standard IRQ handlers (which are running at rtprio 50 by default). in addition, it is recommended (especially for ffado) to raise the priority of ffado-critical IRQs to something higher than the jackd realtime threads, possibly even higher than the ffado-related ones. regards, jörn -- Jörn Nettingsmeier Meister für Veranstaltungstechnik Audio and event engineer Ambisonic surround recordings http://stackingdwarves.net +49 177 7937487 _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Re: Jack2 and FFADO, bug ??
by Stéphane Letz
::
Rate this Message:
Le 7 nov. 2009 à 15:31, Jörn Nettingsmeier a écrit : > Stéphane Letz wrote: >> >> jack2 uses a default value of 10 for the RT priority thread. I've >> just >> checked again jack1 code and this seems the same (line 60 in jackd.c >> file..), although Jörn told some days ago that something was >> different >> concerning default values of RT thread? (Jörn can you comment on >> that?) > > when invoked with -R but no explicit -P, current jackd1 uses these > priorities: > nettings@kleineronkel:~> ps -eLo pid,nice,pri,cls,rtprio,command | > grep jack > > 32166 0 19 TS - jackd -R -d alsa -d hw:1 > 32166 0 19 TS - jackd -R -d alsa -d hw:1 > 32166 0 19 TS - jackd -R -d alsa -d hw:1 > 32166 - 60 FF 20 jackd -R -d alsa -d hw:1 > 32166 - 50 FF 10 jackd -R -d alsa -d hw:1 > > i.e. jackd1 uses an rtprio of 20 by default. > i guess the confusion comes from mixing up pri and rtprio fields. > > in any case the default rtprio in real-time mode should be changed > imho, > to at least 51, so that the jackd realtime threads take precedence > over > standard IRQ handlers (which are running at rtprio 50 by default). in > addition, it is recommended (especially for ffado) to raise the > priority > of ffado-critical IRQs to something higher than the jackd realtime > threads, possibly even higher than the ffado-related ones. > > regards, > > jörn > Hum..., looking at jack1 code again i see: static int realtime_priority = 10; (line 60 in jackd.c ) and : int watchdog_priority = engine->rtpriority + 10; (line 970 in engine.c) So It seems that the thread at 20 is the watchdog RT thread and thread at 10 is the backend RT thread ? Now concerning what would be the right default value, I don't know... but it would be better to use the same value for jack1 and jack2.. Stéphane _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Re: Jack2 and FFADO, bug ??
by Fernando Lopez-Lezcano
::
Rate this Message:
On Sat, 2009-11-07 at 15:41 +0100, Stéphane Letz wrote:
> Le 7 nov. 2009 à 15:31, Jörn Nettingsmeier a écrit : > > > Stéphane Letz wrote: > >> > >> jack2 uses a default value of 10 for the RT priority thread. I've > >> just > >> checked again jack1 code and this seems the same (line 60 in jackd.c > >> file..), although Jörn told some days ago that something was > >> different > >> concerning default values of RT thread? (Jörn can you comment on > >> that?) > > > > when invoked with -R but no explicit -P, current jackd1 uses these > > priorities: > > nettings@kleineronkel:~> ps -eLo pid,nice,pri,cls,rtprio,command | > > grep jack > > > > 32166 0 19 TS - jackd -R -d alsa -d hw:1 > > 32166 0 19 TS - jackd -R -d alsa -d hw:1 > > 32166 0 19 TS - jackd -R -d alsa -d hw:1 > > 32166 - 60 FF 20 jackd -R -d alsa -d hw:1 > > 32166 - 50 FF 10 jackd -R -d alsa -d hw:1 > > > > i.e. jackd1 uses an rtprio of 20 by default. > > i guess the confusion comes from mixing up pri and rtprio fields. > > > > in any case the default rtprio in real-time mode should be changed > > imho, > > to at least 51, so that the jackd realtime threads take precedence > > over > > standard IRQ handlers (which are running at rtprio 50 by default). in > > addition, it is recommended (especially for ffado) to raise the > > priority > > of ffado-critical IRQs to something higher than the jackd realtime > > threads, possibly even higher than the ffado-related ones. > > > > regards, > > > > jörn > > > > > Hum..., looking at jack1 code again i see: > > static int realtime_priority = 10; (line 60 in jackd.c ) > > and : > > int watchdog_priority = engine->rtpriority + 10; (line 970 in > engine.c) > > So It seems that the thread at 20 is the watchdog RT thread and thread > at 10 is the backend RT thread ? > > Now concerning what would be the right default value, I don't know... > but it would be better to use the same value for jack1 and jack2.. In my Planet CCRMA packages I've been patching jack1/2 for years to match the priorities assigned by rtirq on realtime kernels. "10" or even "20" certainly don't work very well, that's much lower than all other rt priorities of kernel and interrupt threads. The ideal situation is priority of soundcard interrupt > jack priority > all others. -- Fernando _______________________________________________ Jack-Devel mailing list Jack-Devel@... http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
| Free embeddable forum powered by Nabble | Forum Help |
