Warning: Long message below...
After reaching a dead-end for the zillionth time during the last month,
I have decided to finally post my experiences here.. I apologize if
that's gonna end up feeling like a short novel, feel free to ignore it :)
To start up, my current ALSA information sits here -->
http://pastebin.ca/525842
I have an RME Hammerfall DSP + Multiface combo sound card on an Intel(R)
Core(TM)2 CPU 6600 @ 2.40GHz machine with 2GB RAM, running Ubuntu Edgy
that currently seems closer to an Ubuntu Feisty after all the upgrades I
have done on it and a simiral machine that still has the default Ubuntu
Edgy Server Edition on it with no software upgrades..
I have tried various software & configuration combinations during this
time with the aim to make the server-side of a radio ripping service.
The HDSP Multiface has 8 analog mono inputs / 8 analog mono outputs let
alone the ADATs and SPDIFs.. What I want to do is record one radio
station via some radio tuners I have here on each input of the multiface
and record each one to a separate WAV file, splitting as necessary
before the 2GB WAV file limit. Everything should be done using
command-line tools and scripts since this is a server with no GUI on top.
I have tried ALSA 1.0.12, 1.0.13, up to 1.0.14rc4 with kernels from
2.6.17-11 up to 2.6.20-16 and in addition to that I have also tried
routing ALSA through the pulseaudio sound server (using the ALSA pulse
plugin)..
I have achieved recording one input at a time using arecord but failed
to record more than one at the same time, either by using the dsnoop
ALSA plugin or by using pulseaudio.. I have tried upgrading the firmware
of the soundcard as recommended on some forums by pluging it to a
Windowz XP box and getting firmware upgrades from the RME website..
On all occasions, I keep on getting an 'unable to install hw params'
error message.. E.g.
/root@radio-master:~# speaker-test -r44100 -Ddmix -c8
speaker-test 1.0.14rc4
Playback device is dmix
Stream parameters are 44100Hz, S16_LE, 8 channels
Using 16 octaves of pink noise
ALSA lib pcm_direct.c:971:(snd_pcm_direct_initialize_slave) unable to
install hw params
ALSA lib pcm_dmix.c:876:(snd_pcm_dmix_open) unable to initialize slave
Playback open error: -16,Device or resource busy
/OR:
/root@radio-master:~# arecord -Ddsnoop
ALSA lib pcm_direct.c:971:(snd_pcm_direct_initialize_slave) unable to
install hw params
ALSA lib pcm_dsnoop.c:569:(snd_pcm_dsnoop_open) unable to initialize slave
arecord: main:545: audio open error: Device or resource busy
/
If any of you have simiral experiences, I would love to share them,
specially if someone is using the same sound card hardware and managed
to get it working properly
Thanks in advance for any information regarding this issues,
Nikos Sarakenidis
Athens, Greece
Sorry to cross post this but I got no response on the JAMin devel list
and we don't have a user list :(
We need some people to check this out and make sure I haven't totally
hosed up the program ;-)
The last commit note that was posted to JAMin devel follows:
CVS commit - 0.97.00
* Removed all XOR raster graphics operations from the HDEQ.
* Added tooltips to output and RMS peak/level text boxes.
* HDEQ spectrum curve color is now modifiable.
* HDEQ spectrum curve remains on screen when modifying HDEQ.
* Changed the default values for HDEQ background and spectrum curve
to black and cyan respectively.
This is a pretty major change. Basically, we paint all the HDEQ
background elements (EQ curve, gain lines, notch handles, crossover
bars) to a GdkPixmap and then draw the entire pixmap to the widget at
the beginning of the draw_EQ_spectrum_curve function. We then draw the
spectrum curve directly on the widget. This way we don't have to worry
about keeping track of the last time we drew the curve in the XOR
graphics plane. In addition to that we must draw the pixmap to the
widget when we modify the background elements. We also save the HDEQ
spectrum curve when we draw it so that we can draw it back on the widget
when we're modifying the background elements. That way we can at least
see the curve that was active at the time we began to modify stuff.
The main reason for making this change to the HDEQ was because I had
received a bug report having to do with a particular 3D window manager.
I suspected at the time (and still do) that it had something to do with
the XOR graphics. The other reason is that I have recently ported all
of my applications at work from Qt3 to Qt4. This has been extremely
painful as they have removed raster graphics from Qt4. At the same time
they have added alpha blending. After all the work though I found that
my applications were much more stable and I didn't have the occasional
stray line due to not erasing an XOR line properly. If I can figure out
how to do the alpha blending in GTK I may add slowly fading HDEQ
spectrum curves to the mix (configurable of course).
As I said above, this is a major change. Please try it out and see
if you have any problems. There may be some speed issues because the
XOR graphics may have been a bit faster. I have been unable to see any
slowdown on my system and, from what I've seen at work, blasting a
pixmap to the screen is really fast. Let me know if you see any
problems.
-----------------------------------------------------------------------
CVS commit - 0.97.01
* Added right-click popup menu to HDEQ
* First menu entry - Reset HDEQ curve : resets the EQ to 0 (this
used to be done by just the right-click).
* Second menu entry - Release parametric EQ controls : releases
the three, non-shelving parametric EQ controls to be reused
while leaving the EQ curve as is. This effectively means you
have an unlimited number of parametric EQ controls. You can
shape the curve with the parametric EQs, release them, and
then put parametric controls on top of the curve you built with
the parametric controls - woot!
* Third menu entry - Cancel : cancels EQ curve drawing (center
click still does this too).
* Modified the help verbiage for the HDEQ.
I think we're real close to a 1.0 release but I'd like a bit more
testing on these last two iterations 'cause they're kinda big ;-)
Sampo,
Can you send me the changes that we need to implement your limiter?
I've lost them somewhere along the line.
Reuben,
Would you please try this on Beryl and see if it makes any
difference?
Cheers,
Jan
--
Jan 'Evil Twin' Depner
http://www.thecfband.com
"Life should NOT be a journey to the grave with the intention of
arriving safely in an attractive and well preserved body, but rather to
skid in sideways, chardonnay in one hand, chocolate in the other, body
thoroughly used up, totally worn out, and screaming 'WOO HOO, what a ride'"
Hi!
I have tried this Java app http://www.cs.hmc.edu/~keller/jazz/improvisor/
with Sun's jdk 5 and 6, and have tried to find app's MIDI ports on qjackctl's
MIDI tab, but without success. 'hdsp' alsa driver is in use for RME HDSP9632,
and the card's MIDI ports are visible. The app's preferences dialog shows the
only choice for MIDI device, and it is called "DSP [hw:0,0]".
Any help?
This published on the harmony-central.com site:
PRESS RELEASE
SAE Institute has agreed to become a corporate sponsor of Ardour, the open
source digital audio workstation project. This major sponsorship ensures
continual development of Ardour as a free, community-based audio recording
and production software. Ardour has previously received corporate support
from Solid State Logic and Harrison, but has primarily relied on donations
from the public and the dedication of creator Paul Davis.
This new initiative will support the further development of Ardour to become a
viable DAW alternative for home and professional studio users, freely
available to anyone. Development aims include a more integrated experience on
Mac OS X. A separate version is intended to be developed which will be
tailored towards beginner students, whilst also being available to anyone and
staying compatible with the main branch of Ardour.
Ardour is a native multitrack recording, editing and mixing software. It
includes a powerful mixer, automation as well as flexible routing and
hardware independency through the underlying JACK audio system. Ardour offers
various synchronisation options, varispeed playback, flexible editing options
and many more features usually found in commercial products. Ardour supports
a wide range of audio-for-video features such as video-synced playback and
pullup/pulldown sample rates. There are also powerful features such as
"persistent undo," multi-language support, and destructive track punching
modes that aren't available on other platforms. The software is currently
available on Mac OS X and Linux operating systems.
Above all, Ardour strives to meet the needs of professional users.
SAE is looking forward to supporting a strong open source project. SAE CEO Tom
Misner comments, "The audio community will benefit from a viable open source
alternative to established DAW products. For a while now some of our staff
worldwide have been exploring and using Ardour and I have received positive
feedback about this software. It has always been our priority to give our
students access to a wide variety of systems. Ardour will be a great addition
to our existing industry-standard Digital Audio Workstations."
For more information, visit their web site at www.sae.edu.
CLAM 1.1, The `More eye-candy, please' release.
After a very intense development months since the last 1.0 release,
the CLAM crew is glad to announce that CLAM 1.1 is ready to
[1]download. It comes with many new features and code clean up.
Most
important improvements are found in the Visual Prototyping
front: new
3D-looking widgets, new data viewers and control surface; and a
simplified way to bind controls between the user interface and the
processing network.
To learn about CLAM: http://clam.iua.upf.edu
This release has been cooked-up under the umbrella of the
Interactive
Technology Group at the UPF lead by Josep Blat. So we thank their
support! It also features the work from contributors such as Zach
Welch; as well as the first patches from [2]Google Summer of Code
program --for example LADSPA and FAUST support and some work on
Annotator widgets.
A summarized list of changes follows. See also the [3]CHANGES files
for details. New audio related widgets were added to be used on the
NetworkEditor and the Prototyper. Such widgets include data
views such
as the BarGraph which can display LPC's, MFCC's. Nice control
widgets
were also added. The ControlSurface, for instance, to control two
scalar parameters by moving a point. Some widgets were gathered
from
the LAC community, such as [4]PkSampler [5]PovRay generated
widgets,
and nice knobs we enhanced from [6]QSynth and [7]Rosegarden.
Thanks to
the developers of those projects for making them GPL and being so
supportive while integrating them in CLAM. With all those widgets,
users now can visually build more appealing applications such
as the
new examples we include with Prototyper: A real-time gender
change, or
real-time spectral effects.
The TonalAnalysis (Chord extraction) now takes advantage of fftw3
performing 4 times faster! The KeySpace visualization was also
optimized so now tonal analysis runs even on very slow computers.
NetworkEditor and Prototyper usability have been enhanced. They
exploit the new in-control bounds parameters to automatically
set up
bounded control senders widgets. Also, NetworkEditor have proper
multi-processing selection features.
On different fronts, the code-base has been reduced by getting
rid of
Fltk and Qt3 modules since we are now focusing on Qt4, and the
documentation have been restructured and now it offers new
programming
how-tos.
The CLAM team
References
1. http://clam.iua.upf.edu/download.html
2. http://clam.iua.upf.edu/wikis/clam/index.php/GSoC_2007
3. http://clam.iua.upf.edu/doc.html#changes
4. http://www.patrickkidd.com/
5. http://www.povray.org/
6. http://qsynth.sourceforge.net/
7. http://www.rosegardenmusic.com/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think I found a way to duplicate the ALSA seq out-freakage that I noticed yesterday.
If I start up alsaseq2jackmidi, and *then* launch rosegarden, all hell breaks loose. The ALSA seq basically dies.
The solution is to shutdown all JACK apps, and jackd, then shut off or disconnect all MIDI or audio devices, and then unload all the snd-* kernel modules, and then turn on the audio and/or midi devices again, then finally restart jackd and all the apps.
Problem does not occur if I start rosegarden first, then alsaseq2jackmidi. So, not surprising, apparently ALSA and JACK get into an argument about timing.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGa0TNe8HF+6xeOIcRAqEkAKDjqspu8C9p/48TUM6uxK5ypC4c8QCgj5VC
0DqBea1qWqEAaTlSGIIri54=
=7Sq3
-----END PGP SIGNATURE-----
Wonderfully, the linux audio opensource field has become nicely populated.
Opensource means freedom of choice. One is not tied to that $400 proprietary
bloated DAW program. Comes jack and one can dissect the functionality and
network smaller pieces (if one's system can handle the multiple processes).
Trememdous freedom of choice.
Problem is: No DAW program, opensource or otherwize, interoperates with any
other. Cakewalk works with Cakewalk, Cubase with Cubase, Ardour with Ardour,
etc. Each has its strengths and each has its adherents. Never the 'twain do
meet. (Lash is fine but the restriction remains.)
Proposal: OpenDAWS.
Just as Sun's Openoffice is not using what they call an open document format,
we need a open digital audio work-stations format. Such would enable us to
work in Ardour when this suits us, Rosegarden or Muse or LMMS or Traversa or
Qtractor or whatever works best for the song. It slso opens doors [SIC] for
collaboration with those using another program with no regrets.
Base it on XML, easy to parse with any number or os parsers around. Something
like:
<requires>
<file ....../>
<file ....../>
</requires>
<track id=1 name=piano type=midi ....>
<clip id=1 type=hexmidi>.......
</clip>
....
</track>
<track id=2 name="lead vocal" type=audio ....>
<plugin name=ladspa-compressor knee=## ratio=#.# ......./>
....
<clip id=1 type=audio-link file=vocal.wav from=##### to=####/>
<clip id=2 type=....../>
....
</track>
Step 1: Specify the XML DTD.
Step 2: Subclass a C++ XML Parsor (and Java--would look more or less the
same).
Step 3: A bare open room -- program to read and play such an animal using
jack. No GUI, no editing, just read and play to demonstrate concept. Do
plugins get set up here or manually using some jack patchbay? Both (if in the
xml, do them, but I can easily enough plug in others)?
Step 4: Get opensource (and proprietary) authors to support this format and
even go over to it.
What say you?
Greetings:
I'd like to build Freecycle on my AMD64 box, but I'm running into
unending difficulties with its Qt detection. The README indicates that
Qt3 is required, which I have installed on my 64Studio system (along
with Qt4), but I'm having nothing but failure trying to get the
Freecycle makefile to find the Qt3 headers. I've tried setting QTdir and
I've tried unsetting it, I've tried using Qt4 instead of Qt3 (because
the requested headers are mostly found in /usr/include/qt4/Qt/), and
I've got 0 joy.
All devel packages are installed.
Has anyone on this list successfully built Freecycle on a Debian
system, 32-bit or 64-bit ? If so, how ?
Best,
dp
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is a weird one. ALSA seq seems to have lost its mind.
Recording with Rosegarden, my audio files epwth suddn and periodic clumpigtogethr of notes for no reason I can determ. Yes, it reminds me of dropped keystrokes on TTY's on slow network connections back in The Olden Days, just like the previous sentence :-)
Recording with arecordmidi, it's worse: all the notes get clumped togetether with a time of zero, if i use a bpm other than the default. So I don't think it is a rosegarden-specific problem, but something to do with the ALSA seq.
I've seen this problem before, many months ago, on my old system, but I was randomly tweaking so many things that I had no idea what finally fixed it... probably a new kernel. But I haven't yet seen this problem on my new machine until now.
Hmm, it appears to be intermittent, working fine now. Yes, I have all my RT stuff set up right, and the notes coming out of the audio interface sound fine, it's only the seqencer(s) that go bananas.
I'll be happy when JACK 1.0 with MIDI is released, and MIDI support is available in Ardour, but until then, any ideas what could be causing this problem and how I can fix it using the existing tools and programs? It's most distressing.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGad1me8HF+6xeOIcRAs51AKDEC7QoJNMaCEF1VGYJyOaoFhB1QwCePSiq
B1c3wq5eEbTQp5o1tqsriSs=
=VtiT
-----END PGP SIGNATURE-----
