What Frank suggests and what Brian suggested before: modify threading priorities, has been done for the audio threads in PowerSDR for, literally, years. All threads in PowerSDR can be run at real time through a setting in the Setup panel but this is not necessary since what we really care about is having the processing of audio threads be high, and not blocking their ability to run free, etc. We went through all of this when we had that silly metering thread at below normal priority able to grabbing a semaphore which blocked the sdr thread, way be in the early days. Now there may be another threading error still lurking. I will be happy to look at it later but may I suggest that in this group in particular one needs to take a lot of what is said here when it comes to the down near the metal internals of the code, with a mountain of salt. Eric Wachsmann and I spent literally weeks looking for any of the non-dsp threads in the GUI, etc. blocking the high priority threads. I doubt there is a lot of meat left on that bone but I could be wrong.
Bob ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "Trample the slow .... Hurdle the dead" -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Brickle Sent: Sunday, July 20, 2008 6:28 PM To: Brian Lloyd Cc: flexradio@flex-radio.biz Subject: Re: [Flexradio] differences between PSK31 demodulators On Sun, Jul 20, 2008 at 2:36 PM, Brian Lloyd <[EMAIL PROTECTED]> wrote: > FWIW, my current hypothesis is that there is some high-priority > process that is part of Windows that is causing a problem... The way this problem is addressed under Linux is by using the so-called "rt" version of the kernel, and running the audio subsystem at a higher priority than typical user processes, even though it's running mostly in user space. One reason this is possible is that the window system and many critical system functions also run in user space, even though they might be essentially owned by the system rather than any individual user. The consequence is that, even with a monolithic kernel, routine but high-priority system operations spend a minimal amount of time hogging the kernel. What seems to matter most is the order in which tasks at the same high-priority level are scheduled for service. As long as the audio subsystem gets scheduled often and gets a chance to do its little bit of work ahead of things like paging, journal updates, etc., the audio hums along happily. In any case, the problem doesn't come up in the Linux world at all, at this point. We have had zero problems of this sort since adopting the multimedia configuration guidelines established in UbuntuStudio. Lately I've been running the FireBox at 192k on a slow laptop with 512M, on a loaded system that normally fills out 1.5MB swap space, with nary a glitch in days. 73 Frank AB2KT -- Travelling by airplane in the US is nothing more than mass training of Americans to the requirements of the coming police state. The whole point is to make you learn to acquiesce without question, en masse, to completely absurd directives by dull functionaries wearing uniforms. -- Atrios _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/ _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/
