I meant the confusion about the original ZWO library.
I didn't mean why you need 16-bit mode
Above I wrote my thoughts on USB and the library.
They divide each transfer into 1MB. For the ASI178 camera, 7 bulk transfers are created for the 8-bit mode and 14 for the 16-bit mode.
This is what I suggested when writing the wrapper.
Now I have modified it so that the transfer is not split into parts in the application layer.

My goal is to fix the ZWO library so that it is usable on Linux. Because that's where the main problem lies.

Looking at your attachment I can see that everything is fine! right?
When receiving the frames, none got lost and you achieved fps above the manufacturer's declaration.

PDB wrote: Not really want to do this on an RPI...

I do not understand.
You don't want to run the camera on Linux on RPi?
Are you running it on W10 on RPi? How do you use the camera?
How long are your videos? How can I help you?

PDB wrote: Looks logic that you need to keep buffers smaller to have it run on the smaller Rpi's.

I don't understand what you're referring to.
The last modification was based on a smaller number of larger buffers. And in fact, on their distribution of addresses for transfers. I operate on megabytes here, I am far from hardware limitations.

In my project I want to use RPi for wireless transmission of high-speed cameras. After optimizing the code, I think it is real. That's why I started working.
Writing directly to the disk should not be a problem either. Additionally, by introducing a simple lossless compression, it is possible to reduce the size by half.

You can describe how you currently use the hardware/software and how you would like to use it?

After some tweaks, I think libASICamera2Boost will be ready. I still have to fix the Indi Library so that no frame gets lost.

Read More...