hello list,
(sorry for cross-postings)
juan pampin has just announced the new "official" release of ATS.
ATS is a spectral modeling system based on a sinusoidal plus critical-band
noise decomposition. Psychoacoustic processing informs the system's
sinusoidal tracking and noise modeling algorithms.
Originally implemented in LISP using the CLM sound synthesis and processing
language, ATS has been ported to C in the form of a spectral modeling
library. This library, called ATSA, implements the ATS system API which has
served as foundation for the development of the ATSH graphic user interface.
ATS interfaces for Csound and PD have also been developed.
ATS software is distributed in open-source format.
there's a new web site with complete information at:
http://www.dxarts.washington.edu/ats/
including a paper with a detailed description:
http://www.dxarts.washington.edu/ats/ATS_theory.pdf
there's also a link to the sourceforge repository, where you can download
the packages:
http://sourceforge.net/projects/atsa
--
On Tue, 1 Jun 2004 01:25 , Malcolm Baldridge <linux-audio(a)paypc.com> sent:
>
>> I had these problems as well. There's a long thread a few months back
>> where it was confirmed that I tried *everything*. Eventually I gave up
>> and bought an IDE drive. Hey presto, problems gone. Now the only xruns
>> happen when there's scsi disk activity, according to vmstat.
>
>This is craziness, and turns things completely on their head. IDE, even
>with bus mastering, requires more I/O and IRQ turnarounds to complete a
>given transaction to a drive.
>
>I've heard of PCI bus greedy graphics cards (in the pre-AGP era), but
>bus-greedy SCSI controllers take the cake.
>
No, it's not craziness. You need to read this:
http://www.staudio.de/kb/english/conflicts/index.html#2940
and this:
http://www.prorec.com/prorec/articles.nsf/articles/1A37C1C69674D6D786256950…
You might be surprised.
Jan
Hi all,
Simple question - Is there a little tool for capturing an incoming midi stream
in realtime and saving it to disk as a midi file?
Or is the best way to do this recording into rosegarden or muse?
cheers,
dave
So, based on Fernando's and Malcolm's advice, I decided to quit fussing with the 2.6 kernels and stick with the 2.4.23 that I have working to do some recording last night. The band came over - we were set and ready to go. I hit 'record' to get an idea of the drum mix (we're submixing to stereo) - 3 seconds in, Ardour stops with an 80ms xrun! Arrgh! I sweated through the rest of the evening, fearing another occurence at 3:30 into a 4:00 song. Fortunately, everything went ok.
I guess I'm back to trying to figure out what's causing these long xruns, now under the 2.4.23 kernel.
Do most people shut off non-essential daemons during recording sessions, or do any other tricks? This is kinda frustrating, as the CPU load seems rather low (< 15% when the xrun happened). I guess I'll test out reiserfs and even ext2 to see if the filesystem is the culprit.
Thanks for reading the ramble,
Joel
> > I guess my main motivation for trying out the 2.6 kernel is laziness.
> > Just build the kernel and get the performance and ALSA without patches
> > or compiling extra stuff. At least, that was _supposed_ to be the way
> > it worked! I'll keep trying the new kernels, but keep the old faithful
> > 2.4 kernel around for recording.
> >
> > I'm _still_ curious about what causes the long xruns, though.
>
> New versions of alsa can be compiled with the "--debug=full" option (I
> don't think the current code in the kernel has that). That will enable
> you to tweak a proc variable to dump the kernel stack on each xrun, it
> is something like /proc/asound/card0/pcm0p/xrun_debug (for playback,
> same for recording in pcm0c). "echo "2">/proc/.../xrun_debug" will turn
> reporting on. You will get the stack traces in /var/log/messages.
>
> Not that you will immediately know exactly what has to be done to get it
> fixed, of course :-)
>
> IMHO stick with 2.4.x, in my tests 2.6.x is not even close to being
> ready for pro audio work. It will get better but it will take some time.
>
> -- Fernando
>
>
Hi all,
I was just wandering around some of my old bookmarks and noticed the the
OpenJay website has been defaced, probably through an old PHPNuke
security hole.
http://www.openjay.org/
I can't find an email address to notify on the page anymore, so I'm
posting here so that someone might fix/take down the server ..
Thanks,
Steve
I'm running a 2.6 kernel with the realtime module added. I'm able to get
jack running with realtime capabilites using
jackstart -r -d alsa
from the command line. But if I run qjackctl, jack starts up, and I get
"Could not connect to JACK sever as client." error.
Alsaplayer seems to be ok, but ardour is a no go.....
I've tried mobprobing as any=1 and with the gid option too.
Any ideas.....
Greg
Joel,
About the only thing I can think of to try (other than an IDE drive) is to
adjust the latencies of the SCSI controller and the sound card. Use setpci. I
think I've got an example on my web site and, IIRC, a link to an article on
setting latency.
Jan
On Mon, 31 May 2004 23:00 , Joel White <cv223(a)comcast.net> sent:
>Aha, a thread convergence!
>
>I started the "Ardour..." thread lamenting long xruns under the 2.6
>kernels. Based on recommendations on the list, I went back to a 2.4
>kernel, still having the occasional long xrun. In the "XRuns..."
>thread, the following from a post by Jan Depner caught my eye:
>
>"What kind of disk drives? Adaptec SCSI controllers can give you
>problems with xruns."
>
>Uh-oh. I'm using an Adaptec controller on my main board (a 7890). With
>a little digging, I came up with the following from the ST Audio website
>(http://www.staudio.de/kb/english/conflicts/):
>
>"The famous Adaptec 2940 SCSI controller series is causing performance
>problems when installed in the same system as our DSP24 series and when
>the audiodata is stored on a SCSI-HDD connected to the controller. To
>get good results in benchmark tests, the Adaptec controller keeps steady
>access to the PCI bus. The result is a reduction of data transfer of
>other PCI cards like the DSP24 hardware. This means that the ASIO/MME
>buffer size (which is the latency) needs to be set to a relative high
>value to avoid stuttered audio playback and drop-outs during recording.
>The performance problems can be reduced if both the DSP24 and the
>Adaptec controller both have a unique and unshared IRQ. Still the
>performance will not be as good compared to the regular onboard
>IDE-controller of a modern mainboard. This means that the best solution
>is to use a IDE-HDD to save the audiodata from within your recording
>software. The simple presence of the controller (that is used while the
>audiodata is stored on a IDE-HDD) is no problem."
>
>Uh-oh again. The 7890 is the on-board version of the 2940. I thought I
>had the xruns pretty much under control with the 2.4 kernel, then I
>picked up a M-Audio Delta 1010LT (I was jonesing for the 8 channels of
>input!). Ugh. I can't record more than a few seconds of 8 channel
>input before a 100msec+ xruns brings everything to a halt. Even
>recording 2 channels won't make it through a 4:00 min song.
>
>So, am I completely hosed with my Adaptec SCSI drive setup? Anybody
>have any insight into these Adaptec controllers? I've fussed with the
>setpci latency_timer settings (from Jan Depner's "Installing and
>configuring ALSA, JACK, & Ardour..." web site), but still see long
>xruns. Trying an IDE drive is not that simple, as I don't have any
>drive slots left in the box (I've got 4 SCSI drives setup as a RAID).
>So, I'd like to exhaust all possibilities before trying new drive
>configurations.
>
>Any thoughts/ideas/suggestions would be _greatly_ appreciated!
>
>Thanks,
>
>Joel
>
>
>