OK,I’ve rebuilt my machine with Fedora Core 7 and CCRMA, and have Ardour2 and jack from the CCRMA repo. When I open any session in Ardour, the Latency menu is correctly defaulting to whatever buffer size I have set in jack (via Qjackctl). All looks good. In this case, the buffer size is 512 for my 1010LT
When I click the Play button on an existing session, Ardour just vaporizes, and jack shows an xrun. Unfortuantely, I don’t remember the text that went along with the crash – the machine has no network connection from the studio.
Here’s more weirdness. When I started troubleshooting, I went in and switched the latency value to 32, and everything works fine (playback, recording, no crashes or xruns). Why should I have to have the Ardour latency set differently from jack’s buffer size. Are there known issues with CCRMA’s FC7 versions of jack, alsa and/or Ardour2?
And an aside: If the Ardour “latency” value is actually supposed to match the jack buffer size, wouldn’t it make more sense to call it “Buffer”?
the menu you are referring to is there to reset the JACK period size, nothing more (or less). its just for convenience (and because qjackctl doesn’t provide a way to change it without stopping & restarting JACK (which is not technically necessary).
as for latency/buffer/period … its all a nasty mess. the new JACK control dialog that is part of the new session dialog if you are not already running JACK uses “buffer” to refer to “period” and also uses the term “latency” in a “normal” way.
the problem with using “buffer” is that most people don’t actually understand what it means. in the ASIO case, where it is used most often, its meaning is constrained by the fact that ASIO always uses a 2-buffer system. for ALSA, this is not true, and the term “buffer” refers to the total chunk of memory used to exchange data between the audio interface and the CPU. that buffer is period_size * num_periods big.
its not possible to debug your crash issue with the limited information you’ve provided.
OK, so I don’t think there really was an issue – I think the crash was something to do with the session. New sessions didn’t exhibit the same behavior, and the session in question started working correctly after I disabled the Control Surfaces stuff that it was trying to start up (without the surface being attached).
One thing I saw, though, was that the latency value in Ardour isn’t always matched to what jack has running. When my jack buffers are set to 512, ardour comes up with 512. When I set jack to 256, ardour comes up with 32. This doesn’t seem to affect anything (which makes sense, according to Paul’s description above…), but I saw that there had been a bug for correcting this.