For your situation binding the application to a different core is probably a good approach if it uses a single thread (you could also experiment with running the program at higher priorities, e.g., a nice level of -1 or -2…if it has its own core, maybe even nice of -5…see “man nice” or “man renice”).
USB drivers do their own thing anyway on CPU0. The question then is if non-USB code data acquisition/consumption can be given priority on the one other core. Perhaps there are other things going on in other threads where those other threads could be going to other CPU cores, yet don’t involve data acquisition directly (e.g., GUI). Should all those threads (assuming it has many threads) be required to use a single core, then they are essentially serialized again and not really taking advantage of cores threads could take advantage of. So your basic approach is probably good if the design of the program does not have other weaknesses introduced by everything on one core.
See: “man pthread_attr_setaffinity_np”. You may want to get the source code and see if it runs the data acquisition in its own thread; if so, then you can set affinity of just that thread and still have the rest of the process distributed on other cores by the scheduler so those other non-critical threads take advantage of other cores.