No.
14-bit audio works by using Paula's built-in for free Channel Locking function which locks 2 channels together into 1 channel. 1 of the channels provides 8-bits of data and the other channel provides 6-bits of volume control. They are fed with the normal DMA mechanism, otherwise it would be quite useless.
I don't think this is correct. Or rather, I don't believe existing calibrated/uncalibrated cybersound drivers for Paula work this way. If they did, you have the following problem to solve, for every 14-bit output value you intend to emit:
SampleValue14 = ChannelVolume * SampleValue8
where ChannelVolume is 0-63 and SampleValue8 is -128 to 127.
The problem with this is that there are many ways to factorise the 14-bit value you want or a value close to it. As an example, suppose your target SampleValue14 is 2048 (which would represent an instantaneous value equivalent to 0.25x the maximum positive value). Do you choose
Favouring larger ChannelVolume :
ChannelVolume = 63, SampleValue8 = 32 (2016)
ChannelVolume = 63, SampleValue8 = 33 (2079)
ChannelVolume = 62, SampleValue8 = 33 (2046)
Favouring exact factorisations:
ChannelVolume = 32, SampleValue8 = 32 (2048)
ChannelVolume = 16, SampleValue8 = 64 (2048)
Favouring larger SampleValue8:
ChannelVolume = 16, SampleValue8 = 127 (2032)
ChannelVolume = 17, SampleValue8 = 120 (2040)
In this trivial case, we have 2 exact factorisations we could use and an entire spread of close approximations for the case where we favour larger channel volume or where we favour larger sample value.
You can make a lookup table, of course, but even if you did, how do you decide which pair of values to use for any given target value? Moreover, this model requires that both the channel volume and 8-bit sample values behave linearly, which they don't particularly. Such a table would also be rather large.
As far as I know, 14-bit replay uses a summed approach as follows:
SampleValue14 = ChannelVolume63 * (SampleValue16MSB) + ChannelVolume1 * (SampleValue16LSB/4)
Moreover, this summation is not perfect since the operation divides the LSB by 4 (basically discarding the least significant 2 bits of data) but only multiplies the MSB by 63, rather than 64. However, this can be rectified by replacing the second term with a small lookup of adjusted values that when summed with the MSB give a better approximation of the desired output value. Beyond that you only need to worry about the true factor by which ChannelVolume63 is than ChannelVolume1 and calibrate accordingly to get a close to linear output.