Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] Interesting MIDI project

by Erik de Castro Lopo

Hamster controlled MIDI: http://www.nbb.cornell.edu/neurobio/land/STUDENTPROJ/2002to2003/lil2/ Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Microsoft : Yesterday's software running on today's hardware tomorrow.

21 years, 4 months

[linux-audio-dev] have to restart jack between ecasound sessions

by Eric Dantan Rzewnicki

I'm starting jack via jackstart like this: jackstart -v -R -d alsa -d ice1712 -r 44100 -p 64 -n 2 I can run ecasound in many ways (different chain settups, via ecaplay, wav or ogg input, etc.) one time only. If I try to run another ecasound session without restarting jack the second ecasound exits like this: audiobox:~$ ecaplay /mnt/audio/in_progress/guitar_mix/s2004-0217-2242.ogg *********************************************************************** * Message from libecasoundc: * * 'ECASOUND' environment variable not set. Using the default value * value 'ECASOUND=ecasound'. *********************************************************************** (ecaplay) Playing file '/mnt/audio/in_progress/guitar_mix/s2004-0217-2242.ogg'. exiting... It doesn't return ... just hangs like that until I ctrl-c it. If I strace the ecaplay it's waiting for ecasound: audiobox:~# strace -p 450 Process 450 attached - interrupt to quit waitpid(451, <unfinished ...> Process 450 detached which is stuck in a futex(): audiobox:~# strace -p 451 Process 451 attached - interrupt to quit futex(0x413e6bf8, FUTEX_WAIT, 453, NULL Once I kill the ecaplay w/ctrl-c the "ecasound -c -D" remains until I use kill -9 on it. Anything else I can do to help debug this? System details below. Thanks, Eric Rz. asus a7v8x-x athlon XP 2800+ (2071.203 MHz) 1.5GB PC2700 RAM 12GB / /dev/hda2 ext2 (actually a 40G disk) 160GB /mnt/audio/ /dev/hdc1 ext2 2GB swap /dev/hda1 (onboard via8235 -- disabled) ice1712 M-Audio Delta-66 w/omni i/o ymfpci guillemot maxisound fortissimo -- midi only debian testing (sarge) 2.6.2 (pre-empt on, drives tuned -- kernel.org sources compiled via debian's make-kpkg) realtime-0.0.2 lsm (insmod'ed since make install screws up all other modules) alsa-1.0.2 (lib, envy24control, tools) alsa-1.0.2c drivers: ./configure --with-isapnp=no --with-sequencer=yes --with-oss=no \ --with-cards=dummy,virmidi,ice1712,ymfpci,via82xx libsndfile-1.0.6 from tar.gz jack-0.94.0 ./configure --enable-capabilities --enable-optimize \ --with-default-tmpdir=/dev/shm --disable-portaudio ecasound-2.3.2 ./configure --enable-pyecasound --disable-oss --disable-arts \ --with-largefile ams-1.7.3

21 years, 4 months

[linux-audio-dev] [ANN] simsam-0.1.7 released

by Christian Henz

simsam-0.1.7 was released. Changes include: - multiple instruments - multiple outputs (JACK only) - config loading (at last) - some fixes & cleanups - some new bugs ;-) Source tarball and i386 .deb for Debian/unstable are available at simsam's SourceForge download page. http://sourceforge.net/project/showfiles.php?group_id=65022 http://simsam.sourceforge.net/ cheers, Christian Henz

21 years, 4 months

[linux-audio-dev] MIDI interface latency

by jrobbins＠nymu.net

Anybody know what's the minimum latency that can be achieved passing MIDI notes from one computer to another? I'm wondering if it's possible in theory to set up an audio generation cluster to be used as a realtime instrument. Basically, have a network aware synthesis app running on all machines, administer the setup/modification of the signal flow architecture from one master machine in non-rt over sockets, and then pass notes to the appropriate machines using midi interfaces. Naturally this depends on a signal path separable into big chunks. I have a hunch that midi over ip has latency too high and unpredictable for this. -jacob

21 years, 4 months

[linux-audio-dev] [ANN] Gungirl Sequencer 0.2.0

by Richard Spindler

Hi, Gungirl Sequencer is an easy to use Audiosequencer. It includes a simple Filemanager and uses Drag & Drop to arrange Audiosamples. This is the new Release 0.2.0 of Gungirl Sequencer, it comes with a bunch of new Features, and for your convinience is provided in the preferred standard Distribution Formats for both Linux and MS Windows: - Statically Linked (all dependencies included) RPM-Package - Autoconfified (./configure, make and make install) Source Package - Executable ( .exe) Installer for MS Windows The new features in this Release are: * A simple Ruler * Select Samples with rubber-frame * MiniPlayer for Pre-Listening * Customizable Snap-Value * Track Mute and Volume * Master Volume * Snapless Sample-Positing * Info-Box for Sample-Files * Progress-Bars for File loading * uncountable Bug-Fixes Check it out at: http://ggseq.sourceforge.net/ -Richard Spindler

21 years, 4 months

[linux-audio-dev] [ANN] Gungirl Sequencer 0.2.0

by Richard Spindler

21 years, 4 months

[linux-audio-dev] caps 0.1.0

by Tim Goetze

pleased to announce the initial release of the caps audio plugin suite under the GNU public license. quoting http://quitte.de/dsp/caps.html : caps, the C* Audio Plugin Suite, is a collection of refined LADSPA units including instrument amplifier emulation, stomp-box classics, versatile 'virtual analog' oscillators, fractal oscillation, reverb, equalization and others. some of caps is an improvement over previous efforts (the rewritten amplifier emulation plugins for example do 8x oversampling using polyphase filters, for much cleaner sound) but most of the plugins are ex nihilo creations. for those with an interest in DSP effects but no time or opportunity to run the plugins, the data sheets provided through the above document may be interesting. enjoy, tim

21 years, 4 months

Re: [linux-audio-dev] TAP Scaling Limiter - how's it work?

by Tom Szilagyi

Paul Winkler wrote: > Hi folks, and Tom if you're listening, > > The description of the TAP Scaling Limiter is > very interesting - http://tap-plugins.sourceforge.net/#limiter > I'm just curious, having done no real DSP coding - > it must do some internal buffering, right? Right, i have to admit it does :) That's why the plugin has to have latency. > So how does it deal with half-cycles that fall on the edge of a > buffer? It seems to me that you can't process the final > half-cycle without refilling the buffer, but you can't refill the > buffer until you've processed all its data - or can you? Yes you can. No, you can't actually, but you can eliminate the problem so you don't have to solve it. There is a ringbuffer, with a length chosen so it is capable of containing a whole half-cycle even at low frequencies (40 Hz is the limit in my implementation, which means varying number of samples at varying samplerates). Incoming audio is streamed into the ringbuffer (which actually works like a FIFO), and the half-cycles are being scanned starting from the other end of the buffer (that is, where output falls out). Now let's say the buffer is just full of audio. The host calls run(), and the plugin starts scanning backwards (from the oldest sample, that is, the one just about to fall out of the FIFO, towards the newest one), and marks zero-crosses and scales the marked individual zero-crosses. It keeps track of the half-cycle boundaries, and when it reaches (or more likely, overgoes) the N samples the plugin was asked to process in this run() call, it pushes out the N samples, but that of course will be in no relation with the half-cycle boundaries. Some piece of the last half-cycle will remain, and at the next run(), the plugin will continue the zero-cross scan from that point, not from the buffer boundary. But it counts the N samples needed to be pushed out from the buffer boundary, of course. I'm afraid i can't explain it very clearly, but i hope you get the feeling. Tom ps. stay tuned, more plugins are about to arrive... expect them in a week or two. :)

21 years, 4 months

[linux-audio-dev] The AGNULA newsletter - the future

by Andrea Glorioso

[Sorry for cross-posting - feel free to forward around] Dear all, I'm sending this e-mail to all mailing lists/persons I think (often with a less-than-optimal inductive process) could be interested in the future of what's currently know as the "AGNULA Newsletter". If you receive multiple copies of this e-mail or if you are not interested at all in the subject, please excuse me and drop everything to the bitbucket. First, a bit of history. The AGNULA newsletter was born in Nov 2003 (more or less) as a service to our users who could be informed of new software releases, events, research achievements in the field of music & sound, with specific preference given to topics related to Libre Software. You can see some more information here: http://www.agnula.org/documentation/newsletter/ (you can find the past issues archive at the same URL). The AGNULA Newsletter was never meant to be AGNULA-centric (although, as was recently pointed out on our mailing lists, the naming we chose could suggest that) but rather as a way to spread information about the above mentioned topics - and of course to talk about AGNULA news, if relevant. Over the time we managed to send around 12 weekly issues of the newsletter to our `newsletter-dist' mailing list subscribers, who currently amount to 70. Honestly, given the young age of the newsletter and the amount of manpower we've been able to put into it, I'm not too dissatisfied with these numbers. However, as the AGNULA project is reaching the end of its funded lifetime I think it's high time that we think whether the AGNULA Newsletter should become something bigger and better organized. What does this mean? Basically, I'd like to understand whether the wider GNU/Linux audio (and video?) community is interested in turning the newsletter into a "community project". What we would basically need is: (a) that Libre Software project maintainers add the newsletter contact address (currently newsletter-collect(a)lists.agnula.org, but this is not cut in stone) so that when they send announcements about new releases the newsletter team is notified more quickly; (b) a (team of) editor(s) for the newsletter. I've been doing that for the past months, but time pressure is growing and since my position as AGNULA technical manager will end in April, I forecast I won't have the same amount of time to dedicate to this project. A native english speaker would be preferred, of course; (c) a (team of) news pieces collectors/writers. The AGNULA project can give (or try to give :) all the necessary instruments needed by the newsletter team to coordinate their work - that means CVS, bug tracking system, mailing lists, whatever; (d) [optional] a (team of) translators to create nationalized versions of the newsletter. This is of course a long-term goal and can be put aside for the moment. So, the question is: do you think this - turning the AGNULA Newsletter into the "AGNULA Newsletter on Sound & Video" or even the "Newsletter on Sound & Video", although I'd like the AGNULA name to remain somewhere in the newsletter, if anything for sentimental reasons :) - is a good idea? If any of you think it is, I would encourage all of you to discuss the topic on: users(a)lists.agnula.org http://lists.agnula.org/mailman/listinfo/users If you are not subscribed to the mailing list, don't worry - I'll authorize your messages as they arrive. Please put a clear sign that you want to be put in Cc: for replies. Thanks for your time and attention, Andrea Glorioso AGNULA Technical Manager

21 years, 4 months

[linux-audio-dev] ANN: Specimen Version 0.2.0 Released

by Pete Bessman

The second major of version of Specimen has been released today. The main change is the new sample editor that allows you to fine tune the way your samples are being played. I've also created some documentation, and added ping-pong and reverse play modes. Download it from www.gazuga.net, and read up on it at www.gazuga.net/guide. [pb]

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