Hi, is there a capture limit for v. 1.2.29 in Debian? It crashes with this error:
Client Session Deleted: 1 [ /home/build/ob_logic/Source/Session.cpp; ~Session; 76 ]
qt.network.ssl: QSslSocket: cannot call unresolved function SSLv23_client_method
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_library_init
read timeout [ /home/build/ob_logic/Source/LinuxUsbDevice.cpp; ReadThread; 328 ]
Master Fifo overflow [ /home/build/ob_logic/Source/LogicProfessionalDevice.cpp; StopCallback; 545 ]
cleanup stream discarded 130 URBs. 0 URBs never queued
Successful transfers: 11523 [ /home/build/ob_logic/Source/LinuxUsbDevice.cpp; ReadThread; 383 ]
On Error Event. Id: 11187063413064850164, Error: 1 [ /home/build/ob_logic/Source/DataCollector.cpp; OnError; 120 ]
Killed
Thanks!
Got a screenshot when it freezes
:
Sorry for the trouble with this! Everything in the log before “Killed” indicates a USB transfer failure. The device side buffers overflowed, which triggered the device to stop recording. This caused the following read requests on the Logic software to timeout, ending the capture.
The problem here is probably memory. The screenshot shows the software reporting 23 GB in use. The in-app memory reporting is usually off by a lot when analyzers are used, so it’s likely that even more memory was in use.
I expect a few things could have happened:
- The capture stopped not because of a USB problem, but because the USB thread could not allocate new transfer buffers fast enough. This is a common problem when the software memory usage is very high and there is little to no free ram available. The OS has to page memory to disk before it can provide additional RAM, and if the OS takes too long to provide the RAM, the PC will momentarily stop issuing read requests to the device, causing it to time out.
- The “Killed” message. I can’t be 100% sure, but I suspect that the OS has killed our application because it’s run out of memory.
Logic 1.x never dealt with running out of memory well. It relied on the OS to tell it when memory was no longer available, through the std::bad_alloc exception. This would cause our software to stop capturing and stop processing memory. Later we added a memory “airbag” that would get deleted the moment this happened too, but overall, it was not a good solution. This is the most obvious on Linux. On Linux, the OS would pretty much die trying to allocate more memory for the software. On some systems, this would cause the OS to become unresponsive, until either Logic was killed or the user reboot the system.
Logic 2 takes a different approach. Instead, it asks the user to set a memory limit for the capture. (Logic 2 still has some bugs with this, but the experience is much better). Logic 2 also introduces a capture mode called “Looping” where the capture has no definite end (it needs to be stopped by the user) and the oldest recorded data is automatically deleted to ensure the used memory does not exceed the user selected buffer size.
I have a few suggestions:
- Update to Logic 2 and compare its performance.
- Analyzers consume a lot of memory. Especially high speed protocols like I2S. I suggest removing all of your analyzers before starting the capture. Once completed, Save the capture, then add 1 analyzer at a time. This way, memory pressure from the analyzers can’t disrupt the capture, because the capture is already complete. You also might want to try only having 1 analyzer added at a time. I2S analyzers are likely consuming the majority of the memory in use here.
- Take shorter captures. If the software crashes, you will lose the recorded data. Stopping the capture before this happens let’s you keep that data. Logic 1.x has an automation interface that lets you automate recording & saving do disk repeatedly. This tool is designed for that purpose: GitHub - saleae/python-saleae-cli: basic command line utility to automate the Saleae Logic software using the ppannuto python-saleae library
What are your goals? Do you need to record long durations of I2S Audio? Would a series of shorter captures taken with a short delay (gaps) be acceptable? With this information we could provide better support.
Ah I just saw that you were posting about automation in another thread. Sorry we don’t support that in Logic 2 yet!
Could you describe how your automation setup works?
If you are trying to automate recording and exporting I2S Audio data, then my suggestion about recording without analyzers and then adding them back will be a little tricky to automate.
I haven’t tried this before, but I think it should work.
- save to “*.logicsettings” files. One with I2S analyzers and one without.
- Before starting a capture, use the load_from_file command to load the settings file without analyzers.
- Record your data
- Use the load_from_file command to load the settings file with analyzers.
- wait for analyzers to finish, then export them.
- repeat.
when using load_from_file with a *.logicsettings file, it should try to apply the settings from that file to the existing capture, if there is one.
Ok, let me try that. Yes, I’m automating this process. The goal is make ~ 1 hr recordings but it looks like it will depend on what we have in RAM, right?. Let me try that. Making a recording without analyzers and then load the logicsettings with the analyzers.
@jesussalinas Sounds good. We’re looking forward to the results of those tests.
Yes, you are correct. Having free RAM available will help avoid the issue where the USB thread is not able to allocate new transfers fast enough.
Hi, I think is the same behavior. Without analyzers still consuming the same amount of RAM and rapidly. I’m gettin 6 min with 32 ram. Looks like 2.x have a better memory resource management. Are you planning to have this memory management for 2.x soon? or Api for 2.x?
Thanks!
Hm… The problem is just the number of transitions you’re trying to record.
Our software run-length encodes digital data, so memory usage is proportional to the number of transitions in the capture, not the duration of the capture or the sample rate.
I2C audio is a very dense protocol. Our software uses about 1-2 bytes of RAM per transition. We used to have a sophisticated memory usage estimator on our website. I’ve just checked, I can’t believe we currently don’t offer any specific numbers on this on our website or support materials. I’ll get that fixed ASAP.
Digital audio can easily be clocked over 10 MHz, depending on the sample rate and bit depth. Recording 2 channels of that at the same time could result in memory usage rates over 100 MBytes/second.
I’m very sorry for the trouble with this. I don’t realistically believe it’s possible to record two (or even one) I2S digital audio stream for a full hour with our products, and there was nothing on our website to explain this to customers. I would suggest automating this to run in chucks between 1 and 5 minutes, but I completely understand if you would prefer to return the units for a full refund if our tools can’t meet your needs. Again, I apologize for this and if you would like to proceed, please contact support and @timreyes can handle the process from there.
