Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7541 discussions

Re: [linux-audio-dev] wxWindows and Linux distros ?

by Stefan Nitschke

AFAIK, Debian stable (woody) includes wxGTK 2.2.9. Stefan >From: Dave Phillips <dlphilp(a)bright.net> >Reply-To: linux-audio-dev(a)music.columbia.edu >To: LAD Mail <linux-audio-dev(a)music.columbia.edu>, LAU Mail ><linux-audio-user(a)music.columbia.edu> >Subject: [linux-audio-dev] wxWindows and Linux distros ? >Date: Wed, 16 Jul 2003 11:33:10 -0400 > >Greetings: > > I couldn't find the answer to this one on Google, so: > > Which Linux distributions include wxWindows in their default >installations ? > >Best regards, > >== dp http://www.linux-sound.org/rtsynth _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

22 years, 7 months

Re: [linux-audio-dev] Re: Shared memory

by Juhana Sadeharju

>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

22 years, 7 months

Re: [linux-audio-dev] Re: Shared memory

by Juhana Sadeharju

>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

22 years, 7 months

[linux-audio-dev] Anfrage Practical Linux 2003 Gießen

by Lars Stetten

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

22 years, 7 months

[linux-audio-dev] A message for spanish users and developers

by Ismael Valladolid Torres

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

22 years, 7 months

[linux-audio-dev] gmorgan-0.03

by holborn

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

22 years, 7 months

[linux-audio-dev] Re: Shared memory

by Juhana Sadeharju

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

22 years, 8 months

[linux-audio-dev] PlayerPro source?

by Juhana Sadeharju

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

22 years, 8 months

Re: [linux-audio-dev] It's been more than a year... Have things improved?

by jacob robbins

>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.....

22 years, 8 months

[linux-audio-dev] BruteFIR v0.99j released

by Anders Torger

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

22 years, 8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev