#1797 xruns using new JACK Transport Logic

[musewhirl]

This bug started as a side-effect in [#1721], but is now reported here for easier tracking.

In a nutshell, launching rosegarden results in a number of errors not seen using its previous JACK logic. The first state=Running error (see below) was guaranteed every time if the user has the checkbox to allow RG to create JACK ports for individual instruments.

JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error

The second state=Triggered error appears randomly and not that often, and I've not seen any user activity which makes it reproducible, nor even caught the activity which causes it yet. I think it might still be while launching though:

JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error

These errors show up in the JACK log only, not RG logs. Currently, apart from their appearance, I've not noticed any other negative behavior in RG with respect to playback. On advice in bug #1721, the box to create JACK ports for individual instruments is now unchecked in my case, which is the default for RG. This removed the guaranteed one-off state=Running error. However, it still happens randomly on launching. I've not seen it appear after RG is settled on the screen.

I'll add the following as further observations specific to the xruns aspect of this bug. In a move to test further, ardour was selected as the jack client.

Ardour's main window
After session selection, ardour's main window appears. With the new JACK logic, a lot of state=Runningerrors appear in the jack logs...guaranteed. In other words, the unchecking of creating jack ports for individual instruments, is not going to prevent guaranteed appearance of the error...here we have not just one, but many. Is that reproducible in the dev environment?

JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = RosegardenTransportClient was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error

I checked the ardour session, and it does not even have JACK transport selected. I usually assume that it means ardour is not using JACK transport, so why would jack be mentioning RG in its logs? Note also, that ardour does have an AudioConnectionManager, which is aware that RG is out there, but in my test session, it has no connection ports to RG selected.

Ardour's Xruns field
When ardour launches, it indicates the number of xruns in a main window field. I am used to seeing a a half-dozen or so, even though jack does not report them as xruns...the jack log remains silent. I believe that those are not xruns per se, but related to a design issue in ardour where opening and closing GUIs results in the count increasing in the ardour xrun count field. I've seen it for years, but only occur when I am opening and closing ardour windows. With the old jack code, and a test ardour session, I get around six xruns for the launch...for a given session, the number is quite consistent for a particular session. But with the new logic, I get double that, and furthermore what appears to be an equal (or close) number of state=Running errors. At first one might assume RG's jack errors are as harmless as the ghost like xruns reported by ardour. However, those ghost-like xruns only occur when ardour windows are opening and closing, and never show up in jack's logs.

With respect to the xrun count field in ardour, if that field increases by 1 during recording, that xrun is seen in the jack logs and ardour has a configuration setting which aborts the entire recording session. I guess that is for those who can't afford an audio glitch or checking whether one gets through. I have that set, so at some point, I should be able to determine whether this new error causes an abort i.e. mentions RG. But that will take time. For now, the above question about the checkboxes is required, and also whether the errors mentioned above are reproducible in a development environment.

Launching ardour default sessions
I thought it might be something about my test session, but I tried one of ardour's default sessions:

1. Launch ardour
2. Select New Session
3. Select: Empty Template (An empty session with factory default settings.)
4. Enter a name for it
5. Click Open

For this I consistently get two state=Running errors. For another called "Jazz Backing Band", I get 8 state=Running errors. Since these numbers are consistent for the chosen sessions, it might provide more clues as to meaning. Can you reproduce these too?

Up until now, these new errors have only been seen when opening RG. Now they are seen opening a jack client which is supposedly not using jack transport. At this point, there are a couple of questions so far unanswered in bug #1721, but best answered here related to this bug:

1. By default, RG starts with only the new JACK logic checked and the previous checkbox unchecked. In my case, since I was using jack previously, I already had the previous jack box checked, so I have both checkboxes after building and using RG from master. Is this correct?
2. Do I have to manually uncheck the old Usd jack checkbox in order to use the new JACK Transport Logic?

The answer to that question is required before any further testing can be done for this xruns bug. All testing could be invalid, if only a certain combination of the checking of those boxes is allowed.

[Ted Felix]

Pushed a potential fix for this as [310fc4]. Please test latest git with "New JACK Transport Logic" enabled.

[Ted Felix]

[310fc4] appears to fix the XRun at launch, but now I am seeing an XRun every time I press play. It's the "triggered" case. I'm assuming this is because we are doing too much work in TransportControl::processCallback() when transitioning to playback. With the old logic, we do nothing related to the sequencer during "process". Now we initiate playback which is a lot of work and causes JACK to miss its real-time deadline

We need to get the sequencer code out of TransportControl::processCallback().