Jon, Andy, LAD people,
http://www.dis-dot-dat.net/dasub.mp3
Playing about with a classic sampled beat - something I normally try
to avoid.
Still, I think I broke it enough that it doesn't sound repetetive.
In case your interested, there is only one beat sample, I use
cheesetracker's offset copmmand (Oxy) to pick out the bits I want and
munge the beat, kind of like recycle, but all done by hand.
You can probably guess, but the vocals are taken from Thundercats.
The voice of Mumm-Ra and a snipet explaining the eye of Thundera (the
one that now goes: THE EYE, The Eye, the eye...).
All chopping and munging was done in cheesetracker, even the crunchy
bass was made from the smooth one by over amplifying and then
filtering out the nasties. Lots of ladspa effects helped, too,
although the ones I most want to use (compressors, etc) are too slow
to be used "inline" like that.
Are there any VERY fast LADSPA compressors about?
James
It may be very well conceivable that the sources of the problem are
different. Hence my fix should only work on the CB1410 cardbuses (or perhaps
the fix is even more specific to the eMachines m680x notebooks).
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
> -----Original Message-----
> From: Russell King [mailto:rmk@arm.linux.org.uk] On Behalf Of Russell King
> Sent: Monday, April 19, 2004 4:15 AM
> To: Ivica Ico Bukvic
> Cc: daniel.ritz(a)gmx.ch; 'Tim Blechmann'; ccheney(a)debian.org; linux-
> pcmcia(a)lists.infradead.org; 'Thomas Charbonnel'; linux-audio-
> dev(a)music.columbia.edu
> Subject: Re: [linux-audio-user] snd-hdsp+cardbus+M6807 notebook=distortion
> -- FIXED!
>
> On Sun, Apr 18, 2004 at 11:12:59PM -0400, Ivica Ico Bukvic wrote:
> > > ico:
> > > would it be possible that you send me an lscpi -vv output before and
> > > after you changed the registers? maybe we see any differences there
> ...
> > > and could you ask the manufacturer of your notebook, if he knows the
> > > purpose of these registers?
> >
> > Last time I checked, he was trying to figure it out as well :-(
> >
> > I am also including the entire PDF (URL) on the CB1410. Perhaps that
> will
> > help (I got this from the notebook manufacturer).
>
> The point about Tim's problem is that he has a different Cardbus bridge,
> so the documentation and fixes for your bridge won't work.
>
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
> 2.6 Serial core
Hi all
I am busy packaging software for Slackware and trying to compile for a
specific architecture. The one problem I am finding with several packages,
is that the configure scripts obtain the architecture of the host system,
and ignore the CFLAGS variable set that contains arguments for the compiler
to compile for a specific architecture.
I am wondering whether anybody has some work-work-arounds that might work
on all packages, or could developers possibly provide a configure
command-line argument to allow a packager to compile for a specific
architecture, other than their own? For example I am running an i686
system, whereas I want to compile for an i586 based system.
Thanks
Luke
--
Luke Yelavich
http://www.audioslack.com
luke(a)audioslack.com
> ico:
> would it be possible that you send me an lscpi -vv output before and
> after you changed the registers? maybe we see any differences there ...
> and could you ask the manufacturer of your notebook, if he knows the
> purpose of these registers?
Last time I checked, he was trying to figure it out as well :-(
I am also including the entire PDF (URL) on the CB1410. Perhaps that will
help (I got this from the notebook manufacturer).
All the stuff can be found here: (including various states of the Hexdump in
Windows as well as the lspci stuff)
http://meowing.ccm.uc.edu/~ico/eMachines/
Hope this helps for the time being!
Best wishes,
Ico
> 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. :)
--