Mercurial > hg > piper-cpp
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 }; |