Linux-audio-user August 2008

linux-audio-user@lists.linuxaudio.org

130 participants
106 discussions

by sh0099

is there a firewire or usb soundcard wich would have the same quality and low latency as the rme-(cardbus/expresscard)-multiface together with a rme-quadmic? i think i dont need the big number of channels... any suggestions? thanks olaf

17 years, 5 months

[LAU] real time in Debian...

by Preston C.

I have Debian installed and was wondering if it was possible to get a real-time kernel in Debian? I do not want to use 64 studio, but was hoping for a site like Planet CCRMA for Fedora, just for Debian. Is there anything like this? Many Thanks, Preston

17 years, 5 months

[LAU] Creating a new distro dedicated to MIDIBox and audio/midi development

by simone-www.io-sound.org

Hi we are on our way to create a special distro dedicated to MIDIBox development tools Please have a look at this thread : http://www.midibox.org/forum/index.php/topic,11913.0/topicseen.html if you want to give your opinion/input and don t want to sign up at MIDIBox i can forward your messages, copying and pasting this thread If you don t know what MIDIBox is have a look at www.ucapps.de Simone -- .wmv , .wma , .pps along with all proprietary Windows formats won t be accepted and/or viewed....

17 years, 5 months

[LAU] question about RAM amount

by Dave Phillips

Greetings, Yet another round of upgrades here. I installed another gig of RAM in each machine. The JAD box (32-bit) reads correctly at 3.1 G during the boot, but the 64 Studio box reads only 3.67 G. It's supposed to be 4 gigs, what happened to the rest of it ? Mobos are identical Gigabyte boards, CPUs are both AMD64, so the amount should be supported, yes ? Video boards are also identical, with 512 MB on-board memory. The BIOS and dmesg yield the same report. Did I miss something ? DIMMs not arranged properly, or ... ? Best, dp

17 years, 5 months

[LAU] [ANN] Realtime priority patch for the linux kernel, jack_capture V0.9.23 and Rollendurcmesserzeitsammler V0.0.4

by Kjetil S. Matheussen

Download from: http://old.notam02.no/arkiv/src/?M=D Realtime priority patch for the linux kernel ============================================ To make sure the Linux kernel is able to grant realtime priority, and full nice and mlock capabailites can still be a little bit inconvenient and/or frustrating. However, this super-tiny patch: http://old.notam02.no/arkiv/src/realtime.diff against the linux source shortcuts all other methods. No more pam, realtime-lsm, rtlimits etc. jack_capture ============ jack_capture is a program for recording soundfiles with jack. Its default operation is to capture whatever sound is going out to your speakers into a file. (But it can do a number of other operations as well...) Changes 0.9.19 -> 0.9.23: *Minor spellings *Check for out of memory *Clean up source a bit *Stop connection thread before closing jack client. *Made --help a tiny bit cleaner *Removed shut down code from the SIGINT signal handler. *Fixed segfault in case jack shuts down. Thanks to Julien Claassen for reporting the bug. (Note that there is also a 0.9.24 release. 0.9.24 has changed internal data representation from lockless ringbuffer to lockless lifo and fifo stacks. (Unmodified lifo/fifo code taken from midishare. (Copyright Grame 1999-2005)) 0.9.24 probably works fine, but it shouldn't be used for important recordings since it hasn't been much tested yet.) Rollendurchmesserzeitsammler v0.0.5 ------------------------------------ The Audio Rollendurchmesserzeitsammler is a conservative garbage collector especially made for running inside an audio DSP thread. New about this release is that I have finally replaced TLSF (http://rtportal.upv.es/rtmalloc/) with a pool-based dynamic memory allocator, which makes allocation using the rollendurchmesserzeitsammler approximately as fast as using custom memory pools. Using the rollendurchmesserzeitsammler should be a lot more convenient than memory pools though, and since memory is not freed manually, but instead is automatically freed in a separate thread, there is a slight chance that using rollendurchmesserzeitsammler instead of custom memory pools could make some DSP code run faster. In non-synthetic benchmarks, I have not been able to see any significant improvement in CPU use because of this compared to using the TLSF allocator. But for programs doing millions of allocations per second, the new memory allocator will probably perform significantly better than TLSF, if it would ever make sense doing so many and frequent allocations of course... Changes 0.0.4 -> 0.0.5 * Implemented a custom pool-based dynamic memory allocater. This new memory allocator is now set as default. To use TLSF instead, set "USE_TLSF=-DUSE_TLSF" in the Makefile before compiling. The following changes are caused by this switch: * Allocating memory is now approx 10 times faster (13 vs. 168 instructions for the allocation itself, but there are some GC overhead too) * The allocator copies used memory only (not just the whole heap). But not always! This was a lot more complicated to to with TLSF so I didn't do that. Note that for the garbage collector to still be hard realtime safe, the programs must ensure that full copies are taken now and then. (There's a change in the API for doing that) * Doing a garbage collection is much faster since the heaps are usually much smaller (because only used memory is copied) and that freeing is 10-20 times faster. * Further improvements for reducing memory overhead and make searching for used mem to be O(log n) instead of O(n) is much simpler now. (this is TODO though) * However 1: In case the code using the garbage collector will continue forever to allocate memory of different sizes, the new dynamic memory allocator could eventually run out of memory even if the program itself doesn't use very much memory. I don't think this is very likely to happen for DSP routines though, and there might even be solutions to fix this problem if it should ever come up. For now, just switching to TLSF fixes the problem. * However 2: in non-synthetic benchmarks, I have not been able to see any practical improvement in CPU use, apart from the slight improvement in CPU available for use in non-realtime threads because taking snapshots usually takes a lot less time now. But for programs doing millions of allocations per second, the new memory allocator will probably perform significantly better than TLSF, if it would ever make sense doing so many allocations of course.

17 years, 5 months

[LAU] JACK with many soundcards

by Adrien DANIEL

Hi ! I am wondering how to use JACK with more than one soundcard. For instance, what if I want to get one of the inputs of my soundcard #1, process it with a JACK program, and finally send it to one of the outputs of my soundcard #2 ? Should I launch several JACK deamons ? If so, would I be able to interconnect them ? Any idea ? Thanks ! Adrien NB : I cannot test anything, because I only possess one soundcard for the moment... NB2 : I have reposted this message because I think that my first post was in HTML, sorry !..

17 years, 5 months

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-user August 2008