On Monday 01 December 2003 20.48, Paul Davis wrote:
> i'd appreciate test reports ASAP, so that out trusty release
> technician (the very wonderful taybin rutkin) can get a new release
> out in the near future.
>
alsa_driver.c
driver->period_usecs =
(jack_time_t) floor ((((float) driver->frames_per_cycle) /
driver->frame_rate) * 1000000.0f);
jackd/engine.c
poll_timeout = (engine->control->real_time == 0 ?
engine->client_timeout_msecs :
engine->driver->period_usecs/1000);
- - -
if (poll (pfd, 1, poll_timeout) < 0) {
Isn't this dangerous?
* What happens if period_usecs < 1000?
Well poll_timeout gets 0 since period_usecs is an uint64_t
A poll with time out of zero will return immediately.
OK?
/RogerL
--
Roger Larsson
Skellefteå
Sweden
I am contemplating buying a laptop of some sort, to develop on.
I was wondering how many of you are using an x86 laptop and how
many are using a ppc laptop :)
It looks to me as if Apples laptops are rock solid and don't suffer
from buggy ACPI to start with. Or is this extra quality just a myth ?
I know some applications are not ported yet to ppc and suffer from
x86-isms, but that should be fixable I guess :)
anyway, thanks for your input,
v
Greetings,
Last week Jack O'Quin and I finished off the first version of a handy
addition to the JAMin gui. It is a gtk2 menu for connecting JACK i/o
ports. Similar to what we have seen in audio programs on other platforms.
You can find it in the cvs now.
It is called
io-menu.c io-menu.h
There are instructions for how to integrate it at the top of the .c
file. I already added it to jackEQ and it was a painless process.
We have tried to make it as self contained as possible to make it easy
for gtk2 developers to use. It should also be a handy reference for
developers using other gui toolkits.
Rgds.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
Apparently upon the beginning of the barrage, the donkey broke
discipline and panicked, toppling the cart. At that point, the rockets
disconnected from the timer, leaving them strewn around the street.
Tethered to the now toppled cart, the donkey was unable to escape before
the arrival of U.S. troops.
United Press International
Rockets on donkeys hit major Baghdad sites
By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM
On Friday 28 November 2003 17:27, Paul Davis wrote:
> >as paul says, opt/ is a fine solution for this, as everything just
> > symlinks, but it's sad that it never took off.
>
> i don't think its a fine solution. i never saw anything useful about
> /opt at all. it just created a *third* possible install location.
Oh, my apologies for misreading.
I think the only sane thing about it is that
-lets you keep track of what's in your system and where did it came from
without an extra database of the package management system
-lets you easily install/switch between software versions
Juan Linietsky
(btw my apologies also for sending the message direct, this new kmail is quite
confusing)
Well, I really wondered after that thread on speech synthesis
on how something done with festival would actually sound mixed up.
I this experiment in nearly half an hour, so dont think it's
something hard. I just wrote the voices in that xml-like syntax
festival uses for singing songs. Then I wrote a very
basic arrangement in cheesetracker, plus added
some effects and a bit of compressor to the voice.
The result is actually better than what I was expecting,
though it's hard to keep festival in tempo.
Here's the little thing I did:
http://reduz.com.ar/songs/evilrobot.ogg
Have fun!
Juan Linietsky
The Rosegarden team are pleased to announce the release of
Rosegarden-4 0.9.5, an audio and MIDI sequencer and score editor
for Linux. To download the source package, go to the homepage at
http://www.all-day-breakfast.com/rosegarden/
This release contains a host of new features and improvements
over the previous release, and is nearly feature complete for 1.0.
Features include:
o Score, piano-roll, event list and track overview editors
o MIDI and audio playback and recording using JACK
o Audio plugin support using LADSPA
o Score interpretation of performance MIDI data
o MIDI file I/O, Csound and Lilypond export
o Shareable device (.rgd) files to ease MIDI portability
o Translations into Russian, Spanish, German, French and Welsh
New features since 0.9.1 include:
o Better sequencer comms layer for much more robust MIDI sequencing
o Control rulers for editing velocity and control events
o Controller management for MIDI devices
o Event list editor with some actual editing capabilities
o Event filter on current selection
o Classification of audio plugins using liblrdf
o Percussion and variations support in bank management
o Import Studio from File
o Markers
o File merging for all file types
o Notation rendering using real scalable fonts (one supplied)
o Multi-page notation rendering with panner
o Much better score printing
o Print Preview
o Segment colouring
o Configurable metronome
o Better Lilypond export
o MusicXML export that works, though it's still pretty basic
o Can now drag notes around in notation view
o Several new .rgd device files
o Better handling of MIDI devices that come and go
o Much improved audio scheduling infrastructure
o Ability to drag-and-drop audio files onto segment canvas
o Many optimisations throughout
Chris
Roger Larsson:
> > > > So how is the low-latency situation for 2.6? I did install 2.6 on
> > > > my private machine, but was not able to get better performance
> > > > than 2.4 with ll+pre (kicked out of jack-graph pretty soon with 128
> > > > frames period). Is there a trick to get better lowlatency performance
> > > > with 2.6 I don't know about?
> > >
> > > Did you compile with CONFIG_PREEMPT enabled?
> >
> > Yes. :)
>
> echo 1 > /proc/sys/kernel/lowlatency ?
> If you have enabled "Control low latency with sysctl"
>
I didnt know there were an option for lowlatency for 2.6?
However, I do remember there were no /proc/sys/kernel/lowlatency
file. Have to check when I get home.
> It might be possible that something like lock break is needed...
>
> Lots of good stuff is available at:
> http://www.tech9.net/rml/linux/
> But most are for 2.4 or early 2.5 kernels
>
I couldn't find a lock-break patch for 2.6 there, and the other
one that might might have helped, the Scheduler Hints patch, was
not very updated. But I think I remember reading about setting
various kinds of scheduler-behaviour by using a kernel option?
Could that make the situation better?
This is a bit irritating, because in 2.4.23-pre8+ll+pre I can
run with a frame size of 32 in jack and run ardour for a very
long time without being kicked, and have very few xruns.
With 2.6.0-pre4 I cant even run with 128 for more than a minute or so,
and I get lots of xruns before that.
My machine is nforce2, xp2800, using the built in soundcard,
built-in gfx card, ps2 mouse+keyb., and no pci or agp slots used.
--
By request of some of the people here, I am posting a complete
song that you can open and check, as well as the lyric files (xml),
and the notes on the problems i found when creating the sounds
with festival. The song was composed in one hour and you can see
how the audio chunks were mixed, as well of which ladspa effects
were applied to 'produce' it.
http://reduz.com.ar/festisong
The song (.ct file) can be opened with the (unreleased yet) version of
cheesetracker, as it uses the new equalizer filters and all that.
http://reduz.dyndns.org/cheesetracker-0.9.5.tar.gz
Cheers! Lets hope we get more festivalized songs soon :)
Maybe Paul Davis will consider integrating festival to ardour hehe...
Juan Linietsky
I'm potentially in the market for a new box before end of year. Has anyone
found anything to show whether Athlon64 (or the high-end FX line) are worth
it for audio? Assume some legacy audio code under legacy OS :-/
Tim
Benno Sennoner and I were discussing today on IRC about
the usual fixed point vs floating point (regarding to some resampling code)
We developed some tests and ran them on a variety of computers.
It would be interesting if ladders here could run them on different computers
(and specially non x86, like amd64. or the Gx processors) so we can
see what performance can we expect on each , and how things
seem to be shaping for the future. It will also be a key factor
on how our projects will develop in the future.
The code is available at:
http://reduz.dyndns.org/resamp_fixp.c // fixed point version
http://reduz.dyndns.org/resamp_float.c // floating point version, portable
http://reduz.dyndns.org/resamp_float_fistl.c // X86 VERSION ONLY!! Uses fistl
instruction
The results dont mean just int vs float performance. They
also test for float->int conversion, which is common
in most algorithms that work with buffers. It is a linearly
interpolated resampling with volume control.
please use GCC options -
-O3 -ffast-math -march=<yourcpu> so it's a fair comparison
results from other compilers is also appreciated!
Here's some results for reference
****************************************************************
vendor_id : AuthenticAMD
model name : AMD-K6(tm) 3D processor
cpu MHz : 412.508
cache size : 64 KB
flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips : 822.47
resamp_fixp - 0m8.460s
resamp_float_fistl - 0m27.390s
****************************************************************
vendor_id : AuthenticAMD
model name : AMD Duron(tm) Processor
cpu MHz : 951.701
cache size : 64 KB
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1900.54
resamp_float - 0m11.180s
resamp_float_fistl - 0m5.810s
resamp_fixp_optimized - 0m2.790s
************************************************
Benno gave me some results:
Intel p4 1800 celeron
resamp_float_fistl - 4.00user
resamp_fixp - 4.51user
(float faster?)
--------------------------------
VIA nehemiah 1GHz
resamp_float_fistl - 0m21.079s
resamp_fixp - 0m7.129s
*************************
Some results on SPARC:
2x 125MHz HyperSPARC
resamp_fixp - user 2m59.010s
resamp_float - user 0m44.290s
(float faster! :)
****************************
Intel 2.4 GHZ P4:
resamp_float - 0m3.440s
resamp_float_fistl - 0m2.960s
resamp_fixp - 0m1.450s
************************
1.25GHz G4 (laptop)
resamp_float - 0m11.170s
resamp_fixp - 0m2.130s
-----------------------------------
Conclusions SO FAR.
My own conclusions about the subject is that the float -> int conversion is
STILL the biggest bottleneck on most common architectures. And until this is
sorted out, fixed point is still the best solution for some specific cases,
and I dont see any problem mixing it with floating point code. If you look
at that algorithm closely in the source, you could replace "counter/
increment"
for purely fixed point values, and do the rest (managing the samples) in
float. This will undoubly speed it up..
Cheers!
Juan Linietsky