From: Jonathan W. <jw...@ph...> - 2007-08-13 01:00:36
|
Hi guys A minor observation. I've had communication from someone who's tested svn515 with a MOTU 828MkII. They noticed the following: > Latency is reported to Jack's clients as if the number of period per > buffer was 1. This issue would affect all MOTUs AFAIK - it's not restricted just to the 828MkII although I have not personally verified it with the Traveler. However, I'm wondering whether it's something about the MOTU driver which is doing this or if it's a known FFADO issue which is still being worked on. I note that in the JACK svn all calls to jack_port_set_latency() in the ffado driver are commented out. Now I have no idea how the whole latency reporting thing works in JACK but it seems to me that this might be in some way related. I also see that the freebob driver does call jack_port_set_latency(). My tentative conclusion is that it's a FFADO issue and something which is still being worked on, but I'd like confirmation of this theory. If it is instead a MOTU problem I'll obviously spend some time trying to work it out. Regards jonathan |
From: Pieter P. <pi...@jo...> - 2007-08-14 13:38:59
|
Jonathan Woithe wrote: > Hi guys > > A minor observation. I've had communication from someone who's tested > svn515 with a MOTU 828MkII. They noticed the following: > > > Latency is reported to Jack's clients as if the number of period per > > buffer was 1. > > This issue would affect all MOTUs AFAIK - it's not restricted just to the > 828MkII although I have not personally verified it with the Traveler. > However, I'm wondering whether it's something about the MOTU driver which is > doing this or if it's a known FFADO issue which is still being worked on. > > I note that in the JACK svn all calls to jack_port_set_latency() in the > ffado driver are commented out. Now I have no idea how the whole latency > reporting thing works in JACK but it seems to me that this might be in some > way related. I also see that the freebob driver does call > jack_port_set_latency(). My tentative conclusion is that it's a FFADO issue > and something which is still being worked on, but I'd like confirmation of > this theory. If it is instead a MOTU problem I'll obviously spend some time > trying to work it out. There are some fixes to the freebob jack backend that haven't been propagated to the firewire jack backend yet. This is one of them. Once we go alpha we'll have to propagate/merge these fixes. Greets, Pieter |
From: Francois.ernoult <fra...@pa...> - 2007-08-14 13:57:36
|
Hi guys, > > A minor observation. I've had communication from someone who's tested > > svn515 with a MOTU 828MkII. They noticed the following: > > > > > Latency is reported to Jack's clients as if the number of period per > > > buffer was 1. > > > > This issue would affect all MOTUs AFAIK > > There are some fixes to the freebob jack backend that haven't been > propagated to the firewire jack backend yet. This is one of them. > This observation also applies to FreeBoB svn r389 (around last working FreeBoB rev for MOTU). I will track changes to FreeBoB since r389 and try to make it working for FFADO. I'll do a patch when I'll find a fix. Regards, Francois |
From: Pieter P. <pi...@jo...> - 2007-08-14 14:07:20
|
Francois.ernoult wrote: > Hi guys, > >>> A minor observation. I've had communication from someone who's tested >>> svn515 with a MOTU 828MkII. They noticed the following: >>> >>> > Latency is reported to Jack's clients as if the number of period per >>> > buffer was 1. >>> >>> This issue would affect all MOTUs AFAIK >> There are some fixes to the freebob jack backend that haven't been >> propagated to the firewire jack backend yet. This is one of them. >> > > This observation also applies to FreeBoB svn r389 (around last working > FreeBoB rev for MOTU). > I will track changes to FreeBoB since r389 and try to make it working for > FFADO. I'll do a patch when I'll find a fix. Note that I'm not talking about freebob or ffado itself, but about their respective backends in the jack source tree. Greets, Pieter |
From: Francois.ernoult <fra...@pa...> - 2007-08-20 22:32:07
Attachments:
jack_ffado_latency.svn1051.patch
|
Hi, >>> A minor observation. I've had communication from someone who's tested >>> svn515 with a MOTU 828MkII. They noticed the following: >>> >>> > Latency is reported to Jack's clients as if the number of period per >>> > buffer was 1. The attached patch fix the latency reported to Jackd's clients and restores the -I and -O options to set extra latency frames. The best would be to take in account the hardware latency (ADC, DSP, DAC, etc...) on a per port basis. The problem is to know the actual hardware input and output latency (we only can measure the some of both). Anybody knows if this information is available for other interfaces than MOTU? I will try to get the information from MOTU but nothing is sure. Regards, Francois |
From: Jonathan W. <jw...@ph...> - 2007-08-20 23:24:28
|
Hi Francois > >>> A minor observation. I've had communication from someone who's tested > >>> svn515 with a MOTU 828MkII. They noticed the following: > >>> > >>> > Latency is reported to Jack's clients as if the number of period per > >>> > buffer was 1. > > The attached patch fix the latency reported to Jackd's clients and restores > the -I and -O options to set extra latency frames. Sounds good. I'll let Pieter review this since it probably affects his code more than anyone's. > The best would be to take in account the hardware latency (ADC, DSP, DAC, > etc...) on a per port basis. The problem is to know the actual hardware > input and output latency (we only can measure the some of both). I can certainly measure it but it might be a while yet - I have other things to do which are of higher priority. > Anybody knows if this information is available for other interfaces than > MOTU? I doubt it - I suspect you'd have to measure it. Manufacturers would know but whether they'll share it with us is anyone's guess. > I will try to get the information from MOTU but nothing is sure. Best of luck. Just don't tell them you're working on the Linux driver or you'll get the standard "we don't support Linux" answer. :-( Regards jonathan |
From: Francois.ernoult <fra...@pa...> - 2007-08-21 00:13:26
|
Hi Jonathan, > > The best would be to take in account the hardware latency (ADC, DSP, > DAC, > > etc...) on a per port basis. The problem is to know the actual hardware > > input and output latency (we only can measure the some of both). > > I can certainly measure it but it might be a while yet - I have other > things > to do which are of higher priority. Yes, I'm just thinking about that because it was in the same focus than soft latency compensation. I can measure output+input latency (91 1/fs for analog), but I need a known output to measure the input and vice versa. > > > Anybody knows if this information is available for other interfaces than > > MOTU? > > I doubt it - I suspect you'd have to measure it. Manufacturers would know > but whether they'll share it with us is anyone's guess. > > > I will try to get the information from MOTU but nothing is sure. > > Best of luck. Just don't tell them you're working on the Linux driver or > you'll get the standard "we don't support Linux" answer. :-( For sure. No, just for "commercial" information, via the frensh MOTU distributor who is a fiend of my associate. > > Regards > jonathan |
From: Francois.ernoult <fra...@pa...> - 2007-09-08 09:40:01
|
Hi all, Did someone test the patch sent a few weeks ago about this (jack_ffado_latency.svn1051.patch)? If there's no problem, I'll send it to Paul Davis. Regards, Francois |
From: Pieter P. <pi...@jo...> - 2007-09-08 10:29:49
|
Francois.ernoult wrote: > Hi all, > > Did someone test the patch sent a few weeks ago about this > (jack_ffado_latency.svn1051.patch)? > > If there's no problem, I'll send it to Paul Davis. There is no need to send it to Paul, since I maintain the jack backend for jack. I'll apply the patch now, since the firewire backend is experimental anyway. It still needs testing though. Pieter |
From: Pieter P. <pi...@jo...> - 2007-08-21 08:06:10
|
Francois.ernoult wrote: > Hi, > >>>> A minor observation. I've had communication from someone who's tested >>>> svn515 with a MOTU 828MkII. They noticed the following: >>>> >>>> > Latency is reported to Jack's clients as if the number of period per >>>> > buffer was 1. > > The attached patch fix the latency reported to Jackd's clients and restores > the -I and -O options to set extra latency frames. > I'm going to apply it, but I wonder why the addr_of_nullbuffer is introduced. Greets, Pieter |
From: Francois.ernoult <fra...@pa...> - 2007-08-21 08:30:46
|
Hi > > The attached patch fix the latency reported to Jackd's clients and > restores > > the -I and -O options to set extra latency frames. > > > I'm going to apply it, but I wonder why the addr_of_nullbuffer is > introduced. This not very beautiful hack is from the FreeBoB backend, it's removes a warning. Its up to you, after all I think I prefer a warning than this hack but... Regards, Francois |