>From: Jussi Laako <jussi.laako(a)pp.inet.fi>
>
>I haven't got any problems with shared memory,
My alsashmrec with two processes and a lock-free shared memory
buffer has worked fine for a few years. If I were not started
testing and rewriting the tools, I would not have figured out
any problems as well.
> but afterall, I don't use
>the SystemV method (shm* functions) because it sucks. I think the
>SystemV IPC stuff sucks as whole. I like to use the "real" POSIX way..
I would like to test with posix routines as well.
Can you mail me some example code? Plain ascii, no attachments.
If I would have a list of posix shm routines, I would read the
man pages, but then I did read systemv man pages as well, and that
did not help at all. :) Example code would be nice.
Best regards,
Juhana
>From: Ingo Oeser <ingo.oeser(a)informatik.tu-chemnitz.de>
>
>You have synchronisation problems. Shared memory means only that
>it's shared, not that it's synchronized for you. You either need
>to synchronize portably by hand using semaphores or use atomic
>operations.
No, my test indicates that the memory is not *the same* in the two
processes. If "shared memory" is something which is the same only
occasionally, then that is what I have now.
Semaphores or atomic operations has nothing to do with this problem.
>Or you have scheduling problems, if you are disturbed by the
>fact, that the client isn't getting the same amount of CPU as the
>server.
That is better explanation for the slow printing. The shmserver
may be too intensive. However, it is not an explanation for
why the shared memory is not *the same*.
But then, while shmserver was running and shmclient printing,
my simple painting program indicated no slowdowns in painting,
which involves a large brush with computations like sqrt() on
each pixel.
I remember this same problem appeared when I modified XWave
at 1998. The play process (X toolkits background process) wrote
the play line location and the GUI process read the location.
Now that did not involve any unlimited computations as the
processes were bound to D/A converter and to periodic update
of X toolkit.
>> Maybe 20 times per second with "renice 19". Slow.
>
>That's normal. They lock each other out for a whole timeslice,
>since they are CPU-bound. If you want them to schedule at certain
>events (e.g. after one of these computation cycles), you have to
>tell the kernel by using semaphores.
I don't understand. Can you explain how semaphores are used for that?
Best regards,
Juhana
Hallöchen!
Ich bin von der LUG Gießen. Ich möchte gerne anfragen,
ob es von den Audio-Freaks Interesse gibt, einen Stand
auf dem Practical Linux in Gießen zu machen, auch
ein Vortrag oder Workshop wäre nett. Wir haben
neben einer Ausstelung ein ganztägiges Vortragsprogramm
und ein Workshops.
Mehr Infos findet ihr auf www.pracitcal-linux.de
Wir würden freuen wenn das Proejkt bei uns vertreten wäre.
Bye Bye
Lars Stetten
Hi,
This is a message for those who speak spanish and are Linux audio and
MIDI users or developers, from wherever around the globe. Thanks and
sorry for cross-posting.
Free Tools es la primera comunidad en español dedicada a prestar soporte
al usuario y desarrollador de aplicaciones de audio y MIDI para el
sistema operativo Linux.
Todos los interesados en el tema están invitados. Para la suscripción,
de disponerse de cuenta abierta en Yahoo!, basta con visitar este enlace:
http://es.groups.yahoo.com/group/free-tools/
En caso contrario, es suficiente con enviar un mensaje de correo
electrónico en blanco a:
free-tools-subscribe(a)yahoogroups.com
Allà os esperamos.
Regards, Ismael
Hi!
gmorgan is a .. Rhythm Station, an organ with auto-accompaniment and a "small"
Band in a Linux Box. Uses MIDI and the ALSA sequencer for play the rhythm
patterns. Styles, patterns , sounds, and the mixer settings, can be edited
and saved.
Program released GNU/GPL version 2.
News on 0.03
--------------------
- New Drum Pattern Edit
- Added some "demo" patterns and songs.
- Lots of bugs solved.
REQUERIMENTS
--------------------------
Fast Computer
Linux
ALSA
Fltk
Take a look at http://personal.telefonica.terra.es/web/soudfontcombi/
And please ... if you enjoy this prog and wants to share patterns, send me,
and i will include in future versions, i have a large TODO, and i need some
help.
Josep
Hello. I examined further the shared memory malfunction.
Locking the memory with mlockall() did not help: the shared
memory is not updated in the client. I used mlockall() both in
shmserver and in shmclient.
For some reason the shared memory is not a true shared memory.
The shmserver and shmclient do have the shared memory segment
obtained with the same shmid value, but processes seems to
have their own duplicates of it. I have no other explanation.
These duplicates were updated when the shmclient performed sleep(1).
Now I have non-waiting sched_yield() in the shmclient, and that helps.
shmserver is very computation intensive process: it goes through
the whole shared memory and increases the integers there. First
there are 250000 zeros, then 250000 ones, and so on. The client
reads only the first memory location in a loop, and prints out the
value if that value is not yet printed.
What practically happens is that shmserver has enough time to
increase the values multiple times before shmclient gets its
turn to check the values. shmclient does not print values such
as 1234, 1235, 1236 --- the scheduling period is too long for
that. In fact, the shmclient prints the values surprisingly
slow; maybe 20 times per second at maximum.
Without "renice 19" the shmclient prints values in steps of 24 (avg),
and with "renice 19" the shmclient prints values in steps of 2 (avg).
Maybe 20 times per second with "renice 19". Slow.
What this could mean? When an audio software does non-realtime
background computations, the other non-realtime processes could be
in trouble even if they run at different user priorities.
These processes could be a disk server, a GUI, etc.
Question: does the same "shared memory" problem occur with threads?
Intuitively there should not be problems, but never know after what
I have seen.
Best regards,
Juhana
Hello. Can anyone convert the file
http://www.genisis.ch/casimage/DATA/PlayerPRO_Source_Code.sit
to some better archive format? (zip or tar)
I have also other sit/sea/hqx files which I would like to have in
Linux friendly format. All related to audio/graphics open source
development, of course!
Best regards,
Juhana
>Hi Jacob,
>Hi LAD members,
>On Mon, Jul 07, 2003 at 04:50:45PM -0600, jacob robbins wrote:
>> deadlock. You forgot to mention one other method for achieving this
>> communication; System V ipc messages, which i prefer because they don't
>> lock (if used right) and they are simple. See the man pages for msgget,
>> msgsnd, msgrcv.
>What do you mean by "if used right"?
It's pretty simple: The realtime thread must always try to get
messages in non-blocking mode.
Meanwhile, the UI thread blocks waiting for the receipt of a different
message from the realtime thread indicating that the requested issue has
been handled. Of course the issues must be carefully constructed so that
the realtime thread can handle them without allocating any memory or
doing too many long loops.
-jacob robbins.....
On my way to 1.0, I just released v0.99j of BruteFIR, which contains
some new stuff, most notable it now uses FFTW3 instead of FFTW2, and
also supports 32 bit and 64 bit floating point precision in the same
binary.
I've done my usual 10 minute Quality Assurance Testing, and since quite
much has been added, I may have broken some stuff. But since I'm lazy,
I just release and hope for the best to happen, and if anyone stumbles
over a bug, let me know and I'll fix it promptly.
http://www.ludd.luth.se/~torger/brutefir.html
/Anders Torger
Hi,
My appologies for what is probably a naive and confused question...
I need to allow multiple programs/processes to take data from the same
audio device at the same time. My initial imprtession is that audio
devices are still set up only to allow one process to access them at a
time. Is there some way to allow multiple processes to take input from
the same audio device at the same time?
A playback analogy might be how normally you can't have two processes
play8ing data at the same time, but ARTS can take multiple audio streams
and then play them out throug the one device.
Many thanks for any advice you can give...
robert
--
====================================================================
Robert Ross
--------------------------------------------------------------------
Mail FB3, Mathematik-Informatik Deptartment of Mathematics
Universität Bremen & Computer Science
Postfach 330 440 University of Bremen
28334 Bremen P.O. Box 330 440
Deutschland 28334 Bremen
Germany
Phone +49 421 218 7129
Fax +49 421 218-3054
Web http://www.informatik.uni-bremen.de/~robertr
Email robertr(a)informatik.uni-bremen.de
====================================================================