Linux-audio-dev January 2004

linux-audio-dev@lists.linuxaudio.org

94 participants
90 discussions

[linux-audio-dev] linux 2.6.1 realtime lsm, jackstart & ecasound success

by Eric Dantan Rzewnicki

I just completed a successful run of ecasound with my guitar_mix.ecs (attached) on my new box. This is a 15 minutes 5 track session, 4 tracks from disk, one live jack input. Three outputs: stereo wav, mono wav and live monitor. It uses amplify and panning effects controlled by ecasound generic oscillators. Details on the new box and it's current configuration: asus a7v8x-x athlon XP 2800+ (2071.203 MHz) 1.5GB PC2700 RAM 12GB / /dev/hda2 (actually a 40G disk) 160GB /mnt/audio/ /dev/hdc1 drives tuned 2GB swap /dev/hda1 onboard via8235 (M-Audio Delta-66 w/omni i/o -- still in old box) (ymfpci guillemot maxisound fortissimo -- midi only -- still in old box) debian testing (sarge) 2.6.1 (pre-empt on -- kernel.org sources compiled via make-kpkg) realtime-0.0.2 lsm alsa-1.0.2 (drivers, lib, envy24control, tools) drivers: ./configure --with-isapnp=no --with-sequencer=yes --with-oss=no \ --with-cards=dummy,virmidi,ice1712,ymfpci,via82xx libsndfile-1.0.5 from tar.gz. debian only had 1.0.4 jack-0.94.0 ./configure --enable-capabilities --enable-optimize \ --with-default-tmpdir=/mnt/ramfs/ --disable-portaudio ecasound-2.3.2 ./configure --enable-pyecasound --disable-oss --disable-arts \ --with-largefile I started jackd via jackstart like so: jackstart -v -R -d alsa -d via82xx -r 44100 -p 128 -n 3 I run the ecasound session from a script that does some pre and post processing. It assembles the 4 wav input files from other wav's and cuts the output files down to randomly selected 5 minute chunks, fades in and out the beginnings and ends, normalizes and encodes the stereo wav to ogg. The whole session ran on this onboard soundcard without xruns. I switched desktops numerous times in openbox3 and even switched out of X to tty2 to login and change my hostname back (I had changed it while in X and new apps weren't able to start because they couldn't connect to the display. duh ... 8) ). The session ran flawlessly. I'm not exactly sure what the stats jackd puts out when run verbosely mean, but I know the results I saw mean I'll be able to run this session with many more effects at lower latency than I could on my old box ... _And_ I don't have to do it as root! yay! :) The old box is a PII 400 w/768M PC100 RAM. On that box the whole session including pre and post processing takes around 21 minutes. On the new box that overhead is cut way down with the whole session taking only 16 minutes 20 seconds (only 1 min, 20 more than the actual recording time). While running jackd reports load averaging (just measured visually from jackd output, not hard numbers) around 7.5 with max usecs ~220. On the old box using my delta66 I have to run at -p 256 to avoid xruns in this session, load averages around 22 and max usecs around 1350. Admittedly, much of this performance gain is related to the new hardware. But, still , it's very cool that all this newish stuff (lsm, latest alsa, latest ecasound, latest jackd, 2.6 kernel) is working well In other testing with the via chip I've had jack running as low as -p 32 -n 3 with just a couple jack_metro's connected. I have to go down to -p 16 to get a few xruns. Not until -p 8 do things start to get really bad. /proc/interrupts says the card's on IRQ 4, too. I have a few more things to install, configure and test before I move my delta66 and midi setup over to the new box. But, these initial tests are very exciting. I just had to share. Thank you to all the developers for all this excellent software. And thanks to all the list members, too. :) -Eric Rz. # eric(a)zhevny.com guitar_mix chainsetup file ### general -b:128 -B:rtlowlatency -n:guitar_mix -X -t:902.802 ### audio inputs -a:1,6,11 -i:track1.wav -a:2,7,12 -i:track2.wav -a:3,8,13 -i:track3.wav -a:4,9,14 -i:track4.wav -a:5,10,15 -i:jack_alsa #-a:5,10,15 -f:16,1,44100 -i alsahw,0 ### audio outputs # live output -a:1,2,3,4,5 -f:16,2,44100 -o jack_alsa #-a:1,2,3,4,5 -f:16,2,44100 -o alsahw,0,0 # file outputs ### FIXME: change this output to .ogg when crop and fades work -a:6,7,8,9,10 -f:16,2,44100 -o:/mnt/audio/in_progress/guitar_mix/stereo_out.wav -a:11,12,13,14,15 -f:16,1,44100 -o:/mnt/audio/in_progress/guitar_mix/mono_out.wav ### chain operators and controllers # live output -a:1 -erc:1,2 -epp:0 -kos:1,0,100,0.02,0 -ea:0 -kos:1,0,200,0.01,0 -a:2 -erc:1,2 -epp:0 -kos:1,0,100,0.04,0 -ea:0 -kos:1,0,200,0.02,0 -a:3 -erc:1,2 -epp:0 -kos:1,0,100,0.06,0 -ea:0 -kos:1,0,200,0.03,0 -a:4 -erc:1,2 -epp:0 -kos:1,0,100,0.08,0 -ea:0 -kos:1,0,200,0.04,0 -a:5 -erc:1,2 -epp:50 -ea:205 # stereo file out for .ogg -a:6 -erc:1,2 -epp:0 -kos:1,0,100,0.02,0 -ea:0 -kos:1,0,200,0.01,0 -a:7 -erc:1,2 -epp:0 -kos:1,0,100,0.04,0 -ea:0 -kos:1,0,200,0.02,0 -a:8 -erc:1,2 -epp:0 -kos:1,0,100,0.06,0 -ea:0 -kos:1,0,200,0.03,0 -a:9 -erc:1,2 -epp:0 -kos:1,0,100,0.08,0 -ea:0 -kos:1,0,200,0.04,0 -a:10 -erc:1,2 -epp:50 -ea:205 ### crop and fade in/out ### generate an effects preset file for this in preprocessing #-a:6,7,8,9,10 -ea:0 -kl:1,0,100,4,0,0,10,1,290,1,300,0 # mono file out for pool -a:11 -ea:0 -kos:1,0,200,0.01,0 -a:12 -ea:0 -kos:1,0,200,0.02,0 -a:13 -ea:0 -kos:1,0,200,0.03,0 -a:14 -ea:0 -kos:1,0,200,0.04,0 -a:15 -ea:205 ### crop and fade in/out ### generate an effects preset file for this in preprocessing #-a:11,12,13,14,15 -gc:$pos,300 -ea:100 -klg:0,0,100,4,0,0,10,1,290,1,300,0

20 years, 10 months

[linux-audio-dev] [OT] Numbers, numbers, numbers...

by Rohan Drape

> that's interesting. elk-scheme says about this: > > > (exact? (* 0 440.0)) > #f > > guess something to be fixed, if #t is the R5RS answer... Actually, R5RS says: An operation may, however, return an exact result if it can prove that the value of the result is unaffected by the inexactness of its arguments. For example, multiplication of any number by an exact zero may produce an exact zero result, even if the other argument is inexact. In some environments this sort of thing can be a fast path. This actually is exactly what some people really do not like about R5RS. Personally, the fact that both Stalin and mzscheme actually exist suggests a curious sort of happiness... Regards, Rohan This reminds me of pop music, "I'm no fucking Buddhist, but this is enlightenment"... :?

20 years, 10 months

[linux-audio-dev] alsa sequencer filter client

by Garett Shulman

Hello, I am trying to create a very simple midi filter client for the alsa sequencer based on aseqview-0.1.4. I have alsa 0.9.8. This code shows the input and the output port in aconnect when executed. And, when the raw_midi client is connected The callback does get called when I play keys on my piano. However, Its as though the message is getting sent back to this client and not on to the next client. The process_event function keeps getting called over and over again with the same message when I hit one piano key. It's as though it is sending itself the message. Any Ideas are greatly appreciated. -Garett #include "portlib.h" int process_event(port_t *p, int type, snd_seq_event_t *ev, int *priate_data) { port_write_event(p, ev, 0); } int main() { unsigned int caps = SND_SEQ_PORT_CAP_WRITE | SND_SEQ_PORT_CAP_SUBS_WRITE | SND_SEQ_PORT_CAP_READ | SND_SEQ_PORT_CAP_SUBS_READ; port_client_t *client = port_client_new("MIDI filter", SND_SEQ_OPEN_DUPLEX); port_t *port = port_attach(client, "FILTER port", caps, SND_SEQ_PORT_TYPE_MIDI_GENERIC); int *priv_data; /* add callback */ port_add_callback(port, PORT_MIDI_EVENT_CB, (port_callback_t)process_event, priv_data); port_client_do_loop(client); return port_detach(port); }

20 years, 11 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 4, Issue 61

by rd＠alphalink.com.au

> > 440.0 is still an exact integer > Hunh? What Scheme is this? The Scheme spec says > "It [a numerical constant] is inexact if it contains a decimal point..." Yes, my mistake, I meant to say that 440.0 is still an integer. Welcome to MzScheme version 205.8, Copyright (c) 1995-2003 PLT > (integer? 440.0) #t > It also says "inexactness is a contagious property of a number". Welcome to MzScheme version 205.8, Copyright (c) 1995-2003 PLT > (exact? (* 0 440.0)) #t This is explicitly mentioned in R5RS, and exact zeroes turn up all the time in controller input streams, from midi controllers for example. > In any case, type checks are trivial. Well yes, it is the the type check that determines the OSC encoding, but without explicit type tagging there is no way of knowing if 1.0 should be encoded as a single or double precision value? Or in fact if it is a 'proper' integer that has been contaminated somewhere along its journey? My actual argument regards all this is that OSC is a good thing to have in user space, and that in user space 440 should be a valid frequency input, and 1.0 a valid index input. I think it is an amazing contribution of SuperCollider that composers find the language and the environment approachable. The 'scsynth' OSC implementation is part of this contribution, we should live up to it's example. Regards, Rohan An aside: I bought up scheme as a counterexample to Lua to show that just because a language has a lot of numerical types does not help with getting OSC encoding `correct'. (integer? 1.0) => #t (integer? 1) => #t (exact? 1.0) => #f (exact? 1) => #t (= 1 1.0) => #t (eq? 1 1) => #t (eq? 1.0 1.0) => #f (eq? 1 1.0) => #f These questions are interesting, and of course not peculiar to lisps, but implementors should bend over backwards trying to make sure that composers don't *need* to ponder the mysteries of inexact integers to tune an instrument.

20 years, 11 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 4, Issue 62

by Jason Walton

Four hours of work for an IPOD >>> linux-audio-dev-request(a)music.columbia.edu 1/26/2004 10:02:19 AM >>> Send linux-audio-dev mailing list submissions to linux-audio-dev(a)music.columbia.edu To subscribe or unsubscribe via the World Wide Web, visit http://music.columbia.edu/mailman/listinfo/linux-audio-dev or, via email, send a message with subject or body 'help' to linux-audio-dev-request(a)music.columbia.edu You can reach the person managing the list at linux-audio-dev-owner(a)music.columbia.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of linux-audio-dev digest..." Today's Topics: 1. Re: [RFC] Lite OSC API (Kjetil Svalastog Matheussen) 2. RE: Modulars (Brad Arant) 3. Modulars (Kjetil Svalastog Matheussen) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Jan 2004 17:35:09 +0100 (CET) From: Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> Subject: [linux-audio-dev] Re: [RFC] Lite OSC API To: linux-audio-dev(a)music.columbia.edu Message-ID: <Pine.LNX.4.58-L.0401261731570.12025(a)iannis.uio.no> Content-Type: TEXT/PLAIN; charset=US-ASCII rd(a)alphalink.com.au: > > Since I think this is really important I will give an example, and from the > other end of a continuum. I use scheme for most of my music work. > Scheme has a very sophisticated numerical tower. I might write (-> > "/n_set" 1001 "freq" 440) to set the frequency of an instrument at SC3. > The OSC encoder encodes values based on their lisp type, 1001 is an > integer and gets encoded as 'i'. Lets assume that to the receiver the > frequency argument is a float, here I lose because 440 is an integer. I > argue that a receiver implemented like that is just wrong, that an integer > 440 frequency is completely valid, and SC3 thankfully agrees and plays > the right note. > For what scheme implementation are you using? And where can I get what you are using? -- ------------------------------ Message: 2 Date: Mon, 26 Jan 2004 08:51:19 -0800 From: "Brad Arant" <barant(a)barant.com> Subject: RE: [linux-audio-dev] Modulars To: "'The Linux Audio Developers' Mailing List'" <linux-audio-dev(a)music.columbia.edu> Message-ID: <200401261655.i0QGt1EO021207(a)roar.music.columbia.edu> Content-Type: text/plain; charset="us-ascii" I have a few more for you since I still own some of these - don't hin anybody has done emulators for them but I thought I would at least let you know they are there. PAIA Modular ARIES System II -----Original Message----- From: linux-audio-dev-bounces(a)music.columbia.edu [mailto:linux-audio-dev-bounces@music.columbia.edu] On Behalf Of Juhana Sadeharju Sent: Monday, January 26, 2004 8:20 AM To: linux-audio-dev(a)music.columbia.edu Subject: [linux-audio-dev] Modulars Hello. Below is an unfinished list of modular synths. Better than nothing. This kind of simple lists gives a good overall picture of the situation. For us developers the list should have following info: have source code? have manuals? have screenshots? have example instrument files? I think I have collected enough all of that. BTW, the paper on first interactive graphics system (I.Sutherland's SketchPad 1963) gives the idea that the drawn circuit diagram could directly be used as input to the circuit simulators. Digital modulars have been around as long but I could not find anything (between 1963-1980) on having a graphical frontend to them. Of course, I do not have access to many old papers. Regards, Juhana ============================================================================ = Source Graph Script Name Code GUI UI Author/Notes ---------------------------------------------------------------------------- - AlsaModularSynth Yes Yes No M.Nagorni & F.Adriaensen AnalogBox No Yes ? ? Arts Yes Yes No ? AudioMulch No Yes ? Ross Bencina BlockCompiler OnHold No Yes M. Karjalainen Building Blocks No Yes ? MIDI only CPS No Yes ? Niels Gorisse Csound Yes No Yes Barry Vercoe Cmusic Yes No Yes ? DirectCsound ? ? ? ? DreamStation No ? ? Audio Simulation Fugue Yes No Yes ? Gabriel ? Yes ? ? Galan Yes Yes ? ? Gdam Yes Yes ? ? Harmonizer/Vsig No Yes Yes Eventide Infinity No Yes ? Sound Quest InstrumentBuilder No Yes ? Mark Trombino, Csound frontend jMax Yes Yes Yes IRCAM JSyn No ? ? ? Kyma No ? ? Symbolic Sound LabView No Yes Yes National Instruments Matlab/Simulink No Yes ? Mathworks MAX/MSP No Yes ? Cycling '74 Moog Modular V No ? ? Arturia NMEdit Yes Yes No ? Nord Modular No Yes No Clavia Nyquist Yes No Yes R.B. Dannenberg OASYS No ? ? Korg OpenMusic ? Yes ? IRCAM PatchWork ? ? ? ? PD Yes Yes No Miller Puckette Pulsar/Scope/Noah No Yes No Creamware PSK Yes No Yes ? Ptolemy Yes Yes ? ? Quasimodo Yes Yes No Paul Davis Reaktor No Yes No Native Instruments Reality No ? ? Seer Systems SAOL Yes No Yes ? Scilab/Scicos Yes ? ? ? Sildex/Signal ? ? ? ? Spiralsynthmodular Yes Yes ? ? SPT ? ? ? Synthetic Intelligence Supercollider No ? Yes James McCartney SynC Modular No ? ? ? SynthBuilder Yes Yes ? Staccato Systems Tassman No Yes No Applied Acoustics Tempest No Yes ? Virtual Labs Vaz Modular No Yes No STL/Martin Fay VirSyn No ? ? ? Virtual Waves No Yes ? Synoptic Visual Orchestra No ? ? ? WaveWarp No ? ? Sounds Logical ============================================================================ = ------------------------------ Message: 3 Date: Mon, 26 Jan 2004 17:51:46 +0100 (CET) From: Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> Subject: [linux-audio-dev] Modulars To: linux-audio-dev(a)music.columbia.edu Message-ID: <Pine.LNX.4.58-L.0401261742350.12025(a)iannis.uio.no> Content-Type: TEXT/PLAIN; charset=US-ASCII Juhana Sadeharju: > > Hello. > > Below is an unfinished list of modular synths. Better than nothing. > This kind of simple lists gives a good overall picture of the situation. > > For us developers the list should have following info: have source code? > have manuals? have screenshots? have example instrument files? > I think I have collected enough all of that. > > BTW, the paper on first interactive graphics system (I.Sutherland's > SketchPad 1963) gives the idea that the drawn circuit diagram could > directly be used as input to the circuit simulators. > > Digital modulars have been around as long but I could not find > anything (between 1963-1980) on having a graphical frontend to them. > Of course, I do not have access to many old papers. > There was one with a graphical interface: MusicBox No Yes No David Fahrland And its from the 64-69 or something, implemented in fortran, had a custom made graphical interface, and supposedly was very much like Max, only 20 years earlier. The machine was placed at EMS/Sweden. >From google I only found this information: http://www.ballade.no/nmi.nsf/doc/art2003100811103357431448 (At the top there is a picture of the machine) -- ------------------------------ _______________________________________________ linux-audio-dev mailing list linux-audio-dev(a)music.columbia.edu http://music.columbia.edu/mailman/listinfo/linux-audio-dev End of linux-audio-dev Digest, Vol 4, Issue 62 **********************************************

20 years, 11 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 4, Issue 61

by Bill Schottstaedt

> 440.0 is still an exact integer Hunh? What Scheme is this? The Scheme spec says "It [a numerical constant] is inexact if it contains a decimal point..." It also says "inexactness is a contagious property of a number". In any case, type checks are trivial.

20 years, 11 months

[linux-audio-dev] Re: [RFC] Lite OSC API

by Kjetil Svalastog Matheussen

rd(a)alphalink.com.au: > > For what scheme implementation are you using? And where can I > > get what you are using? > > I use Matthew Flatt's mzscheme, which is part of the PLT project, see > <www.plt-scheme.org>. I run it with a two line patch to put the Boehm > GC into incremental mode. > > There is a pre-release archive at <www.alphalink.com.au/~rd>. I have Thanks, I'm looking at it now. I was hoping you would have used guile instead so that I could use it in pure data, so I was a bit dissapointed. > used this and James McCartney's SC3 synthesis server, see > <supercollider.sf.net>, as my work environment for over a year and it is > stable, however unless there is a particular affinity for Lisp I would > recommend using James McCartney's Smalltalk dialect as a language > client. > Actually, I'm currently using python and pure data to access the SC3 synth engine. Look at the supercollider module in the pure-data cvs repository. But it would be nice to use scheme as well as python. --

20 years, 11 months

Re: [linux-audio-dev] [RFC] Lite OSC API

by rd＠alphalink.com.au

I am afraid have gotten to your OSC messages a bit late, I can only read lists at web archives at present and the jack lists have been down... > * No service discovery. This is a big deal, but can be solved /if/ we I don't know of a database, which I guess is not a good situation. CNMAT might be interested in doing the basic administration required for a port register. I think that a database of static port numbers is preferable to a dynamic system *if* it is workable. If a dynamic system were neccessary it should be implemented as an OSC server! I am actually not exactly sure what you mean by service discovery? > I'm very happy to discussus a GPL'd library implementation or I have had to do some work on the OSC implementation I have been using in order to address two issues. I think you will need to address these with liblo also. They are: 1. type coercion and 2. variable argmument messages. I am going to attach the note I wrote about the implementation below, which describes these in detail, but briefly on type coercion: Given the message shape ("/foo/bar" "fi") as in the testlo.c file, a receiver should match not only ("/foo/bar" "fi" 2.0 23) but also ("/foo/bar" "ii" 2 23) and ("/foo/bar" "if" 2 23.0) and in fact all other possible numerical encodings, and provide them to the handler in the form requested. The work I have done *only* provides the byte string decoder and encoder, but it does support all the extended basic OSC types and numerical and string coercion. I think you could use it as is if you wanted, or of course just take whatever you need. I will happily implement/apply any changes/fixes required to make it usable for you. The implementation is in the file 'osc.c' in the jack.clock or jack.scope archives at <http://www.alphalink.com.au/~rd>. It works for me but is otherwise untested! Apart from the above the design looks good, although personally I agree with James McCartney, see SC3 or recent post to OSC_dev, that combining the verb and the subject in the address is a bad idea, and would prefer to see a library that discourages that use ;) (This would also make the handler type declarations simpler...) Regards, Rohan

20 years, 11 months

Re: [linux-audio-dev] [RFC] Lite OSC API

by rd＠alphalink.com.au

> Sending '10.1' to a slot that is semantically an integer should > be undefined, though in practice you get '10'. Sorry, not even I agree with that. I meant to say that the floor/truncate/round/ceiling decision should be unspecified.

20 years, 11 months

[linux-audio-dev] Re: Project: modular synth editor

by Juhana Sadeharju

>From: torbenh(a)gmx.de > [ gnomecanvas ] >the only problem would be determining widget size when you add a widget >to the canvas. gtk behaves sort of strange there. [ Posted this to gtk-app-devel-list as well. Reply to where you wish as I will summary. ] Should the module widgets be put to a fixed size container before they are inserted to the canvas? Or what is the problem? I tested with Glade: created a top window with one "Fixed Position" container widget, added viewport to the "Fixed Position", inserted vbox to viewport, inserted horizontal scales to each slot of the vbox. Then I took the properties of the viewport and changed viewport's position and size. Only problem appeared when the viewport size was made smaller than the minimum size of all scales. Viewport could be made very small in which case the scales were clipped agains the viewport. Is there any way to determine when the viewport becomes smaller than the vbox holding the scales? (Or the vbox larger than the viewport.) Does the viewport generate any signals in these cases? Is the viewport a wrong widget for the task? Is there any other constant size container in GTK? Regards, Juhana

20 years, 11 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 January 2004