Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] Concerning libfst, vstserver, and dssi-vst

by Dave Phillips

Greetings: Users are constantly wrestling with issues surrounding the software mentioned in the subject line, and I would like to find out what directions are planned for those projects. Here's what I see now: 1. The vstserver project is functionally dead. It cannot work with newer versions of WINE, and it appears that Kjetil does not plan to keep it updated to accommodate the new versions. Alas, this also means that his nice vsti, ladspavst, and k_vst~ projects are also unusable. :( 2. The libfst project is essentially unmaintained. Again, WINE versions wreak havoc with users who want to keep both fst and WINE up-to-date. Paul and/or Torben: Is the libfst project going to see any more activity from your end, or should it be considered an open project and up for grabs ? 3. The dssi-vst bridge is still unknown to me because of issues with RH9, and I've not had time to test it on FC3. But is there any general feeling that dssi-vst is a better route to take, at least for the normal user ? Btw, I like the DSSI API, but it seems slow in catching on with developers. Is that perception correct ? Please understand that I'm in no way criticising the work done on these projects so far. In point of fact, I'm extremely happy they exist, but I'm also in considerable doubt whether they can continue to be useful without further maintenance. Users are writing to other users to figure out how to fix small problems (usually with libfst), but these repairs are not making their way back into the codebase, which seems rather non-optimal to me. I'm also aware that the greater problems exist because of WINE's inherent instability (WRT its development, not necessarily its usability) and that Linux audio developers can't be responsible for WINE fixes too. Perhaps more crosstalk between the WINE developers and the LAD folk (similar to the recent discussion re: the kernel list and LAD) would help smooth the way for a more consistent and more manageable VST/VSTi bridge for Linux ? So, any comments or useful suggestions ? Best, dp

20 years, 6 months

[linux-audio-dev] latencytest on 2.6 kernels?

by Paul Winkler

Hiya, Now that I've finallly gone to a 2.6 kernel (latest gentoo-sources, 2.6.11.something) I thought I'd fire up latencytest and see what it tells me. Unfortunately, latencytest0.42 still seems to be the latest and it no longer compiles. Anybody got a fix? pw@kermit latencytest0.42 $ make gcc -Wall -O2 -DUSE_PENTIUM_TIMER -c rtc_latencytest.c rtc_latencytest.c:24:41: macro "rdtsc" requires 2 arguments, but only 1 given rtc_latencytest.c:25: error: syntax error before '{' token rtc_latencytest.c: In function `main': rtc_latencytest.c:142: warning: passing arg 2 of `signal' from incompatible pointer type rtc_latencytest.c:143: warning: passing arg 2 of `signal' from incompatible pointer type rtc_latencytest.c:261:24: macro "rdtsc" requires 2 arguments, but only 1 given rtc_latencytest.c:261: error: `rdtsc' undeclared (first use in this function) rtc_latencytest.c:261: error: (Each undeclared identifier is reported only once rtc_latencytest.c:261: error: for each function it appears in.) rtc_latencytest.c:295:22: macro "rdtsc" requires 2 arguments, but only 1 given rtc_latencytest.c: In function `my_exithandler': rtc_latencytest.c:295: error: `rdtsc' undeclared (first use in this function) rtc_latencytest.c:365:19: macro "rdtsc" requires 2 arguments, but only 1 given rtc_latencytest.c: In function `calibrate_loop': rtc_latencytest.c:365: error: `rdtsc' undeclared (first use in this function) rtc_latencytest.c:367:19: macro "rdtsc" requires 2 arguments, but only 1 given rtc_latencytest.c:406:21: macro "rdtsc" requires 2 arguments, but only 1 given rtc_latencytest.c: In function `sigio_handler': rtc_latencytest.c:406: error: `rdtsc' undeclared (first use in this function) rtc_latencytest.c:408:21: macro "rdtsc" requires 2 arguments, but only 1 given make: *** [rtc_latencytest.o] Error 1 -- Paul Winkler http://www.slinkp.com

20 years, 6 months

[linux-audio-dev] jitter on USB audio

by Alfons Adriaensen

Hello, A question for the wizards of the USB audio drivers. At 48 kHz, USB delivers and consumes audio samples in chunks of 48 frames. When using ALSA's mmap inmterface, these will repackaged to the requested period size. So one would expect to see a jitter with a range of 1 ms in the wakeup times of a thread waiting on this interface. For example for p = 256 the real periods will be 6ms, 5ms, 5ms, 6ms, 5ms, 5ms, ... for an average period of 5.333 ms. In practice, when using snd-usb-audio, the jitter range is close to 4 ms. Why is this, and can something be done about it ? -- FA

20 years, 6 months

[linux-audio-dev] [admin] new policy and moderators needed

by Joern Nettingsmeier

hi everyone! after reading the thread "Other real-time options", it occurred to me that the strict members-only policy of this list has one huge drawback: it makes communicating with lkml and other communities almost impossible, since cross-posted threads will not make it to this list. i would like to change this. however, i'm very glad that the linux-audio lists are almost 100% spam-free, and i would hate to see that change. so here a proposal for a new policy: cross-posted messages from other mailing lists should be hand-approved in a timely fashion, and known individuals working in audio-related fields get added to the illustrious "auto-approve" list. unfortunately, my time is limited, so i would like to find five or so people who would be willing to step up as moderators. everybody raise your hands and say YEAH!. if you like this idea, we should then approach the key people on lkml (currently akpm, mingo and con) to always cross-post latency-related stuff to linux-audio-dev. this has two advantages: * the burden no longer rests with the few fearless individuals who keep preaching on lkml (kudos to paul, jack and lee ;) - everyone can chime in. * it will give the kernel preemption guys more testers and better feedback. please comment, jörn

20 years, 6 months

[linux-audio-dev] [ANN} Aeolus mailing lists and Wiki

by Fons Adriaensen

Hello all, Some time ago Joachim Schiele (well known from the MusE project) offered to host Aeolus on his website. As IMHO Aeolus is still far too experimental, volatile and immature to be turned into a shared development project, I declined that offer but instead asked Joachim if he would host a mailing list, something several users have asked for. I'm glad to annouce that as a result, there will be not one but even two lists, and a Wiki page as well. aeolus-user(a)muse-sequencer.org is the place for general discussions, announcements, help requests, bug reports, and everything that could be interesting from a user or musical perspective. aeolus-dev(a)muse-sequencer.org is for purely technical discussions, programming, debugging, talk about algorithms, and in general everything that requires some familiarity with the extremely cryptic and fully undocumented source code :-) I know some users have worked their way through this, since I've received valuable feedback, patches and bug fixes. Both lists are unmoderated, but you have to be a member in order to be able to post to them. To subsscribe, send an empty mail to either aeolus-user-subscribe(a)muse-sequencer.org or aeolus-dev-subscribe(a)muse-sequencer.org You will then receive a message requesting you to confirm the subscription, and the usual help information. The Wiki is at: http://www.muse-sequencer.org/wiki/index.php/Aeolus Many thanks to Joachim for providing these services !!! -- FA

20 years, 6 months

[linux-audio-dev] ANNOUNCE: BEAST/BSE v0.6.5

by Tim Janik

BEAST/BSE version 0.6.5 is available for download at: ftp://beast.gtk.org/pub/beast/v0.6/ or http://beast.gtk.org/beast-ftp/v0.6/ This is a development version of BEAST/BSE, the BEdevilled Audio SysTem and the Bedevilled Sound Engine. BEAST is a powerful music composition and modular synthesis application released as free software under the GNU GPL and GNU LGPL, that runs under unix. The project is hosted at: http://beast.gtk.org A mailing list is available at: http://mail.gnome.org/mailman/listinfo/beast/ GUI skins, example sounds and instrumets for BEAST/BSE as well as screenshots can be found at: http://beast.gtk.org/browse-bse-files.html http://beast.gtk.org/screenshots/index.html This development series of BEAST has a lot of the internals redone, many new GUI features and a sound generation back-end separated from all GUI activities. Outstanding new features include support for skins, many sample file formats, MIDI file import abilities, an improved piano roll widget, the track editor which allows for easy selection of synthesisers or samples as track sources, loop support in songs, mixer support, unlimited Undo/Redo capabilities and MIDI automation. Overview of Changes in BEAST/BSE 0.6.5: * New supported file formats: GUS Patches - Load patchfiles as ordinary samples [Stefan Westerfeld] BseWave - A new tool bsewavetool allows creation and compression of multi-sample files which can be loaded by beast. This tool is experimental and not currently being installed, ask questions or report problems with it on beast(a)gnome.org. * New Effects: Saturator - Saturate audio signals, implements various saturation types. * New scripts: Track Busses - Automatically create mixer busses for tracks * Fixed MIDI file import to create required mixer setup * Added playback position indicator to piano roll * Fixate zoom position while zooming piano roll * Fixed saving of BseMixer state to BSE files * Improved sample file caching algorith * Improved BSE file parsing robustness * AMD64 fixes [Stefan Westerfeld] * Lots of miscellaneous bug fixes * Updated British English translation [David Lodge] * Updated Canadian English translation [Adam Weinberger] * Updated Czech translation [Miloslav Trmac] * Updated Dutch translation [Tino Meinen] * Updated Spanish translation [Jorge Gonzalez] * Added Bulgarian translation [Iassen Pramatarov] * Added Kinyarwanda translation [Steve Murphy] --- ciaoTJ

20 years, 6 months

[linux-audio-dev] [ANN] Digital Room Correction 2.5.0

by Denis Sbragion

Hello, DRC 2.5.1 is out and is available at: http://freshmeat.net/projects/drc/ Changes: A new ringing truncation stage has been added to remove excessive ringing caused sometimes by the pre-echo truncation procedure. The sliding lowpass prefiltering procedure has been rewritten to make it a bit more accurate and to make the code more readable. The postfiltering stage has been split to provide a separate stage for microphone compensation. The documentation has been vastly improved, switching to LaTeX for document generation and formatting. Many other minor bugs have been fixed. Best of listening, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it

20 years, 6 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 19, Issue 26

by Michael Ost

On Tue, 2005-04-12 at 09:02, linux-audio-dev-request(a)music.columbia.edu > I really would like to see a coherent approach defined and organized > to study and maintain VST/VSTi compatibility under Linux. Matters to be > considered include : > Keeping current with WINE development (ongoing). We at muse research have some direct experience in this area. Our VST support library is closed, but we do use and contribute to Wine. We find and fix VST related Wine bugs all the time. We are using wine-20040914 but will probably be moving to wine-20050310. Later versions do make a difference in how well plugins are supported. Support and compatibility is OK especially for the smaller, freebie plugins. For the big ones (like Native) compatibility is more problematic. We will be helping with this effort by finding and fixing Wine bugs, and significant differences between Wine and Windows. Some are fixable with Wine and some will require developer cooperation. As an example, sfz (a Soundfont player) makes an Invalidate() call during the (supposedly) realtime process() call. In Windows that's cheap, in Wine it's not. The sfz folks weren't willing to change their plugin. But the folks at BFD (Fxpansion) were. A Receptor and Wine friendly version is forthcoming. > Trying to resolve licensing issues with Steinberg (if they're > willing to alter their licensing, perhaps they just need some more > prodding?). This is a dead end. You can argue it all you want. They have no business interest in changing the terms of VST. It isn't going to happen. It's even difficult to get some of the key, larger plugin vendors to do anything for Linux but we are chipping away at it. - mo =================================== Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com

20 years, 6 months

Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst

by Kjetil Svalastog Matheussen

Paul Davis: >>One thing that distinguishes dssi-vst from vstserver and jack-fst is >>that it manages threading in the Windows parts of the code using the >>Windows threads API rather than pthreads, which means it ought not to >>be sensitive to threading-related changes in Wine. Of course, that's >>only theory. > >the way wine now handles threading makes this point mostly moot. wine >completely overrides the pthread "vfunc" table for any NPTL system and >even (i think) newer linuxthreads ones. you may think your app calls >pthread code, but if its linked using winemaker, its not (at least, >not directly) :) and of course, the new version of fst will require >winemaker compilation as well. Yes, in theory, there should be no difference. But try to compile a shared library that links to libwine and use pthread functions, without linking with libpthread. This worked with wine 9.12.2003, but not anylonger. I had to use some crazy hacks on wine to make vstserver compile for about a year ago or something. And later it got worse (unable to compile). The way wine/winemaker constantly changes is so tiresome that I just don't want to touch it anymore. (Perhaps thing have got better now, though.) --

20 years, 6 months

[linux-audio-dev] LAC2005: Don't forget to floss^H^H^H^H^Hregister!

by Frank Neumann

Hi all, the 3rd International Linux Audio Conference(*) or "LAC2005" for short is nearing (21-24 April), and if you have not registered for it yet, now would be a good time to do so. It's free, we are not selling your email addresses (honestly!), and it gives you a real bonus: After a short negotiation with ZKM, we agreed that registered participants have free admission to the ZKM Media Museum and the currently running exhibition "Making Things Public". The Media Museum is quite interesting, especially since you can see a real computer monster in live and stunning action there: Recently, they have acquired a fully working Zuse Z22 from a local college. This lady is really worth being seen. Well, I digress. We hope to see many of you next week at the ZKM in Karlsruhe! The LAC2005 Organization Team: Götz Dipper (ZKM) Frank Neumann (*) http://lac.zkm.de

20 years, 6 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