Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] Noise reduction with FFT

by Spencer Russell

I've got this really noisy audio file I'm trying to clean up, and I was thinking, it would be really cool if I could run a clip of the file that was just the noise(it's a recording of a discussion for a TV broadcast, so when no one's talking, it should be silent) and have the program output an average frequency content, in some sort of format that another program could take it as input and create a filter that would filter out those frequencies. It seems like brutefir would be able to do the latter part, but is there a way to automatically generate the filter definition from the frequency content of a file? Is this a feasable method of noise reduction? If it seems like it could work, but there isn't a program to do it, I would be interested in writing it, if anyone has any input. Thanks! -spencer

20 years, 5 months

[linux-audio-dev] arts development discontinued...

by Joern Nettingsmeier

hi everyone! i just read dave's latest musings and stumbled upon stefan westerfeld's notice that he is no longer maintaining arts. many of you have probably already read about it. however, if you want to see a really graceful and stylish way of abandoning a project and changing one's mind, here are stefan's remarks: http://www.arts-project.org/doc/arts-maintenance.html even though arts will probably become obsolete in the near future, i think it should be pointed out that just like the often-bashed open sound system it has been a crucial step in bringing linux audio to the mainstream, and the community owes much to stefan in that respect (not to mention his many contributions to ladspa and other projects). at a time when there was hardly anything else than esound, stefan tackled the job of giving desktop users what they want: multiple source playback and an elegant user interface. even though arts turned out not to be feasible for high-end applications (a fact that stefan now acknowledges, contrary to his former "mission" ;), it has certainly increased the momentum behind linux audio a great deal. kudos, stefan. best, jörn

20 years, 5 months

[linux-audio-dev] [ANN] Ceres V0.42 and Mammut V0.18

by Kjetil Svalastog Matheussen

http://www.notam02.no/arkiv/src/ CERES ***** "Ceres is a simple program for displaying sonograms and for sound effects in the frequency domain." Except that its not that simple anymore... 0.41 -> 0.42 ------------- -Actually apply the fix for the (horrible) bug that caused ceres to crash on newer linux distributions. (Sorry!) MAMMUT ****** Mammut will FFT your sound in one single gigantic analysis (no windows). These spectral data, where the development in time is incorporated in mysterious ways, may then be transformed by different algorithms prior to resynthesis. An interesting aspect of Mammut is its completely non-intuitive sound transformation approach. 0.17 -> 0.18 ------------ -Fixed a (horrible) bug that caused mammut to crash on newer linux distributions. -Simplified the install process a lot. pygtk1, libglade and sndlib is now included in the distribution and is/can be installed automatically if needed. -Added undo for load&multiply --

20 years, 5 months

[linux-audio-dev] ardour 0.9beta23 released

by Paul Davis

Well, its time for another release of Ardour. This release is another milestone: it marks the end of all bugs that were slated to be solved before the 1.0 release. The plan from here is to wait for about a few days to allow testing of this release and minor (cosmetic) bug fixing to continue, and then ardour 0.99 will be released. After that, release engineering (install process, new user experience) will be all that stands between us and release 1.0rc1, which will hopefully be the last release before 1.0. Please note: there is no claim that Ardour is bug free. The bug list for 1.0 was drawn up with the goal of making sure that the vast majority of new (and existing) users of Ardour will have a rewarding, powerful and largely problem-free experience recording, mixing and producing music. There are still substantive (as well as trivial) issues that require solutions, but the development team is anxious to move on to the GTK2 port so that we can make Ardour look as shiny (shinier?) as Rosegarden :) This is an important release for people who work in locales that do not use the period (".") as a decimal separator (i.e. decimals written as "1,5" rather than "1.5"). It is the first version that we believe is now truly locale-safe against data corruption caused by LC_NUMERIC's affect on stored data formats. Enjoy, there's more to come :) --p * fix a truly appalling coding error in all uses of LocaleGuard - people who run ardour with LC_NUMERIC set to something other than en_US.UTF-8 will probably have continued to suffer from locale-based problems because of this problem. * fix nesting of LocaleGuard objects to provide yet more fixes to LC_NUMERIC problems * add new flag for custom canvas items that do not require an automated redraw when arguments are set. * rework canvas "simple rect" item to optimize redraws as resizes occur, and use FAST_PAINT_BOX to speed up drawing slightly. it is possible (likely?) that this will help some system performance issues when recording multiple tracks at once. * rationalize how the "s" (split) operation works. - if the mouse pointer is inside a regionview, that region is split - if the region was part of the selection, then a) all regions covering the mouse pointer time position are also split b) the selection is cleared after the split - if the region was not part of the selection, then the selection is left unchanged after the split * if auto-connect inputs is in use, only connect the first N inputs where N is the number of physical inputs found by JACK * fix grotesque error in use of STL reverse iterators that messed up any use of AutomationList::truncate_end(), causing horrible corruption of the control points. * fix long-standing problems with region gain line visibility (as-is, plus after-trimming) * reimplement Route::_reset_plugin_counts() to use a slightly simpler algorithm and allow zero-input plugins ("instruments") as the first in the chain * fix problem with metering when using zero-input plugins * fix problems with failed remove of redirects * make region editor clocks insensitive at the right times * store relative names in session file for connections, allowing re-establishing internal connections when connected to JACK using a different client name * fix major thinko bug with Curve::spline_eval() that caused a complete failure if the Curve had 0, 1 or 2 control points. * Karsten's fixes for crossfades, plus a modified version of his TimeAxisViewItem "selected" fix. * automation track "controls context menu" now includes "clear" and auto-state submenus, so that full control even using a small track height is possible. * require inserts/plugins to either be mono-input or match the active streams at that point in the route. this means you cannot insert a 2in plugin on a mono track without a 1in/2out splitter preceding it. we will change this in a future (post-2.0) version of ardour so that the splitter is added automatically in a hidden way. * fix naming of sends/inserts to avoid duplications. * removed redundant expansion arrow from TimeAxisView * when a region overlaps another region but is wholly within the other, create hidden, immutable 64-frame xfades at both boundaries. (works, but some more work needed on corner cases and thoroughly testing normal overlap xfades) * fix off-by-1 errors in drawing canvas rect objects (affects rubber band selection, range selection and more) * corrected off-by-1 error in position of fade out polygon within regionviews * expanded height of per-track selection rects to full track height * muted regions never write silence, whether they are opaque or not. * added "Mute" and "Unmute" to region ops menu * fix bug in Editor::cursor_to_selection_{start,end} that prevented the function from working in range mode * delete AudioEngine at exit (and thus call jack_client_close()) * make "active" check menu item on mixer strip "name" context menu be in correct state at startup * popup error message if clone or copy of redirects fails * prepend "!" to the displayed name of a muted region * newly created regionviews follow the current "show waveforms" setting * relevant internal-overlap xfades are invalidated by layering changes * all (relevant) xfades are invalidated by muting changes * another almost-complete reimplementation of plugin count handling - no visible changes intended - we now compute counts before changing the counts - if the configuration is impossible, things are left unchanged - if the configuration is possible, we set the counts - all failed reset_plugin_count() calls should leave the redirect lists in their original state * reimplement region layer changes to avoid visible "illegal" state with two regions in the same layer * fix bug with soloing that would cause solo states of tracks|busses in the incorrect state if busses|tracks were also soloed while a track|bus was un-soloed. * make "active" check menu item in track controls context menu be in correct state at startup * use nick mainsbridge's brilliantly simple "later regions are on higher layers" idea * remove all explicit control over layering from ardour/gtk * fix nasty thread/race condition bug when building peakfiles for imported/embedded audio. two threads could be reading from the same file at the same time, and under some circumstances could stomp on each others activities. * fix potential (suspected) race condition associated with peakfile request submission and handling. may affect some reported "hangs" when importing/embedding audio. * actually use two-stage regionview creation (rects first, waveforms later) by refactoring SndFileSource's use of its primary mutex. makes regionviews * fix attempt to access an illegal column of the file selector in the library/file browser. * add pthread id to "posix signal received" message * require use of --new/-N flag to create new sessions from the command line * remove "exiting foo thread" and "stopping bar thread" messages * from shutdown, don't kill the GUI thread if its not running * add EnvelopeChanged Change to AudioRegion, playlist saves state when this or *any* region change occurs. this fixes a class of bugs where undo after a region was removed fails to fully restore the region's state. * remove debug output from Gtkmmext::NewSaveDialog

20 years, 5 months

[linux-audio-dev] LAC200_4_: Proceedings finally available!

by Frank Neumann

Hi all, this comes somewhat late, but we are still happy to finally have the proceedings of the last Linux Audio Conference (April 2004) online. Short after the conference, we asked the speakers to send papers about their talks so we could put together these proceedings. Well, collecting those papers _after_ a conference was probably not such a good idea :-), but we still got a fine small collection of 6 papers which we have then put together into one PDF, together with a list of the all people who helped in making the conference possible (sorry to anyone we might have forgotten). Get it while it's still warm: http://on1.zkm.de/zkm/stories/storyReader$4477 A lot of thanks go out to those who wrote and submitted these papers! Greetings, The LAC organization team: Götz Dipper Matthias Nagorni Frank Neumann PS: On a sidenote, the OGG files of the presentations which were unavailable for several weeks are now back online again: http://www.linuxdj.com/audio/lad/contrib/zkm_meeting_2004/

20 years, 5 months

[linux-audio-dev] Firewire Audio Card Support

by Olaf Christ

Hi, as the owner of a firewire audio card (Motu 828mkII) I was disappointed when trying to use it under linux. Asking Motu to provide tech docs and/or linux drivers is useless: "We will possibly release linux drivers in the future, but we never release any kind of technical documentation." Is there any effort to join forces for putting pressure on the manufacturers yet? I am willing to create an address list ordered by audio card manufacturer/model to make the manufacturers realize there is a need for linux support. Any comments? Olaf On Thursday 18 November 2004 14:01, derek holzer wrote: > Of course, the Firewire subsystem for Linux works fine. But AFAIK there > are no drivers existing for any firewire audio cards. Bug the various > manufacurers to release more technical info and they might eventually > show up. > > d. > > Victor LaLoggia wrote: > > Hello Frank; > > > > Thank you for your response, and I do not mean to be contrary, but what > > about the work the folks at http://www.linux1394.org/ are doing? > > > > I see that their subsystem has been included Linux kernel sources since > > version 2.3.40. Does the subsystem not work? > > > > Thanks, > > vic > > > > -----Original Message----- > > From: Frank Barknecht <fbar(a)footils.org> > > Sent: Nov 15, 2004 12:14 PM > > To: linux-audio-user(a)music.columbia.edu > > Subject: Re: [linux-audio-user] Using Linux Laptop for Live Performance > > > > Hallo, > > > > Victor LaLoggia hat gesagt: // Victor LaLoggia wrote: > >> I am just beginning my research into the available software and > >> hardware, and would greatly appreciate any information. Especially > >> on hardware - what would be the best usb/ firewire interface for > >> live performance? > > > > No Firewire audio yet on Linux. The best in your case is PCMCIA, which > > has the lowest latency. VX-Pocket or RME cards are good choices. Also > > try, if your internal soundcard is enough. > > > > Ciao

20 years, 5 months

[linux-audio-dev] problem latencytest: modprobe rtc: no such device

by Maarten de Boer

Hello, I decided to give kernel 2.6.10 a try, so I installed it in combination with Con Kolivas system system responsiveness patch. But when I try to run the latencytest (0.5.5), I run into the following problem: $ modprobe latency-test WARNING: Error inserting rtc (/lib/modules/2.6.10-ck2-ck2-pentium4/kernel/drivers/char/rtc.ko): No such device FATAL: Error inserting latency_test (/lib/modules/2.6.10-ck2-ck2-pentium4/misc/latency-test.ko): Unknown symbol in module, or unknown parameter (see dmesg) $ dmesg latency_test: Unknown symbol rtc_register latency_test: Unknown symbol rtc_unregister latency_test: Unknown symbol rtc_control Any suggestion? Maarten

20 years, 5 months

[linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers

by Doug McLain

Tom Szilagyi wrote: >>Hey Tom, >> >>Attatched is a patch that creates a 1in / 2out version of TAP Stereo Echo. It would need a >>new ladspa ID and better name possibly. Ardour now has a strict policy regarding plugin >>connections, requiring a mono to stereo splitter to preceed TAP S.E. on a mono track. The >>popular opinion with the ardour guys is that plugins be made available in various forms >>instead of trying to make the host too complex or having to use combinations to acheive >>the desired results. >> >>I can do the others as well, like reverberator, etc too if you would like. > > > Hi, > > What if I released a stand-alone mono->stereo splitter plugin ASAP? > That would solve this issue completely, no? > > Of course, users will have to explicitly use it, but if I agree to make split versions of > all my stereo plugins, then 1) users still have to decide which one to use and 2) duplicated > code to maintain arises (and many Ladspa ID-s get wasted) etc etc. > > OK, I see you wrote "having to use combinations to achieve the desired results" is ungood, > but I still think this is a cleaner solution from an engineering p.o.v. > > So, what's your opinion? Splitter-plugin vs plugin-splitting? :) At first I agreed that the splitter was the solution, and I wrote one, only to find one already exists in the SWH package. The argument is that this is clumsy and not an optimal solution. After hearing this argument, it does seem like a cleaner, faster solution to have available plugins in various connection formats instead of building the connections from lego's. I am in no way an authority on this though, so I am going to forward this to LAD, as I think it pertains to all the plugin projects. There was recently a thread on ardour-dev regarding connections and plugin counts that is probably going to start all over again, but discussions are fun anyway, arent they? :) Doug -- http://nostar.net/

20 years, 5 months

[linux-audio-dev] Feasibility of Crestron like Linux Based Whole House Audio System - Multisource / Multizone Capable????????????

by Steve Vanechanos

New to the group. Please forgive any unintended breaches of protocol. I just built a house and had it prewired for stereo speaker pairs in 6 rooms / zones in addition to cat5 in each zone. My intention was to purchase a multisource / multizone audio system from a high end integrator. After reviewing several options - Crestron and Niles primarily - I ended the review dismayed with the cost and overall approach of the "main stream" solution providers. I'm a UNIX guy going back to 1983 - Altos8600 running a 5Mhz Intel 8086 with 512Kb RAM, 20Mb 8" Winchester hard drive and Microsoft's version of Xenix. I'm wondering if the present state of the Intel/AMD powered PC with Linux is robust enough to control multiple sources (4, 6 or 8) like digital cable box, directv receiver, XM radio, CD player(s), etc. and route the output to multiple zones/rooms (4, 6 or 8) in an effective and cost efficient manner. The Crestron approach would cost me around $10K - so I've got some money to invest on development if necessary. Once again, my apologies if I've breached any list/group protocol with this post.

20 years, 5 months

[linux-audio-dev] LAC2005: Paper deadline coming closer!

by Frank Neumann

Hi all, just a short reminder: The deadline for paper, music etc. submission for the 3rd Linux Audio Conference (LAC, April 21st-24, 2005) is coming closer - if you plan to hand in a paper, project note, composition, workshop topic etc, be sure to send it off until January 10th, 2005 Believe it or not, we have a tight time plan for the remaining time til the conference, and we need that time for preparations - so we are not going to accept material that gets sent in too late! For more information, please see the web page at http://www.zkm.de/lac Thanks, The LAC05 organization team: Goetz Dipper (ZKM) Matthias Nagorni Frank Neumann PS: And please do not confuse this with the "LCA" that Conrad Parker is organizing, also in April, however not in Germany, but on the other side of the globe! :-)

20 years, 5 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