Hi,
yesterday I released ecasound-2.2.0-pre4 (approaching
next stable release, yay!), which has a few JACK-specific
improvements:
- new command-line syntax for specifying inputs and
outputs, see:
http://www.wakkanet.fi/~kaiv/ecasound/Documentation/users_guide/html_uguide…
- uses the new alsa_pcm:capture_x + playback_X syntax
(requires JACK 0.40 or newer ==> CVS!)
You can find the package at:
http://ecasound.seul.org/download/ecasound-2.2.0-pre4.tar.gz
And now to the main point: 2.2.0-pre4 comes with an updated
version of ecasignalview. Combined with the new JACK syntax,
ecasignalview now suits quite well for monitoring JACK-clients.
The basic syntax is:
ecasignalview -b:XXX -f:32,YYY,ZZZ jack_auto,foo_client null
... where:
XXX = buffersize (jackd's -p:XXX)
YYY = number of channels you want to monitor
ZZZ = sample rate (jackd's -r:ZZZ)
foo_client = any JACK client which uses out_X
style port names
The meters are drawn with ncurses, while values are queried
through the ECI API (ie. ecasignalview is only linked
against libc and libstdc++, not for instance against
libjack). The output looks like:
http://eca.cx/screenshots/ecasound-2.2.0-pre4_ecasignalview.png
... there are a few known bugs, but in general it works
quite well. While not really a huge challenge for Steve's
meterbridge ;), should be of interest to some of you.
--
http://www.eca.cx
Audio software for Linux!
Hi,
the development tree of the latest TiMidity++ was moved onto
sourceforge now.
http://sourceforge.net/projects/timidity/
there is a cvs branch, "R2_12_0_pre1b", which includes bunch of
enhancement patches. the patches sent on the timidity developer ML
(in japanese) are (occasionally) sync'ed with this tree.
also, an english mailling list was opened for non-japanese-speaking
developers and users:
http://lists.sourceforge.net/mailman/listinfo/timidity-talk
hope many people have interest and join to this project.
ciao,
Takashi
Thanks for all the helpful feedback.I have updated the main page for the
djcj site. I have tried to compromise as much as possible.
I also found an annoying bug in the Technical support database which was
dropping some of the variables before they were inserted and added a
table for notes in case you want to be specific about things :)
The database is now working properly again. For those of you who
submitted info but did not see yourself appear you can either resubmit
and I will clean up by hand or you can wait for a couple of weeks until
we have the login scripts working.
Any suggestions for the wording on the page to make it more
representative are appreciated. I want the database to be accesible to
anyone who can provide professional support in any way shape or form for
Linux Audio.
http://www.djcj.org
Best regards.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
pleased to announce the release of 'unmatched'.
'unmatched' is a simple effort to recreate some aspects of
the tone shaping of a real instrument amplifier. unlike
classical convolution techniques, it uses an IIR filter
to emulate an original impulse response, trading impulse
response fidelity for execution speed. it will easily
allow realtime setups combining compression, reverb and
other cpu-bound effects even on an aged system.
http://quitte.de/unmatched.html has the rationale and
implementation (GPL).
tim
As promised, I'd like to revive the linux audio sampler I was working on
about 2 years ago.
I was forced to take a long pause (almost 2 years) from LAD stuff
because I had to finish my CS degree before the retirement age.
But speaking speaking with various developers on LAD there seems big
interest for a high quality software sampler for Linux, especially one
that can play samples from disk since there are now many huge sample
libraries out that only work with samplers that can stream. (Halion,
GIG).
As some of you probably remember at that time, I wrote some
proof-of-concept code that demonstrate that it is possibile to achieve
sub-5msec latencies while streaming samples from disk under Linux given
a lowlat enabled kernel.
But my (and other's) vision is to write a sampler that is both efficient
and offers flexible modulation and routing plus that it can interact
with jack and other audio/midi sw present in your linux virtual studio
setup.
I was toying with the idea of using some sort of recompilation
techniques where the user can graphically design the sampler's signal
flow (routing, modulation, FXes etc) which in turns get translated into
C code that get loaded as a .so file and executed within the sampler's
main app. This would make up for a very flexible engine while retaining
most of the speed of hard coded ones.
I have set up a site and a mailinglist for the sampler at
http://linuxsampler.sourceforge.net
Without the help of all you LAD geniuses LinuxSampler will not become
the sampler I (and others) have in mind, so if you are interested to
contribute code, ideas, designs or want to give advices because you have
lots of experience with hardware samplers or windows/mac applications,
with the please subscribe to the
linuxsampler-devel mailing list at:
http://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
Since LinuxSampler will support JACK from the beginning, I hope that the
jack core members sign up to the mailing list too in order to solve
issues related to jack more quickly.
PS: I suggest to go into planning mode for a while in order to sort out
things a bit and lay out an elegant design concept in order to avoid
the usual spaghetti code projects.
thoughts ?
cheers,
Benno
http://www.linuxaudiodev.org The Home Of Linux Audio Development
> -----Original Message-----
> From: Patrick Shirkey [mailto:pshirkey@boosthardware.com]
>
> >IMO it would be much better if the link to details about
> the card would
> >not say "Install' but instead indicate that details about
> the card can
> >be found there (alsa soundcard matrix), I mean the column is named
> >appropriately drivers&docs but the item in column is always
> 'Install'.
> >It has mostly install info but also module options, known bugs etc.
>
> But it's hard to think of another word that is more appropriate.
>
> I think that for many people once they have found the link for their
> card they will bookmark that and use the matrix very rarely
> after. Once
> that is done the Matrix becomes near meaningless to an average user.
>
> For people who haven't found the page yet they are most
> likely looking
> for instructions about how to install the card. So INSTALL seems very
> appropriate there.
>
> However if people only want information about a prospective
> card it is a
> different story. In that case a different word could be more
> instructive. It would be nice to find the right one :)
IMO it would be better if it would say something like "more info", "docs",
"details" etc.
I also think that it would be very useful to have more info for
prospective buyers because at this point it is basically impossible to find
out which soundcard to buy. I am not saying you should do something about it
right now, but I hope you'll think about it:-)
erik
>IMO it would be much better if the link to details about the card would
>not say "Install' but instead indicate that details about the card can
>be found there (alsa soundcard matrix), I mean the column is named
>appropriately drivers&docs but the item in column is always 'Install'.
>It has mostly install info but also module options, known bugs etc.
But it's hard to think of another word that is more appropriate.
I think that for many people once they have found the link for their
card they will bookmark that and use the matrix very rarely after. Once
that is done the Matrix becomes near meaningless to an average user.
For people who haven't found the page yet they are most likely looking
for instructions about how to install the card. So INSTALL seems very
appropriate there.
However if people only want information about a prospective card it is a
different story. In that case a different word could be more
instructive. It would be nice to find the right one :)
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Hi all.
I have been working on a 'simple sampleplayer' that acts as an ALSA sequencer
client and can be used to play for example drum samples and loops.
Check the simsam homepage at http://simsam.sourceforge.net and download
via CVS.
There are still many things to fix... check the README for details.
Requirements:
ALSA 0.9
QT 3.0.x
libaudiofile
jack
Any feedback is welcome!
cheers,
Christian Henz
Hi,
I am working on a surround sound project. When finished this code will update a virtual acoustic environment based on a persons head motion. I am hoping for some hints on solving a problem I have. Note! My background is in signal processing, not software/hardware interfacing. So I am still clueless on the process of moving data between user memory and the sound card. Current development is done using ALSA.
My problem:
The current code can process the audio far faster then the sound card can except/output it. Therefore, to reduce the latency between head motion and changes in the sound output, I will need to keep the amount of data in the output buffer to a minimum. For the sake of discussion say about a 1024 frames (the exact amount is flexible) Currently I try to control the flow by pausing the output loop. My problem is that I keep getting buffer underruns, even when I am writing another 1024 frames of data to the sound card before 1024 frames have had time to play (which does not make any sense to me).
What I want to do is poll the data buffer so that I can determine the amount of data remaining in the buffer. So far I have only been able to determine (by polling) that the buffer is willing to accept new data.
So my question. Does anyone have a idea on how I can determine the percentage of fill in the output buffer?
I am also open to any ideas on keeping the amount of data queued for output to a minimum, in a controlled fashion.
Thank You
Dennis Thompson
*******************************************************************
Center for Image Processing and Integrated Computing (CIPIC)
Interface Laboratory
University of California, Davis CA 95616
Phone : (530) 754-9861
Fax : (530) 752-8894
e-mail : mailto:dmthompson@ucdavis.edu
URL : http://interface.cipic.ucdavis.edu/
*******************************************************************
> >Thats something that worried me, I seem to remeber that the sound of a
> >guitar changes if its not impedance matched with the AD converter. I'm
> >pretty sure, mine doesn't match passive guitars. My bass is active though,
> >and I dont have any DI boxes, so no choice anyway.
>
>
> likewise here.
The input impedance of a mixer is way too low for a guitar (10K vs. 1M
ohm for a guitar amp iirc). The resulting sound is dull when compared
with using a direct box.
anyone knows a suitable AD box that can
> team up with coaxial digital in?
I vaguely remember reading about some inexpensive a/d boxes that have
built in mic pre's and a switch for high impedance instruments, but I
don't remember their names. I use an active direct box.
Tom