Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

6 participants
7490 discussions

RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]

by STEFFL, ERIK (SBCSI)

> -----Original Message----- > From: Kai Vehmanen [mailto:kai.vehmanen@wakkanet.fi] > > On Tue, 22 Oct 2002, Conrad Parker wrote: > > > it might save you some hassles if you changed the intro to > jack's web > > pages, which currently read: > > > > JACK is a low-latency audio server, written primarily for the > > GNU/Linux operating system. It can connect a number of different > > applications to an audio device, as well as allowing > them to share > > audio between themselves. > > > > that, by itself, sounds to the average user an awful lot > like a general > > purpose audio server. Perhaps what you wrote in the email > below, comparing > > JACK to ASIO, would be more appropriate. > > But the second paragraph of the intro basicly already mentions > the focus: > > --cut-- > JACK is different from other audio server efforts in that it has been > designed from the ground up to be suitable for professional > audio work. > This means that it focuses on two key areas: synchronous > execution of all > clients, and low latency operation. > --cut-- 'suitable' does not mean 'exclusively suitable'. and 'focus' does not (usually) mean 'completely ignore anything else'. all in all if it can handle tough tasks I would expect it to handle easy tasks as well (which I think was the point of original post) erik

22 years, 5 months

[linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view

by Benno Senoner

If I remember correctly, the guy that wrote the VQF (an mp3-like codec) plugin for xmms (home page here:http://www.csn.ul.ie/~mel/projects/linux/vqfplugin/ ) used wine to run the windows version of the audio codec under linux. Reading form his page he has now switched to a native version of the codec but perhaps he could share his experiences with us on this list. I'll try to concact him (if he isn't already on the LAD list) and send him the URL of this thread. cheers, Benno

22 years, 5 months

Re: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]

by Patrick Shirkey

On 10/22/2002 - 04:46:47, Richard Bown said: > On Monday 21 October 2002 20:21, Patrick Shirkey wrote: > > But am I just wasting my breath because the Agnula crew are going to > > do all the work for us? > > Oh well _now_ you come on to my pet subject. > > > Anyone from the Agnula project have a position on this? > > A while ago I got involved in a flamespat with the head honcho of AGNULA > when I suggested that they should improve their communication with the > rest of the LAD community and specifically with the development teams. > I think we'd pretty much all like to know what's happening with AGNULA > (apart from the minutes of their meetings) and naively I saw it as > their job to tell us and be nice to us. > > While they do have selective communication with those that they consider > to be key people I think my fundamental mistake was to actually think > of AGNULA as an organisation. While it appears to be an organisation > it's really just a tech project - it's run by geeks and it will aim to > deliver some packaged apps and code in the time allowed. Once it's > packaged it'll ship and LAD type projects will get exposure to the rest > of the world through their distro. AFAICT that's the deal. While > that's not a bad deal of course I think AGNULA should have more of a > personality and a PR role with and in the LAD community. I've said in > the past that I think it'd benefit "them" and "us". > > But hey. I'm not going to get on my hobby horse again over that one. > No chance. No sir. > Too late :) So we are not wasting our time to debate this. There is a real problem that the professional side of this community is not really taking into account. I was sceptical that the Agnula team would be doing massive promotional campaigns. Peter you said that if we intend to make money out of Linux Audio we *should* be paying for it. Well doesn't that alsao apply to studios and professionals who intend solely to use the finished products to make money? Patrick. --

22 years, 5 months

[linux-audio-dev] latencytest problem with 2.5.44-mm2

by Joern Nettingsmeier

hello benno ! i ran latencytest on kernel 2.5.44-mm2 yesterday, and the audio was totally garbled, just barely recognizable. strangely, i could aplay somesound.wav simultaneously, and it sounded ok. (except for dropouts here and there.) might it be an oss problem ? i'm stumped. i habe never seen this before with the 2.5 kernels. regards, jörn -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)

22 years, 5 months

[linux-audio-dev] writing JACK and LADSPA apps with the ECI C impl

by Kai Vehmanen

I've just reinvented remote-procedure-calls, strings, linked lists and bunch of other stuff while writing the new standalone C implementation of Ecasound Control Interface (ECI) (ugh, C, ugh ;)). But I think the work was worth it. Next I'll demonstrate how to develop a simple app taking advantage of both JACK and LADSPA (with real-time parameter control) with a minimum amount of developer effort. If you are now wondering why I'm writing about this, jump to (6). ;) -- 1. Requirements (for this specific example) - jack-CVS installed and running - Steve's plate reverb LADSPA plugin installed - ecasound-CVS installed -- 2. The Application --cut-- #include <ecasoundc.h> int main(int argc, char *argv[]) { eci_init(); /* create the chainsetup and one chain */ eci_command("cs-add jackdemo_chainsetup"); eci_command("c-add chain1"); /* add the audio inputs and outputs */ eci_command("ai-add foo.wav"); eci_command("ao-add jack_alsa,out"); /* add an LADSPA plate reverb */ eci_command("cop-add -el:plate,50,0.5,0.5"); /* select the 3rd param (wet/dry) for real-time control */ eci_command("copp-select 3"); /* connect the setup and start */ eci_command("cs-connect"); eci_command("start"); while(1) { double curpos; sleep(1); /* fetch current play position */ eci_command("get-position"); curpos = eci_last_float(); if (curpos > 10.0) { /* at pos=10sec, quit playing */ break; } else if (curpos > 5.0) { /* at pos=5sec, set reverb length to 80% */ eci_command_float_arg("copp-set", 0.8); } } eci_command("stop"); eci_command("cs-disconnect"); eci_cleanup(); return(0); } --cut-- --- 3. Compiling gcc -o jackdemo jackdemo.c -lecasoundc --- 4. Running ./jackdemo --- 5. Dependencies --cut-- ###| ~|$ ldd ./jackdemo libc.so.6 => /lib/i686/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) ###| ~|$ du -h jackdemo 52k jackdemo ###| ~|$ file jackdemo jackdemo: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped --cut-- --- 6. The Catch The created binary, jackdemo, does not rely on any external libraries. No dependency to ecasound libraries, JACK libraries, C++ runtime, threading support... just the basic C runtime! In other words jackdemo does not create depency-hells. ;) ... PS Although the example looks simple, a lot happens underneath. 'foo.wav' is read using a double-buffering disk i/o subsystem. If jackdemo is run with root privileges, all memory is locked and realtime scheduling is used. In otherwords, jackdemo takes advantage of all known tricks to achieve reliable audio performance in Linux. -- http://www.eca.cx Audio software for Linux!

22 years, 5 months

RE: [linux-audio-dev] soft synth as a plugin

by STEFFL, ERIK (SBCSI)

-----Original Message----- > From: Likai Liu > To: linux-audio-dev(a)music.columbia.edu > Sent: 10/19/02 1:42 PM > Subject: Re: [linux-audio-dev] soft synth as a plugin > > STEFFL, ERIK (SBCSI) wrote: > > >>erm, sorry, but why not use pointers > >> > > it's dangerous... null pointers, memory leaks etc. tendency is not to > use > >pointers unless absolutely neccessary... > > > References in C++ are just pointers in a sugared form. Actually they are EVERYTHING in ALL computer languages is just sugar, all these languages (the turing complete ones) are same, apart from syntactic sugar. so your statement doesn't really say anything. > the same thing in a slightly different syntax. There is no memory safety > > in C/C++, so you end up having the same risks no matter you use pointers no you don't. just because it's still risky doesn't mean it is the SAME. C++ is quite unsafe as far as memory management goes but certain practices can lead to memory mismanagement much easier - one of the practices that can help is using references instead of pointers. when using references it's quite hard (=harder then when using pointers) to: free already free-ed memory create NULL reference have a memory leak > or references. The difference of the performance probably lies in the > fact that the compiler understands your code better with references, > hence it can do better optimizations. My guess is that references are > easier to optimize against because you don't do pointer arithmetics and > pointer type-casting on references. I don't believe there is performance difference. is there anything that suggests there is? erik

22 years, 5 months

[linux-audio-dev] alpha-SC for Linux

by kasper＠303.nu

Hi, I just heard that there's an alpha version of SuperCollider for Linux. Since I haven't seen this news on this list it might be either because it hasn't been on the list or that I overlooked it :) You can download it here: http://swiki.hfbk-hamburg.de:8888/MusicTechnology/422 (and with .tgz it seems a gzipped file, but it's just a tar!) (Too bad I still can't test it myself because of lack of jack, or to be precisely, ALSA...) bye, Kasper

22 years, 6 months

Re: [linux-audio-dev] soft synth as a plugin

by Bill Schottstaedt

>>indeed, for a plugin soft-synth, it would only ever make sense to write >>it in c/c++ or assembler really, a question of speed. Are there really >>people who seriously want to write a synth in aynthing else? > OTOH, CLM is written in Lisp, (hence the name), and some modern Lisps > (i.e. CMUCL) claim to be as fast as C for floats. So I suppose you could write DSP > code in Lisp if you really wanted to. I did some timing tests in cmucl and was amazed at the performance it was getting -- it is close to C, but (sigh... there's always a catch), you have to be extremely explicit about types, so all that beautiful lisp code gets buried under type declarations. At least the cmucl guys are making progress in this area. In normal use, CLM "instruments" are translated into C and run as foreign functions (so all the DSP stuff is happening at C speeds), and lisp provides an interactive environment to work in (the "listener"). So, yes it is perfectly possible to do real-time synthesis while writing the DSP-related code in Lisp/Scheme; there are examples in both CLM and Snd.

22 years, 6 months

Re: [linux-audio-dev] alpha-SC for Linux

by Stefan Nitschke

> >It builds fine with gcc3 after a bit of auto* hackery (ran ./ltconfig >ltmain.sh, automake -a), but there is no UI yet, so you can't see what >you're doing. > I am not so lucky yet... anyway i saw that SC does use both C++ and ObjC. I thought its not possible to mix them with gcc. Would be realy cool if that has been fixed with gcc3. - Stefan _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp

22 years, 6 months

Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]

by Tom

> > >The occasionaly discussed jack session > > > saving gizmo would be a knock dead feature. > > > > And any offering to the general public that doesn't contain this feature > > will probably end up just plain dead. Be patient. > > > I'm not a patient man ;) I didn't mean you. I meant that anyone interested in announcing linux audio to the world should wait until this level of functionality is present. I'm not suggesting that anyone delay development of the gizmo. The closest thing that I have used is OMS on the mac. It's quite different than a jack environment but it does allow me to save synth midi routings and send/receive channels, and provides synth names to midi apps so I can refer to them directly in my sequencer app. Tom

22 years, 6 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