On a fresh Fedora 11 install (HP nc8000 laptop, 1.6 Ghz Pentium M), the
Planet CCRMA kernel-rt-2.6.29.6-1.rt23.2.fc11.ccrma.i546.rt freezes on
boot with:
Starting udev: end_request: I/O error, dev fd0, sector 0
Buffer I/O error on device fd0, logical block 0
Isn't fd0 a floppy drive? There isn't one in this machine. There /is/
one across the room on a shelf -- maybe rt23 doesn't like that ;)
I disconnected all usb drives and peripheries, but no luck.
It's not a major drama, as 2.6.29.5-1.rt22.1.fc11.ccrma.i586.rt works
perfectly, as does stock Fedora kernel 2.6.29.5-191.fc11.i586.
Sorry for the negative review here on the New World.
Strengths:
The layering was fantastic for the most part. The second minute or so and following of the layered brasses had plenty of potential for something even bigger.
Weaknesses:
Was not sure if those were supposed to be water waves or static or what it was, but found it distracting. Saw quite a bit of potential with that. Then, when vocals kicked in, kinda lost me from there. The first 2-3 minutes of the song seemed to lack cohesiveness.
Possible Improvements:
Assuming those are waves in the first part of the song there, having them pan back and forth would be great. From there, having that either form the backdrop (sound canvas) or fade into the the real sound canvas. Part of that canvas needs to stem from the purpose or aim of the song. Following that, tie together the various parts. For example, that noise in the beginning could be formed better into waves and fading in those brasses. Then build the vocals on top of that.
Hope the critique was not too harsh. Would love to hear a "re-mix" of it.
The "other" Paul N.
Hi all.
It's been a long long time (years) since I suscribed to this list (in
addition to following your articles, blogs and music and using apps
and plugins), and I always thought that one day I should, not only
reading and learning "in the dark", but also contribute with my two
cents, at least with what I can.
But you know, it's hard to take that step with such a level of
knowledge and experience in here, given that DSP development and
kernel aren't my area of expertise.
Maybe, some might know me for any of the projects I am/have been
involved (hi "Packet-In-ers" friends), but that's not the point now (and I
don't like talking about myself).
So, in short, I just decided to say hello, express somehow my admiration
and gratitud, and thank you all for helping me to go to bed with
something more learned ;).
--
Carlos "Sanchiavedraz"
* Musix GNU+Linux (Musix 2.0 beta)
* http://www.musix.es
Hi everyone,
I've written a blog post about my efforts to get an easy-to-maintain
stable Linux system up-and-running, you can find the post here:
http://hardbop200.blogspot.com/2009/07/stable-linux-audio-finally.html
No surprises here, just some simple instructions on how to turn Ubuntu
Hardy into a multimedia studio, aimed at those who don't know where to
start.
I would appreciate any criticism you might have, comments, etc.
--
Josh Lawrence
http://www.hardbop200.com
I have an ensoniq audiopci card that I have been using successfully at
48000 hz for a while now. I have just started working on a project
with prerecorded material at 44100 hz, so I reconfigured jack in order
to avoid needless sample rate conversion. Somehow jack thinks that my
card is running at 44099 hz, so it is resampling the source material
anyway.
Why would my card be running at 44099 hz, is this a software or
hardware problem? I am going to just edit the wav headers to say 44099
so they agree with the engine sample rate for now, but would be
interested to know what the source of this weirdness would be.
Hi,
I'm looking for an external soundcard capable of recording and/or
playing at 192 kHz and 24 bit, well supported by linux/alsa drivers,
to be connected to my laptop, which has both usb-2.0 and firewire.
Since I'm an ham radio, my call is ik7tad, I need this high sampling
frequency because I'd like to use this card mainly for the "software
defined radio".
Googling on the web and looking in the source tree of recent kernels,
I'm not sure if the Roland/Edirol UA-101 is *well* supported.
Anyone here can tell me if this card works well at 192kHz/24bit with Linux?
Perhaps can you also suggest me another card with these specifications?
Can firewire soundcards be considered too?
Many thanks for your opinions, experiences and comments.
I have a couple DSP-for-dummies questions.
I'm still intrigued by the idea of getting a proper Auto Wah-Wah sound going.
I like the approach of building one out of LADSPA plugins.
My question is this: what tools would I use on Linux to analyze the frequency response and characteristics of the many, many LADSPA filter plugins, so as to decide which has the response closest to a real wah circuit (i.e. a lowpass with a resonant peak just above the rolloff point)?
What I'm going for is this:
http://www.geofex.com/Article_Folders/wahpedl/wahped.htm
I don't know squat about DSP, otherwise I might just try coding something up; the LADSPA spec looks pretty straightforward.
-ken
>All this will hopefully change in future and was discussed in some
>length on the LAD list some time ago. Until that changes I personally
>recommend to compile jack without dbus unless you want to use laditools.
>
I use Gentoo pro audio overlay, I have found if using FFADO i seem to need to
have the dbus USE flag turned on.
>
>> Also, I'm new to the whole live ebuilds thing. I see that the
>> overlay offers Ardour, Jack, and many other things in the form of
>> direct CVS snapshots. It seems that these are prefered, however, it
>> looks like they often require unmasked versions of dependency
>> programs. Should I be afraid of that? For example, the live ebuild
>> for Ardour seems to be trying to pull in a version of aubio that is
>> masked for amd64, though I didn't see a bug in the bug database
>> explaining why. Should I simply unmask any package that is demanded
>> of a program in the overlay on the basis that overlay programs are
>> basically bleeding edge anyway?
>
>I can't help you with that specifically since I never used gentoo but
>as a general guideline: stay away from it if you don't know what you're
>doing. A CVS (or any version control system for that matter) checkout
>might be totally broken and there's no guarantee that it will even
>compile.
>
Live ebuilds are always masked for this very reason. However you may find that
some things are worth unmasking. (I have found that for my hardware I need to use
the live ebuild for FFADO and Jack to get the best results..
You won't find reported bugs on Gentoo for live ebuilds as they aren't really
supported but the bug you find may be worth checking for and reporting upstream
(if you intend to help the particular project)... BTW Ardour 2.x live ebuild is
relatively stable but not 3.x....
I highly recommend you join the pro-audio overlay mailing list for specific
discussion around this overlay... (We won't bite :)