Linux-audio-dev October 2002

linux-audio-dev@lists.linuxaudio.org

115 participants
142 discussions

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

by Stefan Nitschke

>From: Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> >On Tue, Oct 22, 2002 at 09:38:26 +0200, Tim Goetze wrote: > > the problem with converging IIR is that either the IIR or the > > converging algorithm or both don't like impulses that are too > > lively. the converger will simply fall dead when it sees an > > exponentially decaying white noise impulse. it makes sense, > >I don't understand why. Is it just beacuse the kernle is a bit too long to >be stable, or is there someting more to it than that? > When the converger tries to find the best coefficients by using a recursive error minimation i dont wonder that i may fail here. A IIR is nothing else as a differential equation solver. As a result you can only approximate kind of periodic signals i guess. Correct me if i am wrong, its quite a long time ago since i learned about linear system theorie and IIR stuff... - Stefan _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp

23 years, 1 month

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

by John Lazzaro

> Lea Anthony <stonekeeper(a)stonekeeper.freeserve.co.uk> writes > > Wishing for people to write native apps for a system with no market is > like wishing Windows would die. It might happen, but it's not bloody > likely. However, if you port a novel Linux application to Windows or OS X, the users on those platforms are quite happy to add the free tool to their workflow if it helps them do their work better. This is how the GNU project got its start, after all -- free, usable software that ran on popular commercial UNIX platforms. Sfront has taken this route -- most of my users are non-Linux users now. I think there's a migration path to Linux that could be based on this strategy -- if the free software community comes up with a set of audio content-creation tools that Windows or OS X users are willing to use as a complete workflow, the case for switching over to Linux to run the workflow more efficiently (or to avoid OS license upgrade fees, etc) is easier to make. Certainly on the CLI side, many people started out at Cygwin users to run emacs and gcc and TeX under Windows, and then decided to add a dual-boot option for Linux to get "the real thing." ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

23 years, 1 month

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

by STEFFL, ERIK (SBCSI)

> -----Original Message----- > From: Joshua Haberman [mailto:joshua@haberman.com] > > "Paul Davis" <paul(a)linuxaudiosystems.com> wrote: > > >So why, having studied the docs, am I completely stumped > with jack? It > > >refuses to play. I don't consider any solution based on a > piece of software > > >_I_ can't operate suitable for general use. > > > > JACK *isn't* intended for general use, and i get tired of > suggestions > > that it should be. there are lots of people working on solutions for > > "general use". JACK is intended for people who are serious about > > audio. > > I don't understand this attitude. I think it hinders > acceptance of JACK > (even for serious audio) and it contributes to further > fragmentation of > the Linux audio world. > > If you would rather everyday applications not use JACK, what > should they > be using instead? OSS is simple but limited, and spotty > drivers/implementations make it difficult to write robust > code. It will > soon be available only through emulation. It forces use of > the blocking > model. > > ALSA is very powerful and complete, but very complex. This will make <rant> it is also pretty much useless for general users. I mean if I can't listen to mp3 and browse the web at the same time ... (without sound servers which were discussed recently and as far as I can tell the general consensus is that they are bad and not to be used). Is there any rationale for the blocking behaviour? I mean I can't imagine situation where I would want playback to wait for another playback to finish and play sound then... either report error (device busy) or just ignore the sound... (or do the mixing) as far as I know this behaviour is not configurable - am I mistaken? (rarely I wish to be proven wrong so much:-) maybe this is not the best place for a rant but since we are discussing the acceptance of linux in audio world, here's my own experience. except of the blocking of sounds (the problem mentioned above) I am quite dissapointed by functionality of linux drivers I have tried, I have sb live platinum and (last time I checked): - front panel midi connectors do not work - game port midi functionality - sort of works, works OK with one keyboard but does not work with another midi controller (yamaha drum toy) (both work fine with front panel midi under windows) - front panel RCA connectors do not work - infra red sensor probably does not work (at least I wasn't able to make it work and I got no responses on lasa mailing list) </rant> erik

23 years, 1 month

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

by Benno Senoner

> I don't know if the 3 points I've made have already been done, I'm new > to LAD, but they are important. Especially 3 as it gives a "migration > path" to existing windoze users. I know, I know, DirectX plugins are > written against Microsoft libraries, but how come mplayer on Linux can > use windows binaries (codecs) in it's system? Could the same not be >done >for audio? Surely it's the same principle? (Media data input, process, >media data ouput). Yes this should be possibile since both DirectX and VST are documented APIs. Form a latency point of view, I am not sure how this works out, but I believe the process() calls do not involve windows specific stuff so the plugs should perform quite well on a low latency kernel. Of course almost any DX, VST plugin do have a GUI. The ideal would be letting wine to display the GUI part while executing the process() stuff directly. I am not a wine expert so I cannot say how difficult this can be, but given that wine is able to execute beasts like Word and Excel I guess it has not problems with plugin GUIs. Indeed the ability to run DX and VST on Linux would be a good selling point for pro audio on linux but there is still lot to do in the fields of basic audio platform infrastructure and integration of the different components. cheers, Benno

23 years, 1 month

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

by Benno Senoner

Hello Joern, Are you using ALSA right ? Perhaps an OSS emulation problem of ALSA ? I recall that I got grabled sound (even lockups) on the SBLive when using 128byte fragments (seemed like a driver or hardware problem). What kind of audio card do you have ? Anyway latencytest is completely outdated (does not compile cleanly on newer distros due to wrong includes etc). Now that I have some spare time again (seems unbelievable but I were able to finish my university degree in CS just a month before turning 30 ... better late than newer as we use to say :-) ) I'll try to rewrite some of the useful tools including latencytest, adding alsa support and new stress test methods and like one guy of the list asked , the possibility to chose the disks (or the path) on which perform the disk i/o tests. Anyway low latency came useful in my thesis since a part of the project consisted in a real time laser scanner that tracks a laser spot that you move over the object you like to scan that is filmed by two cameras that permit a 3D reconstruction of the surface. (at 25 FPS we have processing cycles of 40msec so it is quite easy for the low lat patch to keep up since there is basically no disk i/o present during the scanning activity). cheers, Benno. --- You wrote: 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

23 years, 2 months

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

23 years, 2 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

23 years, 2 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. --

23 years, 2 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)

23 years, 2 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!

23 years, 2 months

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

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 October 2002