Greetings,
I was curious what compiler versions people have had the best luck with.
I am currently using: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
I am considering upgrading via RPM to what appears to be 3.2
(gcc-3.2-7.i386.rpm). Good idea? Bad Idea?
Thanks!
Levi
Hi all,
Another day.. another release :)
* fixed plugin stuff to work with 2.9x C++ symbols
* fixed fltk compile
* added an alsa-patch-bay.desktop
* fixed fltk segfault
http://pkl.net/~node/alsa-patch-bay.html
Bob
Hi all,
It appears as though LADSPA at the moment lacks a means to provide
names for control values (this topic has probably crossed the list
before so I'll try to keep it short).
The common solution for this problem (e.g. as used in Steve Harris'
plugin collection) is to use an integer control port to encode for the
different options that the port can have, then add some text to the
PortName to describe those options (e.g. "1=sin, 2=saw, ...").
This has a few drawbacks though. First, it doesn't really solve the
original problem; the user is still inputting ordered numeric values,
even though the relationship that is being modeled can be totally
arbitrary. Second, it makes for very long PortNames, which causes
layout troubles.
Therefore (if such a thing does not already exist) I propose to extend
the LADSPA specification with a convention: if a PortName matches the
following regular expression: .+ \((\d+=.+,)*(\d+=.+)+\) (in words:
any sequence of characters following by a '(', followed by one or more
comma-separated 'value'='name' pairs, followed by a ')'), then the
host may assume that the given values map onto the given names and
display them as such. In addition, the host may suppress displaying
the '(...)' part of the PortName.
This proposal follows current best practices, requires no
modifications to the LADSPA protocol or data structures, is easy to
implement, and highly unlikely to adversely affect any existing
plugins/hosts.
Any comments?
Pascal.
--
The GNOME U sound editor:
http://awacs.dhs.org/software/gnusound
[sorry for the wide distribution]
Is anyone out there trying out this combination?:
kernel 2.4.20-rc1
capabilities patch
low latency patch
preemptible kernel patch
almost current alsa cvs [20021028.170432 usa pacific time]
If I start jackd and then use the freqtweak jack client I get a completely
dead machine in a very short time (from a few seconds to 10 or 20
seconds).
Same alsa driver, but running on 2.4.19 (up to 20-pre4) seems to be fine
and I can play around with freqtweak for as long as I want :-)
No clues are left behind... something in the kernel is deadlocking, I
guess. I tried removing first the preemptible kernel patch with the same
result. Just a moment ago I tried again after removing the low latency
patch and I still get the same result... that pretty much leaves alsa and
the kernel. Got the same result on a laptop intel810 and an ice1712 card.
Interestingly enough just the jack server running is not enough to kill
the machine. Adding a jack client (just tried alsaplayer, same problem as
freqtweak) kills the machine really fast.
Maybe there is a problem with the scheduler when there are several
SCHED_FIFO tasks competing for the processor?
-- Fernando
Hi,
I am building a sound editor and need an API for playing 'wav'
file samples. I tried the SOX API but the quality is very bad. Is there
some other API, I can try. Kindly advice.
> >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
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 ---
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 ---
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.
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