Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] [ANN] Digital Room Correction (DRC) 2.4.2

by Denis Sbragion

Hello, DRC 2.4.2 has been released and is available at: http://freshmeat.net/projects/drc Changes: This release features better handling of underflow problems during homomorphic deconvolutions. There were some speed improvements. Search and output of peak value and peak position were added to lsconv. Best of listening, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it

21 years, 3 months

[linux-audio-dev] Length of a soundfile in a script

by Hans Fugal

I thought sox might be able to do it but I don't see it if it's there. I want to know how long (in time) an audio file is. Preferably output the number of seconds or some fraction thereof to stdout, and preferably can handle a large variety of sound types like sox (but if not, I can use sox). I know I could use sox to output raw and get the size of the resulting file and do a little arithmetic, but that would be silly if there's a utility for doing this sort of thing. Why? I have my computer as an answering machine, and don't want to be bothered with hangups (very short messages). BTW, an answering machine is great fun to mess with all sorts of audio things, especially the beeps. :-) -- .O. Hans Fugal | De gustibus non disputandum est. ..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach --------------------------------------------------------------------- GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460

21 years, 3 months

[linux-audio-dev] new low latency patch for 2.6

by Thomas Charbonnel

Hi, This is great news, Ingo Molnar strikes back with a low latency patch for 2.6 ! See the original message here : http://groups.google.com/groups?q=Voluntary+Kernel+Preemption+Patch&lr=&ie=… Direct link to the patch against 2.6.7-bk20 : http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H2 Thomas

21 years, 3 months

[linux-audio-dev] Signals and Threads

by Michael Ost

Howdy, list: Does a signal handler (like segfault, or divide by zero) run at the priority of the thread that it gets generated for? Say thread 1 is normal prio and thread 2 is SCHED_RR thread. In normal operation thread 1 can't interrupt or supersede thread 2. Does this hold if, say, thread 1 gets a SEGV signal? Does its handler wait until thread 2 is not running to do its thing? And does it get interrupted if thread 2 wakes up while the handler is working? It would seem that signal handlers use a threads priority, from scanning the web and docs, given that threads have their own signal masks and handlers. But perhaps one of you knows this stuff off the top of your head? I want to improve how our system reacts to a crash, but I'm concerned that the real time audio processing thread will keep the signal handler from reacting promptly. I'm running Linux kernel 2.4.19 with glibc 2.3.2 which provides the libpthread implementation we use to create threads. Thanks in advance for any help... mo ========================= Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com PS: moderator, I tried to remove a similar message sent from another email account, but the 'remove' code didn't work.

21 years, 3 months

[linux-audio-dev] Prony algorithm?

by Dr.Graef＠t-online.de

Hi, does anyone know a library (preferably C/C++, or anything that interfaces to it) which implements the Prony algorithm (a.k.a. least squares fitting of a sampled signal to a sum of damped sinusoids)? TIA Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikwissenschaft.uni-mainz.de/~ag

21 years, 3 months

Re: [linux-audio-dev] Tutorial on Professional Audio GNU/Linux Tools

by Aaron Trumm

And did you find RoseGarden and Ardour we're sync'd up tightly? I have yet to find them REALLY syncing really tightly.... what distro are you on? what versions of the software? what hardware? ------- NQuit www.nquit.com ------- ----- Original Message ----- From: xamat(a)iua.upf.es Sent: 7/8/2004 6:13:42 PM To: linux-audio-dev@music.columbia.edu;developers@lists.agnula.org Subject: [linux-audio-dev] Tutorial on Professional Audio GNU/Linux Tools > > Hi all, > > Today we (I should say Pau Arum?and Maarten de Boer) have given a > tutorial on Professional Audio tools in GNU/Linux in the context of some > conferences on Free Software held near Barcelona, Spain. > > We have showed a great deal of applications. The final demonstration > consisted on reproducing a real professional recording studio situation. > This has been accomplished using Ardour for multitrack recording and > mixing, RoseGarden for MIDI sequencing, Jamin for mastering, qjackctl for > connecting it all and, of course, ALSA. We have recorded live audio tracks > (bass guitar) as well as MIDI from a keyboard controller. Ardour and > RoseGarden have been synchronized and the output of RoseGarden has been > recorded into Ardour. After applying some LADSPA plugins in Ardour, the > final mix has been sent to jamin for the mastering process. All > connections via Jack. > > Everything has worked perfectly so I just wanted to share the success with > all the community and especially congratulate all the developers behind > those great applications and GNU/Linux audio in general. > > ------------------------ > Xavier Amatriain > Music Technology Group > Universitat Pompeu Fabra > www.iua.upf.es/~xamat > -------------------------

21 years, 3 months

[linux-audio-dev] Tutorial on Professional Audio GNU/Linux Tools

by xamat＠iua.upf.es

Hi all, Today we (I should say Pau Arumí and Maarten de Boer) have given a tutorial on Professional Audio tools in GNU/Linux in the context of some conferences on Free Software held near Barcelona, Spain. We have showed a great deal of applications. The final demonstration consisted on reproducing a real professional recording studio situation. This has been accomplished using Ardour for multitrack recording and mixing, RoseGarden for MIDI sequencing, Jamin for mastering, qjackctl for connecting it all and, of course, ALSA. We have recorded live audio tracks (bass guitar) as well as MIDI from a keyboard controller. Ardour and RoseGarden have been synchronized and the output of RoseGarden has been recorded into Ardour. After applying some LADSPA plugins in Ardour, the final mix has been sent to jamin for the mastering process. All connections via Jack. Everything has worked perfectly so I just wanted to share the success with all the community and especially congratulate all the developers behind those great applications and GNU/Linux audio in general. ------------------------ Xavier Amatriain Music Technology Group Universitat Pompeu Fabra www.iua.upf.es/~xamat -------------------------

21 years, 3 months

[linux-audio-dev] ANNOUNCE: BEAST/BSE v0.6.2

by Tim Janik

BEAST/BSE version 0.6.2 is available for download at: ftp://beast.gtk.org/pub/beast/v0.6/ or http://beast.gtk.org/beast-ftp/v0.6/ This is a development version of BEAST/BSE, the BEdevilled Audio SysTem and the Bedevilled Sound Engine. BEAST is a powerful music composition and modular synthesis application released as free software under the GNU GPL and GNU LGPL, that runs under unix. The project is hosted at: http://beast.gtk.org A mailing list is available at: http://mail.gnome.org/mailman/listinfo/beast/ This new development series of BEAST comes with a lot of the internals redone, many new GUI features and a sound generation back-end separated from all GUI activities. Outstanding new features include support for skins, many sample file formats, MIDI file import abilities, an improved piano roll widget, the track editor which allows for easy selection of synthesisers or samples as track sources, loop support in songs and unlimited Undo/Redo capabilities. Overview of Changes in BEAST/BSE 0.6.2: * Rewrote scrollbar sizing, so tracks and parts are easily resizable * Lots of small GUI enhancements and fixes * Added CPU usage information view * Enabled tooltips on menu items * Rewrote logging, messaging and error reporting system * Fixed attack time handling in SimpleADSR * Added support for 1/32, 1/64 and 1/128 notes and quantization steps * Added skin and row highlighting support to the pattern editor * Adjusted skins (pacified some of the more disturbing ones) * Added British English translation [Gareth Owen] * Added Canadian English translation [Adam Weinberger] * Added Brazilian Portuguese translation [Raphael Higino] * Updated Catalan translation [Xavier Conde Rueda] * Updated Czech translation [Miloslav Trmac] * Updated Dutch translation [Tino Meinen] * Updated Croatian translation [Robert Sedak] * Updated Spanish translation [Francisco Javier F. Serrador] * Updated Russian translation [Alexandre Prokoudine] * Updated Portuguese translation [Duarte Loreto] * Updated Albanian translation [Laurent Dhima] * Various sfidl fixes [Stefan Westerfeld, Tim Janik] * First steps taken towards mixer infrastrukture * Fixed user configurable debugging support * Lots of adaptions to GLib/Gtk+-2.4 --- ciaoTJ

21 years, 4 months

[linux-audio-dev] Re: How does ASIO work?

by Ron Kuper

>>> Please specify if you mean per fragment (buffer, usually 2) latency or total latency. <<< Sorry, yes, I mean per-buffer latency. WDM lets buffer sizes get down to 1.5 msec. >>> the Tascam guys that produce Gigastudio, would have dropped their own low latency driver model (GSIF) and would have adopted WDM,ASIO which would ease the pain of integrating Gigastudio with other audio apps. The other theory why they still use GSIF (now they even developed GSIF further by releasing GSIF2) because it would be too time consuming (perhaps they need to rewrite a large section of code to adapt Gigastudio to WDM/ASIO) . <<< When Gigastudio first came out they still needed to support Win95 and Win98. WDM doesn't exist or work very well on these operating systems. Combine this with the fact that Giga does a lot of processing in kernel mode and it's understandable why they needed to invent something like GSIF. They still do work in the kernel, which would also rule out ASIO. ASIO is a user-mode API, not a kernel mode driver model. I'm surprised they don't do WDM today, but I really doubt it's because of some inefficiency in WDM. They can keep all their code in the kernel and still do KS. >>> at any cost. I think one of the best tradeoffs is simply writing VST plugins (or using other plugin APIs) because hosts are usually optimized for low latency audio I/O, can use whatever audio drivers they wish/need and reinventing the wheel for the audio application developer is simply a waste of time. Not to mention that using a plugin API you get perfect integration in a virtual studio. <<< Plugin APIs are different than driver models. You can run VST plugins in ASIO hosts apps, WDM host apps or even MME host apps. If you were developing an audio host app you would need to choose both which driver model you wanted to support, as well as which kind of plugins you want to support. >>> I don't see why WDM should not become the only driver model standard in the windows pro audio world. <<< Totally agree. >>> As said I'm not an expert in low leven windows drivers but I guess WDM is still not perfect so audio apps producers prefer to go their own way to squeeze out the maximum from the hardware (especially for virtual instruments it's very important to achieve low latencies so that the instruments can be played live). <<< In the last few years every pro sound card that's come out has had both WDM drivers and ASIO drivers. Steinberg applications only support ASIO, so if the h/w vendors want to support both Steinberg and others, they need to write both kinds of drivers. It's about being compatible with more applications.

21 years, 4 months

[linux-audio-dev] Re: How does ASIO work?

by Ron Kuper

>>> I am preparing some slides about Linux audio, and while comparing Linux with Windows, I have been wondering how the ASIO drivers manage to obtain low latency on MS Windows, an operating system that does not seem capable of low latency in any other way. So what tricks did Steinberg come up with to get around that? I'd like to be able to say why the Linux approach is better/cleaner. <<< ASIO provides an interface directly to the kernel mode driver, typically through a private device I/O control between the user mode ASIO DLL and the kernel mode driver. By talking right to the driver, they bypass the system component known as KMIXER, which adds 30 msec of latency to all audio in Windows. But ASIO isn't the only way around KMIXER. With the advent of Win32 Driver Model (WDM) Kernel Streaming (KS), the Windows O/S is indeed capable of very low latency. WDM KS has a standardized device I/O control set that's part of the Windows audio stack. KS makes it possible to stream audio at sub 5-msec latency -- approaching 1 msec latency -- using a direct interface to the "miniport" driver in the Windows driver stack. I wrote a white paper about all this a few years back: http://www.cakewalk.com/DevXchange/audio_i.asp There's a diagram of the audio stack in Windows which might be helpful. Note that we never needed to create custom IOCTLs for Windows. Microsoft followed up after this meeting by disclosing the Windows kernel IO controls for everyone to use, known as DirectKS: http://www.microsoft.com/whdc/device/audio/DirectKS.mspx As far as I know the ASIO4All driver is built using DirectKS. ---------- Ron Kuper VP / Engineering Cakewalk http://www.cakewalk.com

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