Re: [linux-audio-dev] Prony algorithm?
Es geschah am Sonntag, 4. Juli 2004 23:43 als Albert Graef schrieb: Christian Schoenebeck wrote: I never heard about the Prony algorithm, but if it does what you describe then it's easy to implement, isn't it? Have you tried it? Any problems? Or are you concerned about performance? No, I haven't implemented it yet. That's why I'm looking around for available solutions before trying to do it myself. As Fons already pointed out, the algorithm isn't trivial at all if you want to do it right and in an efficient manner. There are also issues with numerical instability when the input is noisy. Sorry for my naive reply :) , I thought it was just a simple linear least squares problem. CU Christian
[linux-audio-dev] Signals and Threads
Howdy, list: Does a signal handler (like segfault, or divide by zero) run at the priority of the thread that it gets generated for? Say thread 1 is normal prio and thread 2 is SCHED_RR thread. In normal operation thread 1 can't interrupt or supersede thread 2. Does this hold if, say, thread 1 gets a SEGV signal? Does its handler wait until thread 2 is not running to do its thing? And does it get interrupted if thread 2 wakes up while the handler is working? It would seem that signal handlers use a threads priority, from scanning the web and docs, given that threads have their own signal masks and handlers. But perhaps one of you knows this stuff off the top of your head? I want to improve how our system reacts to a crash, but I'm concerned that the real time audio processing thread will keep the signal handler from reacting promptly. I'm running Linux kernel 2.4.19 with glibc 2.3.2 which provides the libpthread implementation we use to create threads. Thanks in advance for any help... mo = Michael Ost, Software Architect Muse Research, Inc. [EMAIL PROTECTED] PS: moderator, I tried to remove a similar message sent from another email account, but the 'remove' code didn't work.
[linux-audio-dev] new low latency patch for 2.6
Hi, This is great news, Ingo Molnar strikes back with a low latency patch for 2.6 ! See the original message here : http://groups.google.com/groups?q=Voluntary+Kernel+Preemption+Patchlr=ie=UTF-8selm=2g8rY-7zF-11%40gated-at.bofh.itrnum=1 Direct link to the patch against 2.6.7-bk20 : http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H2 Thomas
Re: [linux-audio-dev] Signals and Threads
Michael Ost [EMAIL PROTECTED] writes: Does a signal handler (like segfault, or divide by zero) run at the priority of the thread that it gets generated for? Those signals in particular are defined by POSIX to be synchronous, meaning they should be delivered to the thread creating them. Thus the signal context would run at the same priority as the affected thread. Say thread 1 is normal prio and thread 2 is SCHED_RR thread. In normal operation thread 1 can't interrupt or supersede thread 2. Does this hold if, say, thread 1 gets a SEGV signal? Since thread 1 was running, thread 2 must not have been (unless you have a multiprocessor system). Therefore the signal will be delivered immediately at normal priority. Does its handler wait until thread 2 is not running to do its thing? It was not running, though it could at any time... And does it get interrupted if thread 2 wakes up while the handler is working? Yes. It would seem that signal handlers use a threads priority, from scanning the web and docs, given that threads have their own signal masks and handlers. But perhaps one of you knows this stuff off the top of your head? What I don't know for sure is how accurately various Linux kernels implement the standard. I want to improve how our system reacts to a crash, but I'm concerned that the real time audio processing thread will keep the signal handler from reacting promptly. Only if it's using up all the CPU, in which case your system is hung, anyway. :-) -- joq
Re: [linux-audio-dev] new low latency patch for 2.6
On Fri, 2004-07-09 at 20:44, Thomas Charbonnel wrote: Hi, This is great news, Ingo Molnar strikes back with a low latency patch for 2.6 ! See the original message here : http://groups.google.com/groups?q=Voluntary+Kernel+Preemption+Patchlr=ie=UTF-8selm=2g8rY-7zF-11%40gated-at.bofh.itrnum=1 Direct link to the patch against 2.6.7-bk20 : http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H2 Thomas I would like to thank Paul Davis for demonstrating the exact right way to get a problem solved in the free software world. It reminds me of that old Infocom game, 'The Lurking Horror', where one of the first puzzles is, you in a university computer lab late at night with a hacker hacking away, and you have to figure out how to get the hacker to notice you. In the game, the solution involved taking some Chinese food out of the fridge and heating it up in the microwave. Lee
