comparison vamp-support/LoaderRequests.h @ 186:52322dde68ea

Fix erroneous logic for handling step and block size in prior commit The earlier change had a logical misconception. If PluginStub is receiving the correct step and block size back from the configure call, the plugin on the server side must have already been successfully initialised, as the step and block size are only returned in a successful configure response. This means the test for a failed initialise and redo with the correct parameters must be done on the server side (in LoaderRequests) not the client. The client has a more complicated job, which is to notice that a *successful* configure had returned different framing parameters from those passed to the initialise call, and to pretend that it had actually failed until the host called again with the correct parameters. We definitely need tests for this!
author Chris Cannam <cannam@all-day-breakfast.com>
date Mon, 06 Feb 2017 16:44:33 +0000
parents 3eb00e5c76c4
children e0e3d9efa774
comparison
equal deleted inserted replaced
185:3eb00e5c76c4 186:52322dde68ea
134 if (req.configuration.framing.stepSize == 0 || 134 if (req.configuration.framing.stepSize == 0 ||
135 req.configuration.framing.blockSize == 0) { 135 req.configuration.framing.blockSize == 0) {
136 return response; 136 return response;
137 } 137 }
138 138
139 Framing pluginPreferredFraming;
140 pluginPreferredFraming.stepSize = req.plugin->getPreferredStepSize();
141 pluginPreferredFraming.blockSize = req.plugin->getPreferredBlockSize();
142
139 if (req.plugin->initialise(req.configuration.channelCount, 143 if (req.plugin->initialise(req.configuration.channelCount,
140 req.configuration.framing.stepSize, 144 req.configuration.framing.stepSize,
141 req.configuration.framing.blockSize)) { 145 req.configuration.framing.blockSize)) {
142 146
143 response.outputs = req.plugin->getOutputDescriptors(); 147 response.outputs = req.plugin->getOutputDescriptors();
146 // definition it is accepting the step and block size 150 // definition it is accepting the step and block size
147 // passed in 151 // passed in
148 response.framing = req.configuration.framing; 152 response.framing = req.configuration.framing;
149 153
150 } else { 154 } else {
151 155
152 // If initialise() fails, one reason could be that it 156 // If initialise() fails, one reason could be that it
153 // didn't like the passed-in step and block size. If we 157 // didn't like the passed-in framing (step and block
154 // return its current preferred values here, the 158 // size).
155 // host/client can retry with these (if they differ) 159 //
156 response.framing.stepSize = req.plugin->getPreferredStepSize(); 160 // Vamp and Piper have quite different mechanisms for
157 response.framing.blockSize = req.plugin->getPreferredBlockSize(); 161 // negotiating step and block size:
162 //
163 // - If a Vamp plugin doesn't like the step and block size
164 // passed to initialise(), it fails the initialise() call,
165 // returning false from it. The host is expected to have
166 // called getPreferredStepSize()/BlockSize() after it made
167 // any parameter changes that might have affected these
168 // preferences (but before calling initialise).
169 //
170 // - If a Piper server doesn't like the step and block
171 // size passed in a configure request, but if everything
172 // else about the configure request is OK, then it returns
173 // a successful configure response including its preferred
174 // step and block sizes in the response (which the host
175 // must then use). The important thing to note is that
176 // this is still a successful response, something we do
177 // not yet have here.
178 //
179 // We need to check whether the passed-in framing differs
180 // from the plugin's preferences; if so, then we form a
181 // working supposition that initialise() failed because of
182 // this. Vamp contains nothing to allow us to test this,
183 // except to try initialise() again with different
184 // values. So we try again with the values the plugin told
185 // us it would prefer and, if that succeeds, return them
186 // in a successful response in the Piper manner.
187 //
188 // Note that if the "other side" (i.e. the client) wants
189 // to interpret this as if it were dealing with a Vamp
190 // plugin, then it's going to need some equal-but-opposite
191 // acrobatics.
192
193 if (req.plugin->initialise(req.configuration.channelCount,
194 pluginPreferredFraming.stepSize,
195 pluginPreferredFraming.blockSize)) {
196
197 response.outputs = req.plugin->getOutputDescriptors();
198 response.framing = pluginPreferredFraming;
199
200 } // ... else we return no outputs, which is the error
201 // case (presumably to be converted to Piper error
202 // response).
158 } 203 }
159 204
160 return response; 205 return response;
161 } 206 }
162 }; 207 };