Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] Aqualung mailing list & bugtracker up and running

by Tom Szilagyi

Hi all, the Aqualung project (http://aqualung.sf.net) opened a mailing list for development as well as user discussion. I would kindly invite everyone interested to join the list. I would also like to thank LA list members for their patience. Our list is called aqualung-friends. To subscribe, go to: https://lists.sourceforge.net/lists/listinfo/aqualung-friends The list is members-only. After subscribing, post messages to: aqualung-friends(a)lists.sourceforge.net We are planning to keep the list relatively low-traffic (no cvs diffs, no daily releases), but we would like to have a separate place for discussion so as not to flood the general LA lists with our own troublesome issues. We now also have a Mantis bugtracker available at: http://aqualung.sf.net/mantis I encourage everyone to add bugs, feature requests or whatever. Thanks for all your support, Tom

21 years, 1 month

[linux-audio-dev] Pure Data Trigger Gang Bang 01

by Frank Barknecht

21 years, 1 month

[linux-audio-dev] Re: This better not be patented...

by Juhana Sadeharju

>From: Jens M Andreasen <jens.andreasen(a)chello.se> >> >> http://www.tomshardware.com/hardnews/20040902_135943.html > >As of lately, GPUs have turned into very flexible massive >vectorprocessors. Precision is 32bit floats (but you can trade it down >to get more work done) Yes, it could be that the "invention" implements the algorithms trivially in GPU -- like anyone would implement when getting started in to GPU programming. It is like Nokia mobile connected to the wall power outlet. The Nokia mobile does not take power directly from the wall because that "invention" is patented. Nokia mobile is forced to take power from the battery (which could be next to dead). All this even devices have taken power directly from the wall for decades. GPU is yet another new gear to play with, just like mobiles. Anything can be patented, I'm afraid. >PS: You need not worry about patents for performing an algorithm on a >processor. Especially not when the vendor supplies you with a C-like >languge for doing exactly that. The article says quite clearly that the invention is patented. They would be fools not to try to patent it because the market is huge. >Neat idea, been meaning to try it since the OpenGL2 shader compilers >were released. I have had years this idea of using graphics texture functions to generate audio noises and signals. This app runs naturally on GPU. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

21 years, 1 month

[linux-audio-dev] libao latency

by Thomas Kay

Hi All, I'm trying to develop a custom wav player app using libao - I need to keep the audio latency as small as possible in this project. I was wondering if anybody has done any tests to see how latent libao is for this, or whether I should just throw in the towel now, and move to jack/libalsa? Also I was wondering whether reading each sample at a time from a file is likely to be dropping the real-time ness, or whether people have found that this isn't really such a limiting factor. At the moment it seems quite slow, but then I am developing in vmware- so I guess that adds quite alot of latency!? Tom

21 years, 1 month

[linux-audio-dev] OSC vs MIDI

by Dave Griffiths

Hi all, Ok, so I'm playing with osc (currently doing gui->app communication with it) but all my individual apps still talk midi between them. This is quite cumbersome, as I want to start having lots of controls that midi doesn't support - and I don't really "think" in midi these days anyway. Is there a case now to ditch midi support and go with osc for everything? I see midi messages are a type within osc anyway - is it fairly straight forward to be backwards compatible this way? cheers, dave

21 years, 1 month

[linux-audio-dev] Re: Which API to use for simple clients?

by Andrew Burgess

>I have two Audio related projects that need updating. >Both have existing /dev/dsp style backends at present, which have been working >fine. But recently (SuSE 9.0 install?) when run under ALSA emulation of >/dev/dsp they both started producing segfaults - "after program had exited", >(neither valgrind nor gdb can give any info on the fault). >So I decided it was time to do a native ALSA backend(s). >I have rsynth backend working, and perl Audio:: one almost working. >But before going forward I would like to solicit opinions on what >is the "right" API to use. >(please tell me if I missed any): Portaudio, which gives you macos and windows for free (but of course you must also port the gui stuff...) >2. ALSA >3. JACK Do the callbacks once and it's trivial to port to all three of the above in my experience.

21 years, 1 month

[linux-audio-dev] [ANN] qjackctl 0.2.10 released!

by Rui Nuno Capela

Hi everybody, After the holiday season, and late for the 1st anniversary, here comes another dot release for QjackCtl, the Qt GUI for the JACK Audio Connection Kit: Qjackctl 0.2.10 is out, with some minor enhancements and fixes. >From the change log: - New pre-shutdown script setup option, allowing to specify a shell-script to be run before the JACK server daemon is shutted-down. This overrides any previous shutdown script setting, which should be now moved onto the existing post-shutdown script option, as to keep old procedural behaviour. - Avoid stopping JACK prematurely with QProcess::kill() (oneliner fix); stopping JACK will now take a little bit longer, but hopefully will take the time to cleanup properly (thanks to Kjetil Matheussen). - ALSA driver Duplex mode accepts alternate Input or Output device name. - Context menu reset option is now always enabled (yet another suggestion from Sampo Savolainen). - Main display background gets shinny effect; adjusted system tray background palette color mode. - Priority and setup control is now a spinbox ranging from 0..89 (as suggested by Florian Schmidt). Same for Periods/Buffer. - Patchbay connection lines are now drawn correctly when items are scrolled out of view. Additionally, the connection lines can now be optionally drawn as bezier spline curves (big thanks to Wilfried Huss). Just head to the homepage: http://qjackctl.sourceforge.net or, in case that's not up-to-date yet, to sourceforge's project page: http://sourceforge.net/projects/qjackctl Hope you enjoy. -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

21 years, 1 month

[linux-audio-dev] [ANN] galan-0.3.0_beta7

by torbenh＠gmx.de

hi... i just wanted to announce this bugfix release of galan-0.3.0 this one was a real show-stopper with complex signal routings. get it at http://www.sf.net/projects/galan for those who dont know: gAlan is a powerful modular synth and effects engine, which allows the user to build a custom UI for a synth mesh he has created. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

21 years, 1 month

[linux-audio-dev] Regarding NoteEdit, Finale, and rumor

by Dave Phillips

Greetings: I wrote to Joerg Anders, the author of NoteEdit, and he confirmed that he is leaving off development of NoteEdit. Though I disagree with his assessment of a possible Linux Finale, it's certainly his right to stay with or go away from the helm of NoteEdit development, and he can use any reason he prefers. I have *no* confirmation regarding any Linux development at all from Coda Music, the manufacturers of Finale. Unless someone knows more, I'd say it's an unfounded rumor. I've read that some users have run Finale under Wine: I can get it to open but it doesn't work after that. There's some discussion whether to keep it in AGNULA and whether AGNULA members might want to take over the development of NE. I realize that NE has some possibly irritating dependencies, but I must add that it is a unique Linux music notation editor with a well-evolved set of features and an active user base. I'm uneasy about the implications that mere rumor compelled Joerg to abandon NE, though as I said, I respect Joerg's wishes and his accomplishments with regard to NE. I'm confused as to why Finale's presence might force a developer to consider his own work a closed case. After all, Finale is expensive, closed-source, and not necessarily suited to everyone's work methods. NE is free software, open-source, and works nicely for me. I would hate to see it disappear. Joerg said that since sources are available anyone can continue with NE development. I hope that happens. Best regards, dp

21 years, 2 months

[linux-audio-dev] [ANN] First public alpha of "Louderbox" a multiband squeezer!

by Dan Mills

Hi All, I am pleased to announce that I finally have an alpha release of a louderbox that is (hopefully) reasonably fit to show its face in daylight.... What I have is an 8 band compressor/limiter/clipper/pre em thing written as a jack client. It borrows very heavily from jamin but as fits its intended use butchers far more of the dynamics then would be acceptable in a mastering processor. Excuse the autotools mess, I am still trying to get by head around the horrid things. I Think the dependency list is correct, but do not depend on it. The default startup config needs a lot of work and not all the GUI controls are connected to the DSP core yet. You can see the screenshots (which for some reason seem to matter more then what it sounds like to some people!) and get the code here: http://www.spamblock.demon.co.uk Ps: Sorry Fred, I decided in the end to go with GTK and OSC for remote control. Writing a RML to OSC bridge should be almost trivial however. Like JAMIN (from which it borrows lots of code) this makes heavy use of LADSPA plugins to do most of the real work. Comments, Flames, Patches? Regards, Dan. -- ** The email address *IS* valid, do NOT remove the spamblock And on the evening of the first day the lord said........... .... LX 1, GO!; and there was light.

21 years, 2 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