On Thursday 03 April 2003 15.36, [EMAIL PROTECTED] wrote:
i remember i have read a statement about a lock free ringbuffer
implemented in C somewhere.
Can anybody remeber it ?
Here's one in C; the 'sfifo':
http://olofson.net/mixed.html
I've been using it in various environments for
On Thu, Apr 03, 2003 at 03:14:53PM -0500, rm wrote:
On Thu, Apr 03, 2003 at 11:31:29AM -0800, Tim Hockin wrote:
courtesy of paul davis:
you should use a lock free ringbuffer. we will be adding example code
to the example-clients directory soon. existing code is in
On Fri, Apr 04, 2003 at 12:47:28PM +0200, David Olofson wrote:
On Thursday 03 April 2003 15.36, [EMAIL PROTECTED] wrote:
i remember i have read a statement about a lock free ringbuffer
implemented in C somewhere.
Can anybody remeber it ?
Here's one in C; the 'sfifo':
On Fri, Apr 04, 2003 at 05:03:54PM +0200, [EMAIL PROTECTED] wrote:
The problem i have with the current ringbuffer, is that it does not
solve the synchronization of the non realtime thread to the realtime
thread. what should be done when you cant write to the buffer ?
usleep( a_sensible_value
but how do i handle this sensibly ?
res = sfifo_write(sf, buf, j);
if(res != j)
{
printf(Write failed!\n);
// eeek... no i dont want that...
there are several solutions, none of them particularly good. the best
is to wait on a FIFO. these provide a fast, 99%
On Fri, Apr 04, 2003 at 07:27:57AM -0500, rm wrote:
On Fri, Apr 04, 2003 at 05:03:54PM +0200, [EMAIL PROTECTED] wrote:
so before a writer puts something on the queue to the RT thread it
first dequeues everything returning from the RT thread, and then
enqueues its item. since these items are
below is what i use (i think it works). the primary thing to notice
is that readers and writers are kept in line by the atomicity of
integer assignment (though in general, we should probably declare them
atomic_t or something).
just for completeness sake, this isn't really true. the atomicness of
On Thu, 3 Apr 2003, Tim Hockin wrote:
i remember i have read a statement about a lock free ringbuffer
implemented in C somewhere.
courtesy of paul davis:
you should use a lock free ringbuffer. we will be adding example code
to the example-clients directory soon. existing
On Fri, Apr 04, 2003 at 07:48:20 -0500, Paul Davis wrote:
there is one aspect of the LFRB that bothers me. as has been explained
many times, the monotonic motion of the read/write pointers is
key. but when one the reader/writer moves the pointer to the end of
the buffer and wraps it around,
On Fri, Apr 04, 2003 at 07:48:20AM -0500, Paul Davis wrote:
just for completeness sake, this isn't really true. the atomicness of
int writes/reads isn't central. what is central is (as you noted) the
single (group of synchronous) reader(s) and single (group of
synchronous) writer(s), and the
galan-0.3.0-test2 is released.
galan is a modular synthesizer featuring subpatches, event processing
logic and more.
LADSPA is supported.
you can build your own synthesizer interface, placing controls where you
want them.
I have ported the features added to the galan-0.2 branch up to the 0.3
Greetings:
Just a note to mention that the Karlsruhe report has had 3,871 reads
so far, more than any other article listed except for the Ultimate Linux
Box on-line project. Seems like maybe people are really interested in
what you guys are up to ! :)
Best regards,
== Dave Phillips
On Fri, Apr 04, 2003 at 10:53:05AM -0500, Dave Phillips wrote:
Greetings:
Just a note to mention that the Karlsruhe report has had 3,871 reads
so far, more than any other article listed except for the Ultimate Linux
Box on-line project. Seems like maybe people are really interested in
what you
Hallo,
Dave Phillips hat gesagt: // Dave Phillips wrote:
Just a note to mention that the Karlsruhe report has had 3,871 reads
so far, more than any other article listed except for the Ultimate Linux
Box on-line project. Seems like maybe people are really interested in
what you guys are up
Just a note to mention that the Karlsruhe report has had 3,871 reads
so far, more than any other article listed except for the Ultimate Linux
Box on-line project. Seems like maybe people are really interested in
what you guys are up to ! :)
couldn't be because its on /., could it? :))
++
AGNULA: Call for Python Volunteers
The AGNULA (A GNU/Linux Audio Distribution) is working on the
creation of two entirely Free Software GNU/Linux distributions for
professional audio users based upon Debian
Paul Davis wrote:
Just a note to mention that the Karlsruhe report has had 3,871 reads
so far, more than any other article listed except for the Ultimate Linux
Box on-line project. Seems like maybe people are really interested in
what you guys are up to ! :)
couldn't be because its on
creox 0.2.1 - the realtime sound processor
ChangeLog:
* fixed linking problems with JACK = 0.66
* added Russian translation
* small bug fixes
--
jozef kosoru
Dave Phillips wrote:
One of the complaints was that we absolutely had to support VST and ASIO
for professional acceptance. I had to smile at that one. Yesterday I
read a blurb on a soundfonts site, regarding the new ASIO and the
incredible 27 milliseconds latency. I like the VST plugins I've
oliver thuns wrote:
One of the complaints was that we absolutely had to support VST and ASIO
for professional acceptance. I had to smile at that one. Yesterday I
read a blurb on a soundfonts site, regarding the new ASIO and the
incredible 27 milliseconds latency. I like the VST plugins
On Thu, 2003-04-03 at 21:14, rm wrote:
below is what i use (i think it works). the primary thing to notice
is that readers and writers are kept in line by the atomicity of
integer assignment (though in general, we should probably declare them
atomic_t or something).
Attached is the fifo I've
Attached is the fifo I've had banging about. It uses atomic_t.
OK, I haven't been programming much lately, but when did I miss atomic_t
becoming a part of any C standard?
Also, several people have referred to the atomicity of int/pointer
read/write. This is news to me - can someone point me
OK, I haven't been programming much lately, but when did I miss atomic_t
becoming a part of any C standard?
its not. its a type derived from the kernel headers, which also
defines some basic operations on them. for most common architectures,
they resolve to integer read/write.
Also, several
Also, several people have referred to the atomicity of int/pointer
read/write. This is news to me - can someone point me at the spec for this?
its an architecture-specific issue. its not true on SPARCs and on some
NUMA systems. it has nothing to do with a language per se.
Is it really true
Also, several people have referred to the atomicity of int/pointer
read/write. This is news to me - can someone point me at the spec for this
?
its an architecture-specific issue. its not true on SPARCs and on some
NUMA systems. it has nothing to do with a language per se.
Is it really
25 matches
Mail list logo
