Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

by Lea Anthony

I'm trying to get a picture in my mind as to what is out there. Could someone please give me a list of Wave editors that are seen as potentially really good under Linux? Cheers, -Lea.

23 years

[linux-audio-dev] Meterbridge 0.0.6

by Steve Harris

http://plugin.org.uk/meterbridge/ Added a correlation meter to the JellyFish, thanks to Ari Kauppi for pointing me to the maths. Its calculated using the non-parametric correlation function Tau, incase anyone cares. Changed the default meter type to PPM. Also added a simple osciloscope display. Hopefully this will be the last release for a while (unless there are any bugfixes). - Steve

23 years

[linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins on Linux in real time

by Benno Senoner

I contacted the author of the VQF plugin about opinions of running windows plugins under Linux. He is not subscribed to LAD so he told me to forward this mail to the list. cheers, Benno On Tue, 22 Oct 2002, Benno Senoner wrote: > We are currently discussing about the possibility to run VST or DirectX audio > plugins on Linux in real time. > I remember you wrote an xmms plugin that allowed to run the windows VQF plugin > under Linux using wine & co. > <snip> > It would be cool if you could write on the linux-audio-dev list about > experiences in that field. I am afraid I will have to keep this short as I'm really busy at the moment. I also am a long way from being an audio expert or wine so I doubt my experiences will be of much use to you hence I didn't subscribe to the list . Feel free to forward this to the audio-dev list and cc me on it if you wish First, the solution I used for the VQF plugin was extremly clunky. There was no way of letting the plugin run inside XMMS without causing segfaults. They simply did not merge well no matter what I tried. I suspect but never proved that it was how WINE has to lay out it's memory to be able to mimic how Windows sees things like segments. The layout is drastically different to how a Linux app normally sees things. By the time a VQF plugin could be loaded, the two very differnet approaches to managing memory simply did not work well together In the end, the solution used was this; 1. At XMMS start, fork and exec an application that uses libwine to load the windows DLL. Communicate with the parent through pipes, sockets or shared memory 2. Start up XMMS as normal 3. The plugin just implements stub functions for every routine a plugin is meant to implement and communicates the information to the child This had a number of issues. First, it was difficult to get information from the plugin. It opened the sound device directly itself which meant that visualisation data was not available. At one point, this was resolved by hacking wine itself to write the PCM data to a named pipe rather than playing to a device but needless to say, it was too ugly to live and couldn't really be distributed easily. (I considered it unreasonable to get users to patch and compile WINE just to play a piece of music, visualisations weren't that important). If I had a nice plugin, what I would try to do is set up two unamed pipes at application start to a child application using libwine. One pipe for writing would send commands and one pipe for reading would take PCM data. I don't know how viable this is for you. > I'm not a windows / wine expert but commonsense says me it should be > possibile to run these windows plugins under Linux in real time with small > buffer sizes in order to get low response times (low latency). I would be inclined to go the other way. With the above solution, I would try and buffer as much data as humanly possible to try and avoid the overhead of calling wine constantly. For example, I would try and get 10 seconds worth of data from the windows plugin before starting to play anything. Once I had the PCM data, it would not matter if the plugin could not make real time contraints. > It should be possible to let wine handle the GUI stuff . (if word and excel > runs then it should be able to run plugin GUIs too). It can, but remember that if you are trying to use this plugin with a normal application, you are likely to run into a lot of trouble. At least I did, but this was a few years back. Things might be different now I imagine you already have checked out how avifile loads it's plugins. When I last looked at it (a few years back), it was using a stripped down version of WINE to just load the plugins and get the function pointers. It might be worth checking into. -- Mel Gorman MSc Student, University of Limerick http://www.csn.ul.ie/~mel

23 years

[linux-audio-dev] musicdsp

by Roger Larsson

http://www.musicdsp.org/ Needs help with their Linux information... Any takers? /RogerL -- Roger Larsson Skellefteå Sweden

23 years

Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone

by Tom

I'm really late on this one, but I finally looked at the linked waveforms. Here is what I see. Ignoring push-pull crossover distortion, there are basically two kinds of distortion happening. There are two stages to the amplification, a pre-amp and an output amp. The pre-amp provides soft clipping of the input signal, generating harmonics of the input signal. As the input level is increased, the pre-amp output looks more like a square wave but with rounded edges. The pre-amp is outputting at its maximum voltage (saturation). The output amp sees this square wave as a dc step input. The output circuit is under damped, meaning that its step response will include ringing. The frequency of the ringing is related to the design of the output circuitry and has nothing to do with the frequency of the input signal, since the output amp sees its input as dc. The degree of clipping from the pre-amp determines how long the output amp sees its input as a step, and determines how long the output signal contains the ringing. The output amp is not operating at maximum output voltage. This is what allows the overshoot and undershoot spikes in the ringing to pass unclipped. For even more distortion the output amp could be biased to clip the overshoot portion of the ringing. This pseudo-knowledge comes from a distant dream of having studied impulse, step, and ramp responses of analog circuits 20+ years ago. Tom

23 years

[linux-audio-dev] USB audio.c driver patch; complete n-channel/24 bit patch

by Monty

Apologies taking time to package this up. The patches included are tested against 2.4.19 or later. This patch fixes a few bugs and implements full n-channel support of greater-than-stereo USB audio devices, such as the emagic emi 2|6. I also opted to make the minor extention to OSS to define 24 and 32 bit AFMT modes, and the patch includes this. It does not break any existing OSS compatability, and unaware apps can continue to be unaware. The modified audio.c will build without the OSS extentions to soundcard.h. As suggested, I didn't bother with OSS mixer extentions. The device I care about most doesn't expose a per-channel mixer feature regardless. Also, I was wrong: 2.5's audio.c is different, but the differences appear to be for the sake of keeping up with other changes to USB support. I did not attempt to apply the included patch to 2.5's audio.c, but I'd give it even odds with sufficient fuzz. Monty

23 years

[linux-audio-dev] Re: Music N style sw w/ JACK-support (was: Re: [linux-audio-dev] Re: image problem)

by Patrick Shirkey

Reiner wrote: >> - there's patch for PD that provides JACK-support >> -> >> http://sourceforge.net/mailarchive/message.php?msg_id=1169519 >Actually, this is no longer current. Check the pd list archive for >newer approaches to pd jackification. Personally, I now use Günther >Geiger's patch applied to pd 0.35 and it works quite well. Together >with the plugin~ object for LADSPA plugins the patched pd can be used >as effect rack for ardour. This would make an excellent quicktoot. If you have the time to send me a brain dump I will happily format it. Please consider the benefits that this would provide to pd, ardour and Linux audio users. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

23 years

[linux-audio-dev] Audio Programming

by Lea Anthony

Hi, I am a musician and also a programmer. I have many years experience of coding but not in the audio field. Any tuts around? How do I get into it? Cheers for any info. -Lea.

23 years

Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone

by nikodimka

>> You can calculate your tranformation for the input signal S(x_i) once >> And the same transformation for S(x_i)+1 again. > >Won't that just give you the gradient at point x_i, ie. d/dt(S)? yes. >We are talking about frequency domain aliasing here, oh yeah i see. sorry. > which is when you >generate partials that would be above the nyquist frequencyi, so they get >reflected down into low frequencies. It is not directly related to the >differential of the signal, though a high differential is often indicative >of an aliasing problem. > >Typically you prevent audio aliasing by generating the waveform in a way >so that it contains no partials above nyquist, or by generating it at a >sufficiently high sample rate that there are none, then decimating down. but you can do the pretty same trick for the frequencies: take two different numbers with no common divisors (or just a pair of prime numbers) as sampling rates and see how the output signal changes. The difference give you some linear combination of aliased frequencies. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

23 years

Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone

by nikodimka

>> my feeling is that oversampling alone will not do, although >> you're probably right in that it will get rid of most of >> the aliasing. > >Its how most people tackle to problem. I think I can get the valve cheap >enough that it will be practical. I'm not really familiar with what are the techniques of anialiasing in use. But I can see the following way. You can calculate your tranformation for the input signal S(x_i) once And the same transformation for S(x_i)+1 again. I mean two similar input signals differing in one bit of value. So when you have two output saignals you can calculate the error due to aliasing: abs( F(S(x_i)) - F(S(x_i)+1) ) And apply some techniques to eliminate this aliasing ranging from qubic splines to plain dithering applied to the output signal. It seems to me that this is much better than oversampling. Especially for nonlinear transformations. (Or is it just a trivial thing and it doesnt work and this is not what you discuss?) nikodimka > >> i'm thinking about how to apply the technique to produce >> square clipping, or better a [0 .. 1] range of clipping, >> but the integration approach is awkward. > >I doubt that the electronics ever produces hard square clips. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

23 years

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