't be "tweaky" if you know what I mean. The product only
needs to support a couple of sound cards, though, so it won't have to
target lots of hardware.
Thanks for any feedback,
Michael Ost
Muse Research, Inc.
___
Linux-audio-dev mai
Paul Davis wrote:
> On Tue, Jan 12, 2010 at 1:15 PM, Michael Ost wrote:
>> Hi,
>>
>> We are considering using PortAudio for Linux hardware support (and
>> Windows/Mac as well). What's the word on the quality, reliability,
>> ease-of-programming, latency a
Paul Davis wrote:
> On Tue, Jan 12, 2010 at 1:29 PM, Michael Ost wrote:
>> Paul Davis wrote:
>>> On Tue, Jan 12, 2010 at 1:15 PM, Michael Ost
>>> wrote:
>>>> Hi,
>>>>
>>>> We are considering using PortAudio for Linux hardware support
Olivier Guilyardi wrote:
> On 01/12/2010 07:15 PM, Michael Ost wrote:
>> We are considering using PortAudio for Linux hardware support (and
>> Windows/Mac as well). What's the word on the quality, reliability,
>> ease-of-programming, latency and performance in Linux?
any help,
Michael Ost
Muse Research, Inc.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Paul Davis wrote:
On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost wrote:
Hi list,
I am seeing what appears to be a 4 - 7 usec context switch time on a 3 GHz
Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66 GHz
Atom. Is that reasonable? Does anyone have any tips on how to speed
f...@kokkinizita.net wrote:
On Tue, Nov 02, 2010 at 10:17:30AM -0700, Michael Ost wrote:
Ah, so no magic bullet then! %) This makes sense. Thanks for your response.
One thing to look at is if you really need all those context switches.
That would be the case only if all the VST plugins are
On 11/2/10 10:06 AM, Paul Davis wrote:
On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost wrote:
Hi list,
I am seeing what appears to be a 4 - 7 usec context switch time on a 3 GHz
Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66 GHz
Atom. Is that reasonable? Does anyone have any
Paul Davis wrote:
On Wed, Nov 10, 2010 at 1:39 PM, Paul Davis wrote:
On Wed, Nov 10, 2010 at 1:15 PM, Michael Ost wrote:
I asked Alexandre Julliard, the maintainer of the Wine project, about the
libfst approach, and thought this list might be interested in his response.
- Michael Ost
unrelated threads? Are
there just too danged many SCHED_RR threads fighting for two cores?
Anyone have any suggestions for how to trace the scheduler, and thread
or process interruptions?
Apologies for the lengthy post, but this is a tricky subject.
Thanks for any tips or insights,
On 10/08/2011 04:02 AM, Clemens Ladisch wrote:
Michael Ost wrote:
The higher priority threads in the system are:
...
* IRQ8 (rtc) - FIFO/99
Why does this interrupt get such a high priority?
(Not that it matters as I don't expect it to be used at all ...)
No, it isn't used. This is
On 10/07/2011 08:07 PM, Robin Gareus wrote:
On 10/08/2011 03:25 AM, Michael Ost wrote:
Hi list,
We are seeing unexpected interruptions of SCHED_RR audio processing
threads, and are struggling to understand why they are happening. Does
anyone have any good tips or tools to suggest to help
> On 10/07/2011 07:46 PM, Devin Anderson wrote:
On Fri, Oct 7, 2011 at 6:25 PM, Michael Ost wrote:
We are seeing unexpected interruptions of SCHED_RR audio processing threads,
Wow, a painful response. It's taken me all weekend to figure out how to
reply. :(
First, I think
sync'ing primitives. That isn't happening
when I get these unusual latencies. So for my particular case the answer
is "yes". Cool.
Thanks for the reply,
Michael Ost
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.or
On 10/10/2011 03:04 PM, Clemens Ladisch wrote:
Michael Ost wrote:
Have you ever seen "migration" or "watchdog" hold the CPU for any length of
time?
This shouldn't happen.
I was curious about "migration" since
/proc/sys/kernel/sched_migration_cost =
On 10/11/2011 01:52 AM, Clemens Ladisch wrote:
I wrote:
What is the time quantum that sched_rr_get_interval() returns for these
threads?
Bah, the documentation of sched_rr_get_interval() is wrong; the kernel
uses a fixed RR time quantum of 100 ms which cannot be changed (except
by changing DEF
On 10/11/2011 03:10 PM, Paul Davis wrote:
On Tue, Oct 11, 2011 at 5:33 PM, Michael Ost wrote:
We have gotten some interesting results from cyclictest and the new ftrace
system. Hopefully that will point us to some kernel latency that we can work
around or fix.
it would be really great if
> On 10/07/2011 08:07 PM, Robin Gareus wrote:
It's a bit dated but so is your 2.6.24.3 kernel. You will need to
compile the kernel with CONFIG_PREEMPT_TRACER=y CONFIG_SCHED_TRACER=y
under "Kernel hacking -> Tracers -> .." to get access to
/sys/kernel/debug/tracing/
I've got some output, but a
On 10/11/2011 03:10 PM, Paul Davis wrote:
On Tue, Oct 11, 2011 at 5:33 PM, Michael Ost wrote:
We have gotten some interesting results from cyclictest and the new ftrace
system. Hopefully that will point us to some kernel latency that we can work
around or fix.
it would be really great if
19 matches
Mail list logo
