Linux-audio-dev April 2005

linux-audio-dev@lists.linuxaudio.org

107 participants
90 discussions

Start a nNew thread

[linux-audio-dev] more on live cds

by Iain Duncan

I should have mentioned that I'm certainly interested in any other non-agnula live cd solutions as well. Thanks Iain

19 years, 5 months

[linux-audio-dev] customizing agnula live cd?

by Iain Duncan

Hi, wondering if this might tickle anyone's fancy on the agnula team. The agnula live cd is a great idea. I would love to be able to customize that however, to add my own apps, and of course data files. I play live shows using csound5, but would like to add jack, jammin, ladspa plugins etc, and some of my custom apps. So obviously I need to be able to add all those, and all the orc and sco files and any samples. Is there or could there be a relatively straight forward way of customizing the agnula live cd, perhaps a script or app that allowed one to make a custom version on a small partition and then burn it or something. I figure that would be fantastic for shows in case of hardware failure, disk failure, or even stolen machine as one could essentially do your show off someone else's pc if need be. It would be really sweet if you could count on it recoginizing and being happy with all major sound and midi cards, etc. Any thoughts, pointers, etc? Thanks Iain

19 years, 5 months

[linux-audio-dev] Denemo 0.7.3beta2

by Aaron

Hi all, For all music notators out there, there is a new release of denemo (denemo.sourceforge.net). It has lots of improvements including the graphical interface and added functions. So if you are a denemo user now is a good time to get the latest and greatest. I am using the cvs which has already a bunch of bug fixes since the release, but either way it is quite an improvement from the previous release, with 50 undo's! Best wishes Aaron

19 years, 5 months

[linux-audio-dev] spectral peaks curve

by Andrew Gaydenko

Hi! Is there some tool to accomplish such task: take some sound (wav) file and plot (or give some kind of table) peak spectrum values along all the file in given frequency range? Andrew

19 years, 5 months

[linux-audio-dev] LCA2005

by Dave Robillard

Hi all, Anyone going to LCA2005? (note that's LCA in Australia, not LAC in Germany!) I'd like to see if I can find a keyboard controller and/or guitar for my presentation (not to mention the jam session afterwards). I'm flying in from Melbourne and can't bring any of that stuff. Keys in particular would be /really/ nice to have, if there's any Canberra folks around. .. thought I'd ask. :) Regardless, drop your name in this thread anyway - it'd be nice to have something of a roll call Cheers, -DR-

19 years, 5 months

[linux-audio-dev] LAC2005: getting there from belgium

by Pieter Palmers

Hi all, I'm looking for a ride to LAC2005 (and back) from Belgium (Leuven). Can someone here help me out? Thanks, Pieter Palmers

19 years, 5 months

[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

19 years, 5 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

19 years, 5 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

19 years, 5 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

19 years, 5 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 April 2005