Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7444 discussions

Re: [LAD] Car engine sound emulation for future electic cars. ideas

by Kjetil S. Matheussen

Fons Adriaensen: > > The data used by car manufacturers to describe engine noise > is a spectral description, where some small divider of the > RPM (depending on engine configuration) is regarded as the > funcdamental frequency. For each harmonic you have a smooth > amplitude map in function of RPM and throttle position. > > Staring from these it's not so difficult to synthesise > something quite realistic. > The company "Staccato" tried to provide synthesized car sounds for race car games in 1999, according to this page: http://www.scandalis.com/Jarrah/PhysicalModels/index.html

16 years, 2 months

Re: [LAD] embedded high end audio

by Pieter Palmers

Florian Faber wrote: > Peter, > >> I doubt that it is easy over a transport protocol that doesn't have a >> global absolute time reference (like ethernet). > > What time reference do you have in mind on ethernet that can be used as > word clock source? My formulation is a bit unfortunate. I mean that ethernet does NOT have a global absolute time reference. And word clock is not a time reference. It's a 'rate' reference, which does not contain absolute time information. What you need to output signals on different devices with sample accurate phase is an absolute time reference. Which ethernet does not have. Greets, Pieter

16 years, 2 months

Ladspa: Text encoding for metadata fields

by David García Garzón

I have some doubts, as both host and plugin programmer, regarding the text encoding that should be used for Ladspa v1 metadata fields. Is there any convention? Utf8? Is it limited to plain ASCII? Which fields are restricted and which are not? I supose that unicode is supported in some way as many 'makers' have weird signs on their name but the header-documentation does not provide any answer to that. David García Garzón.

16 years, 2 months

[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.

16 years, 2 months

Re: [LAD] [OT] vector drawing software

by Kjetil S. Matheussen

Fons Adriaensen: > > Inkscape lookd more and more as some GUI interface > to Cairo. ATM I can write the Cairo code a lot > faster than using the GUI... > I was just about to suggest writing Cairo code. :-) pgf/tikz is probably faster than programming cairo though. But what would be really nice would be a programming interface for pgf/tikz.

16 years, 2 months

Re: [LAD] [OT] vector drawing software

by Kjetil S. Matheussen

Fons Adriaensen: > > Anyone knows a good vector drawing program for Linux ? > > Absolute requirements are: > > - Lines, arrows, boxes, circles, etc. > - Linewidths and styles, colors, filling. > - Text > - PDF or PS export. > - PNG and JPEG import (no bitmap editing required). > - Accuracy. > > I've been using TGIF for years, but I'm more and > more being blocked by its main flaw which is that > it seems to use a unit of 0.2mm internally (in > metric mode) which is orders of magnitude too big. > > Tried QCAD and INKSCAPE, both fail basic > requirements (and have other problems). > > Maybe pgf / tikz would be useful? http://www.ctan.org/tex-archive/help/Catalogue/entries/pgf.html

16 years, 2 months

jack, kernel, etc. versions & priorities

by Garett Shulman

Hello, I had a great performing linux audio setup until I had to move to a newer kernel to get some hardware on a new motherboard to work. Now I can't seem to get decent performance and thought it might be helpful if folks could chime in with what versions, etc. they are using with decent success. In particular I'm having a very challenging time with Linux Sampler, which I had previously working very solidly but now regardless of numerous jack/ls version permutations segfaults when I create a jack driver in ls. Thanks! -Garett Kernel version? RT patch? Preemption mode? Audio hardware IRQ scheduling policy and priority? Alsa version if different from kernel? Jack version, scheduling policy and priority? Linux Sampler version (or cvs date), scheduling policy and priority?

16 years, 2 months

need some C++ help

by Dave Phillips

Greetings, I'm compiling a program called kodisein, an open-source VJ tool. I'm hitting the wall here: g++ -c -w -I /usr/include/stlport -I ../lib/handler -I ../lib/tools -I ../lib/types -I ../lib/values -I ../lib/widgets -I ../lib/windows -I ../src -I ../src/connectors -I ../src/handles -I ../src/objects -I ../src/modules -I ../src/modules/attribute -I ../src/modules/matrix -I ../src/modules/object -I ../src/modules/value -I /usr/include/SDL -I /usr/include/GL -o ../lib/handler/KEventHandler.o ../lib/handler/KEventHandler.cpp ../lib/handler/KKeyActionHandler.h:42: error: expected initializer before ‘<’ token ../lib/handler/KKeyActionHandler.h:51: error: ‘KeyActionHash’ does not name a type make: *** [../lib/handler/KEventHandler.o] Error 1 The file in question is short enough to include at the end of this message (line 42 is at the typedef). I have minimal skill debugging C++ and have no idea how to fix this problem. Any suggestions from the C++ masters here ? TIA, dp /* * KKeyActionHandler.h * kodisein */ #ifndef __KKeyActionHandler #define __KKeyActionHandler #include "KKeyHandler.h" #include "KConsole.h" #include <ext/hash_map> using namespace std; // -------------------------------------------------------------------------------------------------------- class KKeyAction : public KNotificationObject { protected: string key_name; public: KKeyAction ( const string & keyName ) : KNotificationObject () { key_name = keyName; } virtual ~KKeyAction () {} virtual const string & getKeyName () const { return key_name; } }; // -------------------------------------------------------------------------------------------------------- struct eqstr { bool operator()(const char* s1, const char* s2) const { return strcmp(s1, s2) == 0; } }; typedef hash_map <const char*, KKeyAction *, hash <const char*>, eqstr> KeyActionHash; // -------------------------------------------------------------------------------------------------------- class KKeyActionHandler : public KKeyHandler { INTROSPECTION protected: KeyActionHash key_handlers; string last_key; public: KKeyActionHandler () : KKeyHandler () {} virtual ~KKeyActionHandler (); KKeyAction * getActionForSequence ( const string &, bool = false ); bool addSequenceCallback ( const string, KObject *, KCallbackPtr ); bool setSequenceCallback ( const string, KObject *, KCallbackPtr ); void removeSequenceCallback ( const string, KObject *, KCallbackPtr ); bool isSaveSequenceCallback ( const string & ); bool handleKey ( const KKey & ); }; #endif

16 years, 2 months

Re: [LAD] [OT] CD-R masters, block error rate and dvd-r mystery...

by Joern Nettingsmeier

hi anthony! thanks for your reply. i'm cc:ing the list so that others can benefit from it as well... Anthony Kozar wrote: > Hi Joern, > > This is just a shot in the dark, but most audio CD tracks have a "lead-in" > time of 2 or more seconds. CD players will typically count down using > negative numbers for this time and the track is considered to begin after > the lead-in. Perhaps one of your drives (the DVD drive?) is reading the > lead-in as part of the track? > > (2 seconds x 44100 samples/sec. x 2 channels x 2 bytes/sample = 352,000 > bytes) i can rule this out, because although i used both a dvdr and cdr drive for burning, both cds were read back in using the cdr drive. any differences must have occured during burning. but since i used the same toc file and disk-at-once mode, it's unlikely that the lead-in got interpreted differently in both drives... but you are right, this being a live cd, i used pre-gaps and non-silent gaps extensively - i'll investigate some more along those lines. best, jörn -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 Kurt is up in Heaven now.

16 years, 2 months

Towards a truely realtime capable FOSS audio distribution | A guide to the Jack Source Code

by micu

Hello everybody, my name is micu and I study computer science at the Dresden University of Technology. During an internship at the operating systems chair of the university, I ported ALSA to the chairs operating system DROPS aka TUD:OS [1,2]. To let ALSA talk to the hardware and provide to it the usual linux kernel environment DDEKit / DDELinux [3] were used. As a kernel-userland interface I wrote a very small emulation layer, which makes it possible to link SALSA-lib [4] against the ALSA "kernel" part. So right now, we have a somewhat stable ALSA server running in userland on top of DROPS without changing ALSA or the SALSA-lib source code. I have been continuing this project within my diploma thesis. The remit of the thesis can be found here [5]. It is the goal of the thesis to take some steps towards a truly realtime capable (meaning with time constraints to be guaranteed) FOSS audio distribution. Here [6] you can see a raw version of my requirements definition. The architecture we are going to use is --- how could it be different :) --- Jack or Jackdmp (with a strong bias towards Jackdmp). To get the mess out of my head, I wrote a short guide [7] to the Jack source code. It is a pretty raw version and it isn't finished in any way yet; but I won't work on it any longer. Nevertheless, it might be helpful to other developers new to Jack. Therefore, if you will, you may get it under any license you wish (attribution of the author is appreciated :) to publish and improve it. Of course, the long term goal of the project won't be met to any extent during my thesis and I have no idea, if this project will be continued here at the university. Neither do I know, whether I will have time to work on it afterwards. To make a long story short: I would like to ask my first three questions.... so far :) 1.) Do you agree on having a truly real-time capable architecture in the FOSS audio world would be a really great thing --- and would you say, getting such a thing maybe could get a (major) goal of the pro audio FOSS community? 2.) Concerning our Jack vs. Jackdmp decision: http://jackaudio.org/ says, Jackdmp is going to be Jack 2.0. How likely and how soon do you think is this going to happen? 3.) I guess, there is a very minor bug in the lines 236, 237 of libjack/driver.c, svn revision 2734: The type castings should be switched. Thanks a lot in advance and please excuse my bad english :(. Regards, micu BTW: I love Jack and I love ardour --- and therefore I love you :). ========================================== [1]http://www.realtimelinuxfoundation.org/variants/variants.html#VARIANTS_DR… [2]http://www.osnews.com/story.php/15814/Introduction-to-TUD-OS/ [3]http://demo.tudos.org/dsweeper_tutorial.html [4]http://www.alsa-project.org/main/index.php/SALSA-Library [5]http://www1.inf.tu-dresden.de/~s3418892/task.txt [6]http://www1.inf.tu-dresden.de/~s3418892/Require.pdf [7]http://www1.inf.tu-dresden.de/~s3418892/AgttJSC.txt -- GnuPG: https://www1.inf.tu-dresden.de/~s3418892/micuintus.asc Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80

16 years, 2 months

Jump to page:

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