>After having read many of the threads going on here, it seems that a lot
>of the problems we're facing with i/o latency and cached writes and the
>like deal with the way the kernel handles the filesystem, and trying to
>code around that might not be the best way in a free OS such as ours.
we're
I admit I'm certainly a newcomer to this list, and this is my first post,
but I was wondering...
After having read many of the threads going on here, it seems that a lot
of the problems we're facing with i/o latency and cached writes and the
like deal with the way the kernel handles the filesyste
>Yep, but SHM isn't the only answer. Sockets provide a particularly useful
>implementation.
Sockets still force a data copy and they are bandwidth limited as well
AFAIK. They also don't offer RT characteristics. Try to write a lot
of data to a socket, and the kernel will do a bunch of
non-determ
On Tue, Oct 02, 2001 at 10:55:02AM -0500, Kevin Conder wrote:
> I saw this note on the Csound mailing list and thought I'd forward
> it here. I agree with the point that poorly documented programs are harder
> to use.
Yes. But note that this rant is aimed at a program (actually a python
pac
Oops, you're right of course - brain must have shut down.
Hopefully issues are addressed to an extent in other emails. If all else
fails, the numbered points in the recent big posting are a good start point
for debate, as is the API (if it makes sense to folk). What I find
interesting is that so
On Tue, 2 Oct 2001 08:22:01 -0500 (CDT)
dave willis <[EMAIL PROTECTED]> wrote:
> i don't know much about c, and am wondering if anyone has recommendations
> on books for learning c for unix/linux, as well as for audio.
Well for a rank beginner with C, you might like to try a book I co-authored
On Tue, 2 Oct 2001, Richard W.E. Furse wrote:
> > -Original Message-
> [...]
> > It is certainly true that there is only one type of "exchange" currently
> > written for JACK, and that is for low-latency PCM. This does not mean that
> > the API is not suitable for other types of connectio
> On Mon, 1 Oct 2001, Paul Davis wrote:
>
> > > 1. Package early and often.
> > Unless you don't feel your codebase is ready for users that don't know
> > their way around gdb and a C++ compiler.
>
> The original thread was about how to make Linux audio applications
> more accessible to non-progra
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis
> Sent: 30 September 2001 19:02
> To: [EMAIL PROTECTED]
> Subject: Re: [linux-audio-dev] LADMEA revisited (was: LAAGA and
> supporting programs)
>
>
> First of all, I'd like to thank Richard
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis
> Sent: 01 October 2001 17:32
> To: Richard Guenther
> Cc: [EMAIL PROTECTED]
> Subject: Re: [linux-audio-dev] LADMEA revisited (was: LAAGA and
> supporting programs)
[...]
> However, as I poi
> 4) "Think you know pro-audio on Linux? You don't know JACK!" is just
> too good to pass up, even for people like myself for don't watch
> TV in the USA :)
Tempting fate: there's also "Windows has Rewire, Linux has Jack." ;-)
Having said that, LAIC is plain obscure. Can't we just get th
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Karl
> MacMillan
> Sent: 29 September 2001 23:37
> To: [EMAIL PROTECTED]
> Subject: Re: [linux-audio-dev] LADMEA revisited (was: LAAGA and
> supporting programs)
[...]
> It is certainly true that there
Pardon me but...
How about SoftWire?
This name has a few things going for it.
It has a play on words. (software - softwire)
Its name and meaning are the same. (software wire)
It conforms to the probable next-generation hardware interconnect name.
Stand-alone hardware boxes will be connected wit
On Mon, 1 Oct 2001, Paul Davis wrote:
> > 1. Package early and often.
> Unless you don't feel your codebase is ready for users that don't know
> their way around gdb and a C++ compiler.
The original thread was about how to make Linux audio applications
more accessible to non-program
I saw this note on the Csound mailing list and thought I'd forward
it here. I agree with the point that poorly documented programs are harder
to use.
Note: I am Kevin Conder in Chicago and this is Kevin Parks in
Seoul, Korea. I took the liberty of adding some paragraph breaks to
While I'm not too sure about a book for audio programming, I highly
recommend "Practical C Programming", published by O'Reilly. It's easy
to follow and provides a nice introduction to the unix programming
environment.
-- Mike
On Tue, Oct 02 @ 08:22, dave willis wrote:
> i
Here is what made me come up with this idea
[LAIC(LinuxAudioInterConnection)=layman]:
Subject: Re: [linux-audio-dev] LADMEA Prototype
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Aug 14 2001 - 15:55:55 EEST
...
last night, i thought of an analogy/metaphor) to illustrate the
difference between the
i don't know much about c, and am wondering if anyone has recommendations
on books for learning c for unix/linux, as well as for audio. i wish to
maybe help a bit with the alsa driver, but mainly learn how to program
audio/midi apps using alsa.
thanks,
dave
My two cents:
in french 'LAIC' is quite opposed to 'religious' (example: 'a laic school').
Well I prefer 'JACK' . Better for musicians.
On Mon, 1 Oct 2001 16:08:42 -0700
"STEFFL, ERIK *Internet* (SBCSI)" <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: David Gerard Matthews
19 matches
Mail list logo
