> On Sunday 18 April 2004 13:44, Tim Blechmann wrote:
> > out, the windows hdsp driver sets the latency timer of
> > the cardbus bridge and (i am repeating what i wrote before) thomas added
> > this to the linux driver as well ... which didn't work for no kernel i
>
> no. there was a change setting the lateny timer to 255, but only for the
> HDSP, not for the bridge. that's why i ask.
>
I see. Not sure about that. What I do know, however, is that the hexdump I
was looking into was the cardbus registers, *not* the hdsp ones (see below).
> > used on my machine (nearly every kernel between 2.4.22 and 2.6.5 both
> > vanilla and ck/gentoo)
> > there is a latency problem, but it's NOT related to the settings of the
> > latency registers of the hdsp or the cardbus bridge...
> >
> > > ico, i'm know it works for you with 0x04 at 0xc9, but please try
> > > anyway.
> > as i pointed out earlier, i've got the same behaviour on my machine with
> > the same register settings on windows (works fine) and on linux (doesn't
> > work).
> > what we should do is figuring out, what this specific register on ico's
> > machine is actually doing...
>
> could you actually show us the hexdump of the config space?
>
This is all I have currently. Will generate more as soon as I can (please
let me know which particular device you are looking for).
http://meowing.ccm.uc.edu/~ico/eMachines/
(jpegs are verbosely titled)
Ico
1. A short summary of changes
Minor bugs in JACK support have been fixed. Now Ecamegapedal
makes sure it won't launch the JACK daemon by accident
when probing for available devices on startup. The manual
pages have been updated with some new sections.
---
2. What is Ecamegapedal?
Ecamegapedal is a real-time effect processor software with
a graphical user interface for controlling the effect
parameters. It is meant to be used as a virtual guitar-fx
or studio effect box. In addition to real-time operation,
Ecamegapedal also supports reading from and writing to audio
files. All audio object and effect plugin types provided by the
Ecasound libraries are supported. This includes ALSA, JACK,
OSS, aRts, over 20 file formats, over 30 effect types, LADSPA
plugins and multi-operator effect presets. Ecamegapedal's
implementation is based on Ecasound and Qt libraries.
Ecamegapedal is licensed under the GPL.
---
3. Contributors
Patches
Kai Vehmanen (various)
---
4. Links and files
http://www.eca.cx/ecamegapedalhttp://ecasound.seul.org/download/ecamegapedal-0.4.4.tar.gz
---
http://www.eca.cx
Audio software for Linux!
Q 5.3 has been released, along with Q-Midi 1.14. (Mostly bugfixes this
time.)
Q is an equational programming language based on term rewriting. Q-Midi
is an add-on module for the Q language which provides an interface to
MidiShare, Grame's cross-platform MIDI library. If you want to try out
programming computer music applications in a high-level functional
programming language, then these might be for you. You can find more
information about Q and Q-Midi at http://q-lang.sourceforge.net/.
Also available now in CVS is a first snapshot of the upcoming Q-Synth
package which provides interfaces to OSC and SuperCollider3. See
http://sourceforge.net/cvs/?group_id=96881 for checkout instructions
(the CVS module name is q-synth), and for a link which allows you to
browse the CVS repository.
Enjoy!
Albert Graef
--
Dr. Albert Gr"af
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
On Apr 14, 2004, Anders Torger wrote:
> Thus, I think it is necessary to implement something operating on the
> ethernet level to get best performance in terms of throughput and
> latency.
>
> /Anders Torger
If what you mean by "operating at the ethernet level" means
"no Cobra-like hardware to help, but putting data directly
into Etherframes w/o IP/RTP headers", then its unclear to me that
working at the RTP/IP level is going to hurt you much. The
simplest implementation would have RTP/IP header overhead,
but there are nice header compression schemes that get rid of it:
http://www.ietf.org/rfc/rfc2508.txt
and its improved versions. By using RTP, you get a lot of
protocol design you might otherwise need to do,
within RTP (like RTP MIDI) and surrounding it
(session management, etc).
One big thing you need to worry about are clocks -- unlike
a protocol like AES/EBU or SPIDF, packet-based media is
not sending an implicit clock along with the data. So, the
nominal "sender sampling rate" can't be precisely linked to
the nominal "receiver sampling rate" in a simple way. The
consequence is either too much data piles up at the receiver,
or not enough. One solution to this problem is to continuously
running a sample-rate converter at the receiver in software,
to keep the two sampling rates locked. See:
http://www1.ietf.org/mail-archive/working-groups/avt/current/
msg00569.html
and use the "Thead Next" to cycle through the discussion, it
goes on a ways and lots of interesting folks drop in with info.
A separate issue for your "many streams" case is synchronizing
the streams to each other, in the case where not all share the
same nominal clock. RTP has tools for this, based on
associating NTP timestamps from a common clock to each
independent stream, that get used for audio/video lipsync,
and can be repurposed here as well.
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
Greetings:
Some URL errors fixed, Speech section completely updated (thanks to
Antti Kaihola), LilyPond entry massively rewritten, and a few more apps
in the New Additions...
http://www.linuxsound.at (Europe)
http://linuxsound.jp (Japan)
http://linux-sound.org (US)
Best,
dp
martijn:
> the last? are you not gonna announce it any more, gonna change the name, or
No, please don't change the name! Its a refreshingly
amusing to read about a serious sound tool with such a
totally unserious name. I like it. :)
--
Hello Everyone!
Announcing for the last time this year the new release of Wav Composer Not
Toilet. Wcnt is of course, the not-real-time modular synth, sequencer,
sampler, wav file generator. Get it from wcnt.sourceforge.net.
This release is wcnt-1.1z (read wcnt-1.1260) and here are the new features
and changes:
~~~~~~~~~~~~~~~
BIG CHANGES:
~~~~~~~~~~~~~~~
*** Updated website to be more helpful + online example.
*** Sets of data which are not module parameters or module inputs (shape of
an adsr, notes in a riff, riffs in a sequencer, etc) have now been
generalised into a base class. Specialised data reading routines have been
replaced, which make it easier to program new data sets. This also means
that data definitions are now more tappy tappy on your keyboard, my
justification for this extra user effort is readability.
*** Riffs inserted into sequencer can be transposed at point of insertion,
and the note lengths can be modified.
~~~~~~~~~~~~~~~
COMMAND LINE:
~~~~~~~~~~~~~~~
*** Now has short options too.
*** two conversion options to convert a note name to a frequency, and a
frequency to degrees per sample and samples per cycle.
~~~~~~~~~~~~~~~
NEW MODULES:
~~~~~~~~~~~~~~~
*** dynamic
Maps amplitudes of input signal to a set of output amplitudes/ratios. Of
course it has two sets of which the output can be modulated between.
*** spreader
Spreads the output of a number of wcnt_signal modules along an imaginary
line and outputs that which the modulation input lands upon.
*** note_tran
Translates notes into values. The note range used depends on being
triggered by a note_on, or note_slide. Four output triggers so you can tell
if the note was in one of the two note ranges or not. (see online example:
wcnt.sourceforge.net/drumex01.wc )
~~~~~~~~~~~~~~~
MINOR CHANGES:
~~~~~~~~~~~~~~~
*** adsr got a couple new params regarding shape modulation
*** logic trigger's xor mode definately works now (dunno if it did before)
*** trigger now behaves in a note_on/note_off type operation gleaned from
the input signal.
*** wcnt_signal has a level param
That's All Folks, same time next year, see ya! see ya! see ya. see ya,
see ya see yaseeyacyacyacycaaa...
James.
~(sirromseventyfive)~
_________________________________________________________________
Use MSN Messenger to send music and pics to your friends
http://www.msn.co.uk/messenger
http://www.notam02.no/arkiv/src/radium-0.63.tar.bz2http://www.notam02.no/radium/
(Note, the CVS is very outdated)
Radium V0.63 Alpha Linux Port
Released 15.4.2004
HOW TO MAKE IT RUN WITHOUT READING THE REST OF THE README FILE
make
./start.sh
INTRODUCTION
This is the second public, and the first official, release of
the linux port of the music editor Radium. The Amiga version
has been stable since January 2002.
Radium is a new type of graphical (currently only) notebased
music editor.
For more info about the program, check out the online manual placed
at http://www.notam02.no/radium/ somewhere.
COMPILE
The following packages are currently used to build and run Radium:
*libgc - http://www.hpl.hp.com/personal/Hans_Boehm/gc/
*Python - www.python.org (at least V2.0 and tkinter)
*Python development package
*pyqt - http://www.gnu.org/directory/devel/specific/PyQT.html
*pygtk - http://www.daa.com.au/~james/software/pygtk/ (pygtk1, use pygtk-0.6.11)
*xterm - Yupp.
Most of these things are allready included in the radium/ directory (mainly because
of compatibility problems between various versions of gtk, pygtk and
libglade), so you only need to get hold of "pyqt".
"pyqt" is available as package for most linux distributions.
CURRENT STATE
The biggest problem is that saving does not work. Loading does though.
Other things that needs to be fixed is that the playing behaves
strange when reaching the end of the blocks, and that the alsa-seq code
needs some care (midi/alsaseq/).
ABOUT THE CODE
The code is a mix between C and Python. The state of some of the code is
quite horrible and ununderstandable, but relatively bug-free, eh
hopefully. :)
CONTACT
k.s.matheussen(a)notam02.no
http://www.notam02.no/radium/
--
hi richard, hi everyone!
i'm just wading through 2k5 linux audio mails, as i'm a little
behind on current affairs due to a lengthy and less-than-smooth
moving of houses.
after reading the LADSPA related threads of about a month ago, a
couple of things became obvious to me:
* LADSPA has some showstopper deficiencies to some developers
* there seems to be an ongoing battle about how essential rdf
metadata support should be: if it's purely optional, then many
things that conceptually should be metadata must be duplicated in
more or less inelegant additions to ladspa.h, and there seems to be
no real consensus on how to do that. if metadata support is
necessary even for simple hosts to create usable guis, we put the
famed 'S' in danger.
* at present, the discussion has reached the "matter of taste" point
and is pretty much dead in the water.
* with no real formal process for the development of LADSPA except
for richard's role as the "benevolent dictator", and richard being
very quiet on the matter, those developers who opt for an extension
of the spec may feel there is no way to get their proposals through.
* maybe for that reason, there has been some imho ill-advised
rhetoric towards fait-accompli tactics.
now wherever LADSPA is heading, one thing is very certain for me:
LADSPA and JACK are the very two projects that absolutely *MUST*
*NOT* *FORK* or even develop "local dialects" at this point in time.
i'm not afraid of forks in almost all contexts, but a forked
"common" api is a dead api. whatever happens, let's not jeopardize
the two major kickass components of linux audio.
there may come a time when LADSPA has become so inert and obsolete
that we should take care of it the darwin way, but this time is
still a long way off.
for that reason, let's try to cram a LADSPA BOF into the already
overflowing schedule at LAConf#2, or at least dedicate a "working
dinner" to the future of LADSPA.
i have this feeling that injecting the face-to-face factor and some
german beer into the discussion might remove some obstacles. :-D
richard, if you are reading this, some comment from your part would
also be helpful imho. i found you have not participated in the
ladspa discussions since release 1.1, which was in august 2002.
it seems everyone still considers you the keeper of LADSPA, and it
might clarify things if you stated
* your opinion on the current discussion;
* your criteria for approving extensions;
* whether you are willing and have the time to retain the role of
official LADSPA maintainer and to have the final say over what goes
in or what doesn't, or let go of this role;
* whether you can make it to LAConf#2 for a beer :)
all the best,
jörn
--
The handles of a craftsman's tools bespeak an absolute simplicity,
the plainest forms affording the greatest range of possibilities for
the user's hand.
That which is overdesigned, too highly specific, anticipates
outcome; the anticipation of outcome guarantees, if not failure, the
absence of grace.
- William Gibson, "All Tomorrow's Parties"
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)