Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] lash subversion repository

by Bob Ham

Hi all, Just a note to say that a lash subversion[0] repository is up at svn://svn.lash-audio-session-handler.org/lash/lash/trunk It's currently uncompilable, but that'll change :) Bob [0] http://subversion.tigris.org/ -- Bob Ham <rah(a)bash.sh>

21 years, 6 months

[linux-audio-dev] Fwd: open hardware, Linux

by Luke Yelavich

Forwarding this to mailing lists where others may be interested. >Envelope-to: luke(a)audioslack.com >From: Vedran Vucic <vvucic(a)eunet.yu> >To: audioslack-users(a)audioslack.com >Date: Sat, 8 May 2004 13:44:53 +0000 > >Dear colleagues, > >A good friend of mine started project creating open audio card and possibly >he is interested to find people who can maybe contribute to idea of opencores >and open hardware having in mind that his project is related with audio >recording and editing. > >www.opencores.org/projects.cgi/web/fac2222m/overview > >I think that such an effort may be very important contribution to efforts all >we are committed. > >Best wishes, > >Vedran Vucic -- Luke Yelavich http://www.audioslack.com luke(a)audioslack.com

21 years, 6 months

[linux-audio-dev] Re: audio application design problem

by Juhana Sadeharju

>From: Christian Henz <chrhenz(a)gmx.de> > >So far I've been using an Observer pattern Are all these patterns described somewhere in the web? People refers mostly to some book(s) but that is not available for me. >Surely one doesn't want the audio thread to execute widget redraws. >So one has to de-couple these mechanisms, for example by defining >event and update messages and passing those around by FIFOs instead >of direct parameter manipulation / direct GUI callbacks. The audio thread should not execute even indirectly any GUI code. If you send commands from audio thread to GUI thread, the GUI thread should not execute each command "as is". If the audio thread sends commands at too fast rate and GUI thread processes each of them, the system breaks. So, the de-coupling must happen at greater level than at basic threading level. I would set up the graphics engine to run at constant frame rate; say, 30 frames per second which is enough for our eyes. Then I would set the audio thread to send events at most at rate 30 times per second. GUI thread should process as many events at a time as possible. In practise, the fixed frame rate would be an upper bound for the actual rate; rate could be 10 Hz if there is a lot of drawing --- that is why the events must be processes in "as many as available" manner and some multiple events may require skipping. In simplest, the fixed rate GUI could peek at the variables of the audio thread; no FIFO. Using any frame rate bound in non-video-player applications is something I have not seen before. I use this kind of fixed frame rate in my little experimental painting software. E.g., GIMP don't work that way. -*- How Ardour and other realtime applications do it? What if one uses a volume meter plugin with small buffer size? Would the plugin be executed, e.g., 200 times per second and at each time would GUI be changed? Not a good idea. Has this problem dealt in GMPI discussions? Regards, Juhana

21 years, 6 months

[linux-audio-dev] info request - users of Edirol UA-5

by Alfons Adriaensen

Hello, if there are any users of the Edirol UA-5 USB interface out there, I'd like to hear from you ! TIA -- Fons

21 years, 6 months

Re: [Agnula-Users] Re: [linux-audio-dev] Request to audio related LiveCD packagers

by Andrea Glorioso

>>>>> "Tom" == Tom Kerswill <tomkerswill(a)f2s.com> writes: > As a musician and user of the software, I think that it is more > important to get maximum useability and practicallity out of the > software. At the moment most musicians are paying for Microsoft > Windows software, because there is not an alternative that > supports their hardware. That's the most pressing problem. If > there are free alternatives in development, then use them, but > if there is no alternative, then it is most important to support > a wide range of equipment and reach as many potential users as > possible. Tom, please notice that this is a matter of distribution. The fact that A/DeMuDi doesn't come with the firmware doesn't mean the user can't simply download the firmware itself (not that I particularly like this solution). Of course this can't be done on the Live CD until you install it on the hard disk (if you feel like doing it) but then again I very much doubt you can do serious low-latency work directly from CD - anybody correct me if I'm wrong. bye, -- Andrea Glorioso andrea.glorioso(a)agnula.org AGNULA Technical Manager http://www.agnula.org/ M: +39 333 820 5723 F: +39 (0)51 930 31 133 "Libre Audio, Libre Video, Libre Software: AGNULA"

21 years, 6 months

[linux-audio-dev] [ANN] AlsaModularSynth 1.8.1

by Matthias Nagorni

Hello, a new version of AlsaModularSynth is available from Sourceforge. Note: Remember to download the latest version of the LADSPA plugins by Fons Adriaensen: http://users.skynet.be/solaris/linuxaudio Otherwise the latest instrument patches just won't work ! News: - Added hplp_instrument.ams which demonstrates the new highpass filter by Fons Adriaensen. Due to the HPLP combination, the presets of this patch are quite close to some of the famous "Switched-On Bach" sounds by W. Carlos. - Added sinfonia.mid for your own experiments with hplp_instrument.ams - Fixed bug in LADSPA module where uninitialized output control ports have caused segfaults. - Several small corrections in demo patches. For more news check the respective section on the project page. Have fun ! Matthias -- Dr. Matthias Nagorni SuSE Linux AG Maxfeldstr. 5 phone: +49 911 74053375 D - 90409 Nuernberg fax : +49 911 74053483

21 years, 6 months

[linux-audio-dev] regarding mobos and CPUs

by Dave Phillips

Greetings: A client has asked me to get some opinions regarding AMD CPUs and recommended motherboards. He's planning to replace an SMP system that has apparently never worked quite right. He doesn't want another SMP mobo, and a friend is advising him to go with a uniprocessor system built around a recent AMD CPU. The recent JACK problem with AMD CPUs was a revelation for me: I'd never had any problems with AMD chips, but now I'm feeling reluctant to recommend them. Am I just being paranoid, or are there particular reasons to go with Intel instead of AMD ? My client is considering a P4 instead of the AMD, hence this infoquest... Also, what's a recommended motherboard ? Are there any mobos that should definitely be avoided ? TIA for any help you guys can proffer, it's much appreciated. Best regards, dp

21 years, 6 months

Re: [linux-audio-dev] regarding mobos and CPUs

by Taybin Rutkin

What is the problem with JACK and AMD cpus? I haven't heard of one. Personally, I have an nvidia nforce2 motherboard which has worked fairly well for me. Taybin -----Original Message----- From: Dave Phillips <dlphilp(a)bright.net> Sent: May 6, 2004 10:44 AM To: LAD Mail <linux-audio-dev(a)music.columbia.edu>, LAU Mail <linux-audio-user(a)music.columbia.edu> Subject: [linux-audio-dev] regarding mobos and CPUs Greetings: A client has asked me to get some opinions regarding AMD CPUs and recommended motherboards. He's planning to replace an SMP system that has apparently never worked quite right. He doesn't want another SMP mobo, and a friend is advising him to go with a uniprocessor system built around a recent AMD CPU. The recent JACK problem with AMD CPUs was a revelation for me: I'd never had any problems with AMD chips, but now I'm feeling reluctant to recommend them. Am I just being paranoid, or are there particular reasons to go with Intel instead of AMD ? My client is considering a P4 instead of the AMD, hence this infoquest... Also, what's a recommended motherboard ? Are there any mobos that should definitely be avoided ? TIA for any help you guys can proffer, it's much appreciated. Best regards, dp

21 years, 6 months

Re: [linux-audio-dev] regarding mobos and CPUs

by Taybin Rutkin

Yes, that was just an autotools problem. It could have happened to a P4 if jack was built on an AMD box. It was more of a cross-compilation issue. Taybin -----Original Message----- From: Dave Phillips <dlphilp(a)bright.net> Sent: May 6, 2004 11:20 AM To: The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu>, LAU Mail <linux-audio-user(a)music.columbia.edu> Subject: Re: [linux-audio-dev] regarding mobos and CPUs Taybin Rutkin wrote: >What is the problem with JACK and AMD cpus? I haven't heard of one. > > > Not so long ago a release of qjackctl in Planet C failed due to (IIRC) JACK getting compiled with an SSE call (or calls) that killed it completely on my Duron. The problem was simply and quickly solved, and I'm perhaps off-base accusing JACK but that's where the problem came from. Maybe it was a bad make ? Anyway, if it's the opinion of the LAD developers that AMD is OK then that's what I need to know. As I stated, I've had only that one difficulty with AMD and Linux audio software, so I think I'm just being paranoid. Best, dp

21 years, 6 months

[linux-audio-dev] Re: [PlanetCCRMA] The Linux FreeVSTi Compatibility List

by Christian Frisson

Hi, Kjetil Svalastog Matheussen wrote: > Very nice work. However, I think you may have misunderstood how the > vstserver works: > > The vstserver does actually work by setting up a bounch of processes and > threads, and are very very far from being single-threaded. There are no > limitations on how many vsti's you run simultaniously. My apologies... My dev knowledge is too low to be mentionned. Additionally, French people like me don't always speak English very well ,-) I've definitely made this thread confusion during my tests, as I tried to launch two plugins simultaneously, both with vsti, and had VSTserver return errors... Had just another go today, works perfectly! Mea culpa. When it comes to limit the number of opened console windows, how should I define my paths correctly system-wide? On Fedora Core 1 - seems to be relevant in this case - appending "export VST_PATH=..." to the file /etc/profile and sourcing it afterwards does only define the path for console use. When using the launcher (Alt+F2) to start plugins with "vsti plugin_name", it doesn't seem to recognize VST_PATH. > The difference between the vstserver and the new fst-library made by > Torben Hohn and Paul Davies is that the fst-library runs the vst-plugin > in the same process, while using the vstserver-system you run the > vst-plugin inside a new process set up by the vstserver. > > What this means is that you get less contex-switches and therefor > better performance when running many (something like more than 8 according > to Paul) vst-plugins simultaniously using the fst-library. What kind of features are already planned for the next releases of both projects? Cheers, Christian

21 years, 6 months

Jump to page:

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