Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt + alsa + jack = dead computer

by Fernando Pablo Lopez-Lezcano

> >I browsed the Kernel Source and there is only one mark_inode_dirty in > >pipe_write (in fs/pipe.c). So we know where it is hanging... > > > >And in __mark_inode_dirty (in fs/inode.c) there is one > > spin_lock(&inode_lock) > >call, and I guess that is where the whole thing is hanging. So something > >is holding that lock... how do I find out who is doing that? Apparently > >the handling of inode_lock is confined to inode.c. I'll keep reading. > > > >Maybe the pipe in question is one of the pipes that jack uses for ipc? > > seems *damn* likely ... sorry to just be chiming in with a useless comment! Do you think the problem might be jack? Some race condition that only happens (or is much more likely to happen) in 2.4.20? It does sound more like a kernel bug, but I have not seen a hung machine without having jack and clients running... -- Fernando

23 years, 1 month

RE: [linux-audio-dev] 1.5 ms latency possible?

by David Seymour

Actually what I'm talking about is simply monitoring. Tons of people have trouble monitoring when recording digitally simply becayse that can't monitor off of the A/D in real time. The RME DSP and the Lynx cards take care of this with a seperate digital router that basically takes the digital signal off of the A/D and shoots it right back to the D/A to send out to the console or headphone system for monitoring. You can then toss on any FX you desire. I honestly set up a distant mic for my reverb stuff and put digiverb on it if the singer needs it. David Seymour Benchmark Media Systems 800-262-4675 www.benchmarkmedia.com -----Original Message----- From: David Olofson [mailto:david@olofson.net] Sent: Thursday, January 02, 2003 10:25 AM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] 1.5 ms latency possible? On Thursday 02 January 2003 16.21, David Seymour wrote: > Would it be safe to say that trying to lower latency within the > system for monitoring purposes is simply a waste of horsepower > given the availablilty of I/O cards with routing DSP build into > them? I know LYNX and RME have cards that will do this. Depends on what you mean by monitoring. These audio interfaces generally have no DSP "effects" whatsoever, so as soon as you need basic EQ or whatever, you're out of luck. (AFAIK, this goes for the the cards you mentioned, as well as all Echo cards, and all Envy24 based cards.) So, if you're using external hardware for all effects, you're probably fine with ZLM. The audio interface will basically work like a patch panel in your analog system. If you do everything virtual, you can't even set up basic monitor sound, since that usually requires at least a simple reverb. (Dry signals and headphones don't mix...) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---

23 years, 1 month

RE: [linux-audio-dev] 1.5 ms latency possible?

by David Seymour

Would it be safe to say that trying to lower latency within the system for monitoring purposes is simply a waste of horsepower given the availablilty of I/O cards with routing DSP build into them? I know LYNX and RME have cards that will do this. David Seymour Benchmark Media Systems 800-262-4675 www.benchmarkmedia.com -----Original Message----- From: David Olofson [mailto:david@olofson.net] Sent: Tuesday, December 31, 2002 5:35 PM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] 1.5 ms latency possible? On Tuesday 31 December 2002 23.24, Anders Torger wrote: [...] > I've thought about RTLinux actually, but it is simply too much > work, porting drivers to start with... You can probably get away with using normal drivers (OSS or ALSA) in mmap() mode, and hooking the interrupt with an RTLinux or RTAI ISR. Start up the I/O from user space as usual, and then divide the IRQ period into the number of fragments you need, using an RTL or RTAI periodic thread. Just keep in mind that PCI cards generally have a 64 byte PCI burst size limit, so going below that won't work. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---

23 years, 1 month

[linux-audio-dev] [Fwd: ams segmentation fault]

by Eric Dantan Rzewnicki

I don't know whether this is a bug in ams, or a problem with my system...I suspect the later, but can't figure out what's wrong. But, I am unable to get ams to run. It appears to compile OK. But, as noted below, running it results in a "Segmentation fault". I have installed qt3 and fftw. I edited the top of make_ams to match my system: box1:~/audio_code/ams-1.5.5$ head -5 make_ams QT_BASE_DIR=/usr/lib/qt3 QT_LIB_DIR=$(QT_BASE_DIR)/plugins-mt/styles QT_BIN_DIR=/usr/bin QT_INCLUDE_DIR=/usr/include/qt X11_LIB_DIR=/usr/X11R6/lib My ditribution is Debian stable (woody). My system is a PII 400Mhz w/768MB RAM. The version of g++ is 2.95.4. I have a working install of jackd 0.44.0 from cvs. I'm starting jackd like so: # jackd -v -R -d alsa -d ymfpci -r 44100 -zt -n 3 -p 512 I can start up multiple instances of jack_metro, connect them to the alsa ports and hear the beeps. So, jack appears to be working. But, if I start ams nothing is reported in the jackd output about a new client. ams does attempt to connect to the X server when started. I know this because if I 'su -' to get to root and then start ams: box1:/home/eric/audio_code/ams-1.5.5# ./ams ams: cannot connect to X server but, if I su without the dash so that root inherits my user environment ams gets past the point of connecting to the X server (assuming that comes first) and exits with a segmentation fault. I'm not sure what other information would be useful to you in helping me to sort this out. If there is anything else I should tell you, please let me know. Thanks in advance, Eric Rz. -------- Original Message -------- Subject: ams segmentation fault Date: Sat, 28 Dec 2002 21:47:34 -0500 From: Eric Dantan Rzewnicki <eric(a)zhevny.com> Organization: zhevnycom To: Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> CC: linux-audio-user(a)music.columbia.edu References: <3E0BCBEC.9DB82093(a)zhevny.com> <20021227103148.GH681(a)ecs.soton.ac.uk> <1041005858.4921.17.camel@eviltwin> <20021227181307.GD19938(a)rfa.org> Eric Dantan Rzewnicki wrote: > I can now start jackd as root and > then start ams -j. Sorry I didn't think of this earlier. :-\ > > Adding /usr/local/lib to /etc/ld.so.conf and running ldconfig as Steve > suggested allows ams to find libjack.so.0 (I really should have > remembered that piece, too). > > Now that I have it running I'll go finish reading the ams documentation > and figure out how to use it. :) hmm... I perhaps spoke too soon. I had ams working yesterday on one box (at the office)... But, now I can't seem to get it working at home. It seems to compile fine, but when i try to start it: box1:/home/eric/audio_code/ams-1.5.5# ./ams Segmentation fault box1:/home/eric/audio_code/ams-1.5.5# ./ams -j Segmentation fault It doesn't matter if jackd is running or not. Either way it seg faults... What could cause this? What information should I provide to help sort this out? Thanks, Eric Rz.

23 years, 1 month

[linux-audio-dev] 1.5 ms latency possible?

by Anders Torger

I have made a program which is to be run on a dedicated computer, equipped only with a multichannel soundcard (hammerfall), a small LCD and a remote control. This forms a dedicated surround processor (if interested in the software, look at http://www.ludd.luth.se/users/torger/almusvcu.html) for use in multichannel HiFi systems. In some configurations, a 64 sample processing block is relevant, leaving a total IO-delay of 128 samples, which in 44.1 kHz is about 3 ms. With such a configuration, I have got the system going for a few hours at most before underflow. Of course the relevant processes are realtime scheduled, I have even used tricks with sched_yield to get the processes yield in the right order (I will probably have to pay for that sooner or later though) for the most safe operation. So, my question to this list is if someone has run a similar system for days without underflows, and if there is some guide or tips on how to put together the for the moment best low-latency kernel, if there are kernel features that should be avoided, some bad driver or filesystem perhaps, and if there are some hardware setting tricks (apart from giving the sound card the highest interrupt priority). Perhaps tips on which user space processes that should not run (I have no syslogd or cron, but sshd is running) Is it even possible today to build an embedded system with 1.5 ms processing block based on Linux, which runs until hardware or power failure? Oh, my software does not necessarily need to access any filesystem while it is processing, although it would be good if it could (to continuously save volume settings and similar if changed through the remote control). So it can be seen as a strict soundcard-to-the-cpu-and-back problem. /Anders Torger

23 years, 1 month

[linux-audio-dev] |ANN| Autocomp 0.0.5

by Wayne Myers

Hi, Autocomp is an automatic accompaniment generator for Perl and Csound, developed on Linux. It's an attempt at a practice utility for musicians. Freshmeat project page is here: http://freshmeat.net/projects/autocomp/ Download it or read more here: http://www.waz.easynet.co.uk/software.html Currently there is only one style of output, which is a pastiche of a 'swing' style with a walking bassline. The output is heavily on the gorgonzola side of cheesy, but it's already at a stage where you can practice with it if you don't mind the cheese level. All comments/suggestions etc gratefully received. Cheers etc., Wayne -- Wayne Myers http://www.waz.easynet.co.uk/

23 years, 1 month

Re: [linux-audio-dev] Software Setup

by Patrick Shirkey

>Actually I'm just asking because I want to see how good jack is and how >it works before we start to add jack support to glame. Works well for me. Having jack support increases the liklihood of more people using glame too. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman

23 years, 1 month

[linux-audio-dev] [ANN] ALSA Patch Bay 0.4

by Bob Ham

Mmm.. releases :) Biggest thing is that it now listens to changes in alsa and automatically refreshes. * made a nice dlopen() system for GUIs and drivers * ladcca support * major amounts of code cleaning up and seperating (eg apb.h -> 6 .h's:) * bug fixes * compilation fixes * listens to alsa changes in a thread * gtk gui now uses a proper toolbar with stock buttons http://pkl.net/~node/alsa-patch-bay.html Bob

23 years, 1 month

[linux-audio-dev] Software Setup

by Alexander Ehlert

Hi all, I'm just curious about the software setup people use here to play around to make music. Furthermore I'd be interested what software setup people use to use jack. I was recently wanted to try out jack so I just installed the debian packages of jack and the alsaplayer with jack out, but wasn't really successfull. So before I start building lots of apps, I just wanted to know what is worth being tried out. Cheers, Alex

23 years, 1 month

[linux-audio-dev] nice plugin review

by Paul Davis

from electronic musician (dec/2002): "Polish developer Professional Sound Projects (PSP) has introduced a plug-in emulation of Lexicon's PCM 42 hardware, and it bears investigation. But first, I must make a disclosure. I designed the Lexicon PCM 42, so this won't be your usual review. I can't claim total objectivity, but I hope that I can offer some insight. ..." (actually, its a very, very normal EM-style review. too bad, after such a great start). --p

23 years, 1 month

Jump to page:

2026

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