News for hackers. Stuff that matters.
Re:I Tried Linux as My Main Dev Environment but Was Forced B... by squarefoot on Tuesday January 29, 2019 @04:20PM (#19029878)
Cracks and pops without buffer xruns might indicate some interrupt related problem. A long time ago in another galaxy we had a problem causing a very small but very regular data loss over local network communications using protocols with no flow control. Of course we would expect some data loss since we were using the wrong protocols for the job (though on a LAN it's not that common), but its regularity made it worth investigating, and in the end I discovered that an interrupt fired by the video card driver (IIRC) every x time would clog the system for a tiny fraction of a fraction of second during which the CPU would essentially be loaded at 100%. To get to the culprit I had to match to the millisecond timestamps of system interrupts with those of data losses. (I totally miss those days...)

Back to the point: had I played audio instead of transmitting data, I would likely have heard those milliseconds of overloaded CPU in the form of pops and cracks, so it may be worth checking if you have something loading the system in bursts during which it cannot process audio safely.

Re:I Tried Linux as My Main Dev Environment but Was Forced B... by nickjj on Tuesday January 29, 2019 @05:02PM (#19030246)
I was keeping htop open during recording and never noticed anything too crazy. CPU was always about 30%-35% max on each of the 4 cores.

Would you still think it's an interrupt issue if there were no pops and cracks on Windows using the same exact hardware in the same USB port?

Re:I Tried Linux as My Main Dev Environment but Was Forced B... by squarefoot on Wednesday January 30, 2019 @09:52AM (#19035443)
Mine was just an idea. If you're experiencing an extremely short burst that overloads the machine, it could be so short that it disappears when measuring average cpu load which is what most tools do, but it could affect a near realtime buffer write or read (from an audio or network card). If there is any way to plot very short high spikes it should become recognizable, especially if it obeys some regular pattern like a timed irq or the like. In our old case, the hardware were Alpha workstations and Tru64 the OS, we nailed the problem to a driver because installing both Linux and *BSD on the same hardware the problem disappeared, so it can be a software issue.