Re: [linux-audio-dev] A Python loop sequencer, was re: using csound as a sampling engine

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] A Python loop sequencer, was re: using csound as a sampling engine
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ke syys   08 1999 - 10:45:28 EDT


On Mon, 06 Sep 1999, Paul Winkler wrote:
> A big question is whether a python script is even capable of
> REALLY accurately timing its output. The built-in time and sched
> modules are probably what I'll end up using. Try them! How fast
> are they?

I do not know python, but interpreted scripts are much slower than
C/C++ code, don't expect 1msec precisions.

> Do some experiments. Can't find anything on dejanews about this.
> For my purposes, timing resolution down to 1 msec is probably
> plenty. I bet 10 msec would even be useable for a lot of stuff
> (though probably ultimately frustrating).
>
> This all probably depends on the speed of getting stuff into and out of
> the
> FIFO or pipe...
>
> If this proves to be unworkable, is there any other (faster) way to get
> realtime events to Csound? Some sort of IPC? I don't think so.
> Somebody was working on reading k-rate values in realtime from X11
> scrollbars, but I don't know if they ever finished it, or if it could
> be used for "i" events...

I don't know the performance of named pipes, but
i benchmarked the IPC functions msgsnd() , msgrvc()
and was able to send about 45000-90000 short messges, between 2 processes
therefore the delay is around 15-30usecs (on my PII400).

Pipes uses usually 4k buffers, and maybe you are experiencing buffering/flushing
problems.

>
> Or if Python is the source of timing problems, could I implement the
> core event-sending mechanism in C? I don't want to have to do
> this... In fact, I'm NOT going to do that. If the feasibility test
> fails, the project will probably die. let's hope it works.

I'm not very confident that Python will be suitable for RT apps,
especially music that require precisions in the 1-5ms range for
stable timing + low-latency.

I think sooner or later we should all join our efforts and contribute
to the Audiality project (with first versions running in userspace on
ordinary Linux kernel , then on RT-Linux with sub 1msec lanecies).

Audiality will be designed with realtime, flexibility, efficiency and
scalabitily in mind.

In future, designing an audio app will be more a GUI programming task
than re-implementing audio-engines evertime from scratch.

For example oolabola could be almost a GUI app which calls
audiality modules and connect them together.
For example:
- open 2 instances of the wave-streamer plugin (will be capable of stream
audio from disk)
- wire the wave streamers to 2 resampler-plugins (do change pitch)
- send the results to 2 equalizers and finally mix together the audio.

The user could then easily feed the oolabola output to a track of a harddisk
recording app.
If you want to use your high quality EQ in your preferred
audio-app, just load the plug-in and replace your standard EQ.

regards,
Benno

--
Benno Senoner
E-Mail: sbenno_AT_gardena.net
Linux low-latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:11 EST