On Thu, 2002-03-21 at 16:13, Rene Rebe wrote:
> You can add GSMP to the list of "multi-channel" and "full-duplex by
> design" applications.
>
> http://drocklinux.dyndns.org/rene/gsmp/
Thanks for the note, Rene.
>From what I read on that page, you use shared objects for plugins and
effects -- i
On Thu, 2002-03-21 at 15:49, Paul Davis wrote:
> ALSA already has support for zero-copying I/O, via its mmap mode.
Thanks for your reply, Paul. I'm not as familiar with ALSA as I should
be, but I did know about mmap mode and its performance implications. I
hadn't assumed that the latency betwe
Slashdot just posted an interesting article on preempt and low-latency
patches and their performance. It seems the best results are when both
of them are applied. This might be old news for some of you, but I still
feel that many will benefit from this article. Check it out here:
http://www.linux
jfm3 wrote:
>
> I have made a big upgrade to www.pure-data.org, a web site for the Pd
> user and developer community.
Nice Job, found it quite by chance, and am happy to see it...
Mike
On Thu, 21 Mar 2002, Paul Davis wrote:
> i noticed from luca's initial report on firm timers that switching the
> caps lock LED on and off is a notable source of latency in the
> kernel, on the order of 7msec.
Seems odd. I would have expected the LED to be handled in the keyboard's
hardware. M
I have made a big upgrade to www.pure-data.org, a web site for the Pd
user and developer community. It's only been up for two days, and we've
already had hundreds of users utilize it's collections of links and
information. Please go there, register, and use the "Download", "Web
Links", and "Submit
>> (the term "PCM" is OK once you get into this
>> stuff, but ...).
>
> How about adding PCM to your Terminology section then?
Done.
>> The following document represents it current state. I
>> would like to ask for feedback even though it is very incomplete.
>
> What is the license
>if someone is interested, I just prepared a small web page about firm
>timers: http://www.cse.ogi.edu/~luca/firm.html On this page, you can
>find a small paper describing some experiments and a kernel patch
>implementing firm timers.
fantastic work! this looks like the KURT patch done in a way t
>I wrote a little program to test the accuracy of clock_nanosleep
>under linux. Running SCHED_FIFO at the highest priority I did
> an absolute clock_nanosleep()
on an unmodified kernel (regardless of the presence of latency
patches), i think it would be odd to expect that clock_nanosleep() to
be
On Thu, Mar 21, 2002 at 02:47:41PM -0800, Paul Winkler wrote:
> hmm, wonder if that works :)
Nope.
#include
#include
main() {
int res = 44100 ;
int length = res * 1 ; // 1 second
int hz = 440 ;
int amp = 24000 ;
int x ;
short out ;
i noticed from luca's initial report on firm timers that switching the
caps lock LED on and off is a notable source of latency in the
kernel, on the order of 7msec.
several people have noted problems with this either on ardour-dev or
on LAD, and i just wanted to assure them that they are not imag
Hi all,
Erik Walthinsen wrote:
[...]
> Yes, there are things called 'firm timers' that use the IO-APIC to
> (transparently) give applications extremely high resolution on longer
> sleeps. I've cc:'d the guy who's been working on the patch most
> recently, maybe he's got a draft of his paper he's
One word: Beautiful!
Ico
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:owner-linux-audio-
> [EMAIL PROTECTED]] On Behalf Of Paul Davis
> Sent: Thursday, March 21, 2002 4:31 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [linux-audio-dev] initial (incomplete) version o
On Thu, 21 Mar 2002, Paul Davis wrote:
> prompted by phil kerr this morning, i started writing a tutorial on
> using the ALSA Audio API
Great!
> (the term "PCM" is OK once you get into this
> stuff, but ...).
How about adding PCM to your Terminology section then?
> The follow
On Thu, Mar 21, 2002 at 04:31:06PM -0500, Paul Davis wrote:
> I would appreciate it if anybody has any ideas on a really simple
> way to get the playback examples to make a nice noise without
> burdening the examples with either waveform generating code and/or
> calls to some kind of audio file li
Hi.
On: Thu, 21 Mar 2002 16:49:10 -0500,
Paul Davis <[EMAIL PROTECTED]> wrote:
> For throughput issues, Ardour and Ecasound are probably the two most
> obvious candidates, because they are designed from the ground up
> around dealing with multichannel audio interfaces and full duplex
> opera
On Thu, 2002-03-21 at 13:47, Martijn Sipkema wrote:
> Is there something that can be easily done about the bad
> performance of clock_nanosleep at long sleep times?
Yes, there are things called 'firm timers' that use the IO-APIC to
(transparently) give applications extremely high resolution on l
>The kinds of improvements we're going to investigate at first are
>comparatively simple: zero-copying I/O, a fast path to the kernel
ALSA already has support for zero-copying I/O, via its mmap mode. I
suspect that you may not understand as much as you might want to about
how this model of acces
I wrote a little program to test the accuracy of clock_nanosleep
under linux. Running SCHED_FIFO at the highest priority I did
an absolute clock_nanosleep() followed by a clock_gettime() and
took the difference. I noticed that when using a short sleep time
the results were very good, but when usi
Greetings,
My name is Will Benton and I'm a CS grad student at Wisconsin. I've
been reading l-a-d and l-a-u for a while, but have only posted a
couple of times IIRC. I apologize if this message is a little long --
but please read and reply; there may be something in it for you in a
few months.
prompted by phil kerr this morning, i started writing a tutorial on
using the ALSA Audio API (the term "PCM" is OK once you get into this
stuff, but ...). The following document represents it current state. I
would like to ask for feedback even though it is very incomplete. I
have not tested any o
Steve Harris wrote:
>On Sat, Mar 16, 2002 at 04:54:03 -0500, Paul Davis wrote:
>> >my proposal for a remedy is rather simple: let control port value
>> >pointers not point to one LADSPA_Data but to an array of two.
>> >
>> >the first represents the start, and the second the end value for the
>> >
On Thu, 21 Mar 2002 16:57:35 +
Phil Kerr <[EMAIL PROTECTED]> wrote:
> Part of the problem is the lack of Alsa specific MIDI tutorials. People
> still use this method because there is generally more examples they can
> find to get them started.
>
> The answer is we need more Alsa specific co
Hi,
On Wed, 20 Mar 2002, Nathaniel Virgo wrote:
> I've asked this before on LAU, but I'd really like to know the answer because
> I'm thinking of writing my own if there isn't. It'll be my first midi app --
> is there a book that can teach me what I need to know to program with midi on
> linux?
>> plm is designed as a *hardware* patcher/router. unless the author had
>> unusually flexible insight
>
>using open() and read() is unusually flexible? :)
its amazing how many Linux MIDI software includes stuff like:
open ("/dev/midi", )
or
#define MIDI "/dev/midi"
--p
Part of the problem is the lack of Alsa specific MIDI tutorials. People
still use this method because there is generally more examples they can
find to get them started.
The answer is we need more Alsa specific coding examples.
LAD's post your tutorial links here?
Phil
Paul Davis wrote:
>
On Thu, Mar 21, 2002 at 07:09:45AM -0500, Paul Davis wrote:
> >Maybe plm is what you want:
> >http://member.nifty.ne.jp/Breeze/softwares/unix/index.html
> plm is designed as a *hardware* patcher/router. unless the author had
> unusually flexible insight
using open() and read() is unusually flexib
On Thu, 21 Mar 2002, Paul Davis wrote:
> >A nice intro to writing MIDI apps using C/C++ can be found below:
> >http://ccrma-www.stanford.edu/~craig/articles/linuxmidi/
>
> IMHO, this is a dangerous introduction for one very important reason.
>
> its discussion of kernel scheduling for MIDI I/O
Richard Snow wrote:
>
> unsubscribe instructions please?
http://www.linuxdj.com/audio/lad/subscribe.php3#subscription
>
>On Wed, Mar 20, 2002 at 08:55:31PM +, Nathaniel Virgo wrote:
>> does anyone know if an app exists that can open a midi port and then, for
>> instance, send channel 1 to the external midiport and all the rest to a
>> virmidi port?
>
>Maybe plm is what you want:
>http://member.nifty.ne.jp/B
>A nice intro to writing MIDI apps using C/C++ can be found below:
>
>http://ccrma-www.stanford.edu/~craig/articles/linuxmidi/
IMHO, this is a dangerous introduction for one very important reason.
its discussion of kernel scheduling for MIDI I/O is about the OSS
sequencer. The OSS sequencer is a
I read:
> does anyone know if an app exists that can open a midi port and then, for
> instance, send channel 1 to the external midiport and all the rest to a
> virmidi port?
should be very easy to do in pd and can then be run -nogui and remote
controlled via tcp/udp sockets.
OTOH pd might be a
Hi Nathaniel,
A nice intro to writing MIDI apps using C/C++ can be found below:
http://ccrma-www.stanford.edu/~craig/articles/linuxmidi/
Regards
Phil
Nathaniel Virgo wrote:
>
> Hi everyone,
>
> does anyone know if an app exists that can open a midi port and then, for
> instance, send channe
33 matches
Mail list logo
