Closed freesig closed 6 years ago
Is there any chance that the channels are laid out one after the other in one long slice?
That does look pretty suspicious though that it has an array of buffer pointers that are both showing the same pointer. What do the 0
s mean from is_input
and channel_num
?
So the ASIOCreateBuffers is just giving each buffer the exact same address. I tried writing some C++ across the boundary and printing the pointers and it's the same there. So it's nothing to do with rust. One solution is to offset the buffers by casting them to the
(ptr as *mut TheSampleType).offset(buffersize * channel_number)
But this is super hacking.
Is there any chance that the channels are laid out one after the other in one long slice?
Yes I'm pretty sure they are although this is implemented in the driver so I'm not sure we can count on it.
What do the 0s mean from is_input and channel_num?
is_input means 0 is an output or 1 is an input channel. I still don't know what channel number really means. It basically says the input channel index counting from 0 but I'm not sure if I just make that up or not. The docs on this are super confusing and don't actually match the implementation.
To clarify ASIOCreateBuffers is a virtual function in the SDK which is implemented in the actual drivers. So I can't check the code or rely on the behavior. It's super confusing though because port audio seems to be using this in a similar way. Also if this was a bug surely it would have been noticed. Even weirder that it happens in asio4all and the dante asio drivers
This is how port audio does it
It does seem they are using the channel numbers. I'll try that
ok that did it hahaa
It appears ASIO is only outputting from a single channel. The output from create buffers:
It looks like both channels are assigned the same pointer addresss.