Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] Looking for some PR stuff related to Jack

by Ivica Bukvic

Hi all, I am currently writing an article talks (among other things) about Linux as one of the currently viable pro-quality-audio platforms. I am trying to get a hold of some specs in relation to JACK, so I'd appreciate it if you can give me a quick rundown of the following information: All of these pertain to ALSA or JACK: 1.) What is the lowest stable achievable latency with the current stable (2.4) branch of the kernel (with ll and preempt patches) using Alsa on a modern system (i.e. at least 1GHz machine)? 2.) What is the lowest stable achievable latency utilizing app<--->jack<--->audio hw kind of setup on a modern system (i.e. at least 1GHz machine) with the current stable (2.4) branch of the kernel (with ll and preempt patches) using Alsa? I would appreciate it if you restrict your responses to simple numbers (i.e. 1) 1.6ms 2) 2ms ) since I do not have the time to have a discussion on this matter, but am rather looking for a quick list of testimonials in regards to the two given questions. Thank you for your help! Sincerely, Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster & computer consultant http://meowing.ccm.uc.edu/~ico/ ============================ "To be is to do" - Socrates "To do is to be" - Sartre "Do be do be do" - Sinatra "I am" - God

22 years, 11 months

[linux-audio-dev] Re: OSX

by Bill Schottstaedt

> it's much easier to port from Un*x to OSX > than vice versa. A far greater number of > *nix libraries have been ported from the *nix world to OSX than the > other way around. You can even run X windows > on OSX I think "OroboroSX", or some such name, is an X window manager for OSX that makes X apps fit in with Mac apps so it's not obvious which style is running. Gtk and Motif have been ported, so the GUI is not a big issue. The audio side is still primitive, but easy to use. Porting Snd took a few days, mostly spent chasing down dumb things like the -framework loader switch. I'd say it took about the same effort overall as porting to the Sun.

22 years, 11 months

Re: [linux-audio-dev] Looking for some PR stuff related to Jack

by Benno Senoner

Paul what you described is very unfortunate. Although I have not had time to perform any tests lately, I always had the bad feeling that the out-of-process model would cost us some performance because the kernel would screw us in some way. As said, two years ago I was able to achieve 2.1msec latency with the LinuxSampler proof-of-concept code and I think for many low-latency fetishists (a drummer playing a midi drumkit) it would be hard to give up these excellent response times especially since we are talking about a software implementation of a MIDI instrument that ideally should as be as good as the hardware counterparts in terms of playability. Regarding the sampler we are currently solving other basic design problems so for now I think we can let this issue aside since we will probably perform the first tests with direct ALSA/OSS output and standard out-of-process JACK mode (in the latter case not expecting to get extremely low latencies), but in order to get latencies at par with ALSA , when using JACK the in-process model is as you said probably mandatory. (and according to Steve Harris JACK would need some extensions to handle the loading of these in-process jack "plugins" at run time). For now we will probably test the extremely low latency cases using direct audio output otherwise it would be hard to isolate timing problems. (Was the deadline miss due to the sampler or due to jack not getting scheduled in time ? -> double frustration :-) ). Paul, do you think that in (near) future it will be possible to run an entire virtual studio using jack's in-process model that runs all active apps (eg ardour, sampler, snyth, FXes etc) as plugins of a single process ? This would be really useful for those that need these extremely low latencies while at the same time being able to access to a fully fledged virtual studio where your only limitation is the CPU speed and RAM/disk speed/size. cheers, Benno Paul Davis wrote: > the JACK data i provided covers an out-of-process client. the > all-in-process client case has the same latency as ALSA only. > > the difference between the two is that although 99.9% of the time, the > kernel operates as desired and JACK can provide ALSA-only/in-process > performance in the out-of-process case, every once in a few tens of > thousands of process() cycles, the kernel messes up our scheduling and > this causes an xrun. tracking this down is an important but very, very > difficult case. its possible that it may never be solved. > > --p -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

22 years, 11 months

Re: [linux-audio-dev] Gigasampler vs Halion PR war

by Benno Senoner

I suspect that Steinberg (and others) went the wait-and-see attitude. They recognized that the patent was simply too broad and that an eventual lawsuit would have caused quite a controversy in the audio world. (Perhaps damaging good relations between Tascam and other audio sw producers, generating bad press and probably in the end resulting in the patent declared invalid). Plus it seems that soon there will be new contenders on the commercial disk based samplers area.I believe that regarding the patent they took the same stance as (probably) Steinberg did. For example Native Instrument announced that they will add disk streaming support to their Kontakt sampler this month. ---- http://www.nativeinstruments.de/index.php?kontakt_us Direct From Disc extension In November 2002 a free Mac and PC update for registered KONTAKT users will add the Direct From Disc extension. This feature will enable KONTAKT to play samples directly from the hard drive. Sample size will no longer be limited by the amount of physical RAM - an instrument can be as large as available hard drive space. All instruments utilizing this technology will load many times faster than RAM-based instruments. --- You are probably aware that Invision has a patent about the PC softsynth this means that there are literally hundreds of such apps "violating" the patent. The idea of caching data in RAM that resides on a mass storage device is just too old, it has existed since the first mass storage device was introduced. Anyway if you care, in the good old Amiga days I implemented routines that allowed the streaming of large audio clips from disk and CDROM with instant play by caching the first part of the clip in RAM. It was 1991-92 I believe the project was part of an italian version of the Grolier Encyclopedia for the Amiga and that strange CD-like player amiga device. (I do not remember the name anymore). This is just a small example of "prior art" :-) I guess there are hundreds other of examples too. I fully agree with what David Burrows said. :-) cheers, Benno Paul Davis wrote: >>Do we know what Steinberg did about this, if anything? >i asked karl steinberg. he was unwilling to say anything about it. -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

22 years, 11 months

[linux-audio-dev] Gigasampler vs Halion PR war

by Benno Senoner

Gigasampler / Gigastudio vs Halion "comparison": http://www.nemesysmusic.com/news/NewsLet/newslet_Mar2002.html no comment :-) Benno -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

22 years, 11 months

[linux-audio-dev] spiced 12AX7, plots, clipper.so

by Tim Goetze

after taking some plots from a simple 12AX7 preamp spice model, i've decided to try naive asymmetric hard-clipping, without any antialiasing measures. http://quitte.de/12AX7-clipping.html has the plots, a link to the spice model source, the hard clipper ladspa implementation and the mandatory mp3: http://quitte.de/brat.mp3 which is the output from this signal chain: guitar (bridge pickup, humbucker) -> HiPass (200) -> Gain (db = 30) -> clipper.so -> unmatched.so it may not be a true amp model, but to me ... it rocks. i'm still pondering whether antialiasing is needed, and if so, how to do it (fit in a windowed sinc where the signal hits the clipping threshold? thoughts welcome). for building a decent 'virtual amp', i imagine some combination of Steve's excellent valve and valve_rect for a good, smooth and warm lowish-gain tone, a bit of tunable eq and this kind of hard-clipping for hi-gain, harsh distortion topped off with a cabinet response will just about do it for me. tim

22 years, 12 months

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

by John Lazzaro

> Paul Davis <paul(a)linuxaudiosystems.com> writes: > > OS X is a major challenge to the linux audio religious faithful. It's an opportunity, too, though -- there's a segment of the Mac population that can barely justify the cost premium for Mac hardware, because they use the hardware for recreation or avocation, not as a tool to make more money. If the Linux folks: -- Port the popular apps to OS X, and improve them so that the honest and budget-conscious Mac folks adopt the free Linux apps rather than pirate commercial apps. -- Keep those apps running just as well (or better) under Linux, and evangelize the hardware cost differential. Linux audio could probably carve out the budget-conscious Mac subset over a period of 3-5 years, which (random guess) is 100,000 users or so. That's not my motivation for putting sfront on OS X -- that has more to do with just reaching more users to popularize the underlying standards -- but it might be a motivation for the mainstream Linux GUI audio apps to start a serious OS X porting effort. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 12 months

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

by CK

Thanks paul, I have this problem once in a while as a die hard opensource fan I didn't go out and buy software for years now and - a point that even in the linux community many people don't seem to understand - not because I'm a cheap- skate or ex-w4r3z kid that doesn't understand how commercial sw production works (no that I would but I guess I get the overall picture) _but_ because also on an application level I want to have access to the sources, to tailor to my needs, to figure out inner workings without bothering tech support, to fix things. I had this discussion with a cycling74 employee recently explaining that I might buy max/msp but _not_ without sources, I'd sign their soul-demanding NDA, pay more - whatever to be able to change #define MAXINLETS 64 in any objects src to what I believe is needed ... I read: [very insightful posting snipped] > improve it. OS X does not let me do this because it isn't as > tinker-friendly as linux. make this a 'thinker-friendly' aswell (SCNR maybe it's because I'm .eu) cheers, x -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

22 years, 12 months

re:[linux-audio-dev] Open Music

by assayag gerard

> From: David Gerard Matthews <dgm4+(a)pitt.edu> > To: linux-audio-dev(a)music.columbia.edu > Subject: [linux-audio-dev] Open Music > Date: 25 Oct 2002 23:39:57 -0400 > > Is anyone working on this: http://www.ircam.fr/equipes/repmus/OpenMusic? > Apparently they GPL'd the sources, and you can download it, but it's > written in Lisp, and MCL PPC Lisp at that. However, as they put it: > > "At the beginning, this will make sense only to people owning the > Digitool compiler. Although we are conscious that this limitation does > not fit clearly into the GPL framework, we think that making the sources > available is an oppurtunity to raise collaborations leading to new > versions of OM that would depend only on open sources compiler, > particularly on linux platforms" > > I did speak with some Ircam people at Darmstadt this past summer, and I > don't think they really have the interest in doing the port themselves. > However, Ircam certainly isn't anti-Linux, so they might be > able/willing to help/be persuaded to work on it. (François, and > Norbert, if you're on this list, feel free to comment.) > > -dgm Until now, we did'nt have the internal resources to develop a full linux version of OpenMusic. However a fragmental prototype of OM/Linux based on cmucl had been developed by Camilo Rueda and his team at Cali Univsersity in Colombia. See http://escher.puj.edu.co/openmusic/ Things are changing now, thanks to the Agnula (A GNU Linux Audio Distribution) project. This project is funded by the European Commission, coordinated by Tempo Reale in Florence, and involves Ircam (coordinator : Francois Dechelle) as a partner. See http://www.agnula.org/ Thanks to Francois Dechelle's support, we may now envision the integration of OmLinux in the following monthes, as well as the definition of a coherent development strategy between OMLinux and OM/OsX. More info to come soon... Gérard Assayag Music Representation Team IRCAM

22 years, 12 months

[linux-audio-dev] work is what happens while we're debating GUIs

by Paul Davis

this is a VSTi: http://www.harmony-central.com/Newp/2002/Oddity-large.jpg slurp ;)

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