<azonenberg>
So with these latest fixes, OpenCL accelerated filters should now work correctly in debug builds with sanitizers enabled
<azonenberg>
at least on nvidia, the default asan settings seem to conflict with the driver
<d1b2>
<louis> Yes, after those linked patches, I can reliably get 125MPt captures out of my Tek MSO56. The MSO6 is at a client site and hasn't been tried, but I would hope it works too.
<azonenberg>
@louis: OK, so please update the docs then
<d1b2>
<louis> Will do :)
<azonenberg>
also not sure if you've seen the SCPI console yet but please give it a try
<azonenberg>
it works well with any driver using the queued command API
<azonenberg>
may have issues for anything using the older raw send
<d1b2>
<louis> The issue with USBTMC still stands. I got about 15m into looking at it the other day and I'll circle back eventually
<azonenberg>
not sure if you're familiar with the difference?
<azonenberg>
it looks like the current tek driver is a mix of both so it could use some refactoring
<azonenberg>
long term i want to move all of the drivers over to the queued API except for occasional special optimizations that need low level access
<azonenberg>
tl;dr SendCommandQueued() / SendCommandQueuedWithReply() are generally preferred. These methods push the command into a FIFO within the SCPITransport object, which is then flushed to the device the next time a read or explicit flush is requested
<azonenberg>
most importantly they use a separate mutex than is used to control access to the actual socket
<azonenberg>
which means that you can SendCommandQueued() while the socket is busy downloading a waveform
<azonenberg>
and it won't block
<azonenberg>
This eliminates the need to have mutexing in the driver object, for the most part - sometimes in AcquireData() you might need to explicitly lock the net mutex and do low level send/recv calls if you want to batch commands
<azonenberg>
but afaik the tek backend doesnt support that anyway