Helge Fredriksen wrote:
>
> Did any of you guys ever tried to use the OpenAL API interface towards a
> Firewire sound device like FA-101? I see that it appears on your lists as a
> device that has drivers on Linux.
AFAIK OpenAL doesn't talk to hardware directly - it provides an API for
programs to use but sends data to the soundcard via the operating system's
native sound system. Therefore the devices supported by OpenAL are the
devices supported by the underlying operating system. For many sound cards
under Linux, that native sound system is ALSA (http://www.alsa-project.org).
OSS was the previous default native sound system under Linux and is still in
use by numerous programs.
The FA-101 is (as you'd know) a firewire interface. Support for firewire
interfaces is starting to gain momentum now but for various technical
reasons this is not provided by ALSA at this time. The support effort is
the so-called Freebob project (http://freebob.sourceforge.net) in
combination with the JACK system (http://www.jackaudio.org/), a low-latency
audio API. Only a small number of firewire audio interfaces are supported
by freebob at this time, but from what I read the FA-101 is one of them.
Getting back to your question, if OpenAL supports JACK under Linux then in
theory you could talk to an FA-101 via OpenAL. According to the OpenAL
website it currently only supports OSS and ALSA under Linux. Therefore at
this point in time you can't use OpenAL to send audio to an FA-1-1.
However, unless you particularly wanted the 3D modelling features of OpenAL
you'd probably be better off using the JACK API directly.
It should be noted that a long-term goal of the freebob project is to
implement an ALSA driver for the firewire interfaces. However, there is
still much to do before that will occur so I can't see it appearing any time
soon. Once it did appear (and assuming OpenAL don't implement an interface
to JACK earlier) you would be able to use OpenAL with the FA-101.
Regards
jonathan
After several months without a stable release but lots of development
activity, we are pleased to announce CLAM 0.95
CLAM (http://clam.iua.upf.edu) is a C++ framework for doing research and
app development in audio and music. It comes with a set of applications
ready-to-use.
Most important in this release is NetworkEditor 0.4, with a radically
reworked UI based on Qt4.2, lots of work on stability and usability, and
new visual-prototyping features.
You can visually prototype standalone apps (or audio plugins):
Edit audio networks with NetworkEditor, then edit its UI using Qt Designer
and CLAM widgets plugins. Finally, Prototyper let you run the audio network
with its UI.
This is better shown in this quick tutorial:
http://iua-share.upf.es/wikis/clam/index.php/Network_Editor_tutorial
This release comes with many new processings, mostly spectral
transformations.
But we want to highlight the tonal-analysis which does chords identification
at real-time, and its related visualizations. This code is based on the
work done by researchers at Queen Mary University (London) and Universitat
Pompeu Fabra (Barcelona). More credits are in the About box.
These and many other improvements can be found in the ChangeLog:
http://clam.iua.upf.edu/ChangeLog.txt
This release brings new packages for Linux (Debian sid, Ubuntu edgy) and
Windows installers.
In Linux, you can simply add new sources to /etc/apt/sources.list
deb http://clam.iua.upf.edu/download/linux-debian-sid ./
deb http://clam.iua.upf.edu/download/linux-ubuntu-edgly ./
Both Linux and Windows comes with desktop integration and several examples
ready to use. Mac OSX packages will be catching up next weeks.
Bug reports and any feedback is very welcomed (and needed).
The CLAM team
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Greetings:
I've not checked out recent SVN sources, but watching the devel mail
list I get the distinct impression that there's no internal development
going on with Hydrogen. Almost all traffic on the list is concerned with
translations.
So, what's the story ? Is there a Hydrogen 1.0 in the works or is it a
deader ?
It would be a deep shame to see Hydrogen's development languish.
Best,
dp
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've started to convert the information from linux-sound.org into a
distributable doku-wiki.
http://linux-sound.sonologic.nl/
This is a prototype installation and experimental suggestion!
Please review and comment before further development proceeds.
** content information **
it's basically a database of http://linux-sound.org chopped up into text
files. I have added URLs to [external] screenshots and logos to some
pages and updated or deleted a few dead links.. it's still a long way to
go, but some tasks could be semi-automated (fi. searching for dead links..)
I am open to suggestions on how to maintain the content. This prototype
is open for editing to all registered users (email verification).
I can share experiences or rewrite and improve the dokuwiki to some
extend, and may contribute to content but not on a day to day basis.
patches, suggestions and comments are welcome.
** design/layout look&feel **
no efforts have been taken to change the default dokuwiki look and feel.
Is anyone interested in
a) designing and writing a dokuwiki template
b) start a discussion on aims and goals for good user interaction design
c) create a wiki-page to host a design contest
d) rewriting the dokuwiki template ;-)
** technical- and mirror information. **
The data set is a 20MB git repository.
dokuwiki keeps it's data in txt files. I've started to put them under
git version control. The idea for mirror-sites is to
check out and branch their wiki while maintainers can merge information
upstream. dokuwiki only requires php.
The wiki itself is available as a separate git repository (incl.
pre-installed plugins and config) - the independent data-set git repos
should work with every dokuwiki installation. The whole system including
generated-meta data is about 50 MB.
more information:
http://linux-sound.sonologic.nl/devel:githttp://linux-sound.sonologic.nl/devel:setup
#robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFfI+seVUk8U+VK0IRAgrzAKDEF5aI9h8yZOis11v+T+GRTugL3wCfVc/z
N/dkTVHWwZMWz9ca8iVnDcY=
=z/Nj
-----END PGP SIGNATURE-----
Greetings:
I've received a few notes that indicate people are interested in
revising the look & feel of the site at linux-sound.org.
If you're currently working on such a project *please* make your
intentions public. There are at least two projects working towards the
same end, and this is truly one wheel that does not need reinvention.
Better that folks work together on it.
Best,
dp
Hi,
If I have a sample 2kHz sine wave signal at 50% peak.
I then add a white noise signal at 20%.
I then do a FFT transform.
If I design the FFT so that 2kHz is at the center of one of the FFT
buckets, how close will the FFT figure be to the 50% sine wave input.
Obviously, there will be a variation due to the amount of noise. So the
output of the FFT buckets will be 50+-error.
Will this variation as a result of noise decrease as I use more and more
samples per fft block? I.e.Will the +-error value decrease?
I would think it should decrease, as a result of the general averaging
the fft routine will make to the noise signal. I would think that as the
noise was random, it should average out to zero over time.
I.e. 20% noise samples. Average each sample, the average should be zero
as one reaches infinity number of samples.
So, if my reasoning above is correct. I can draw the following conclusion:
A 2kHz signal sampled at 8kHz and then FFTed, the 2kHz bucket will be
less accurate than a 2kHz signal sampled at 16kHz and then FFTed.
Now, I just need to work out how much more accurate it would be.
James
Hi everybody!
I wonder what's the common behavior for a synth/sampler regarding MIDI bank
select messages. You might know that MIDI has splitted bank indeces into two
values MSB (coarse) and LSB (fine) value. So the "optimal" behavior would be
a device / sequencer to send a MSB and a LSB bank select message to change
the current bank. But many older keyboards for example won't do that. I've
heard most of them only send MSB bank selects, while few others send only LSB
bank selects. Is that true?
If yes, how should you handle that on synth/sampler side? Because you know,
using just MSB messages would only allow to switch between the following set
of banks:
{ 0, 128, 256, ... , 16256 }
while using just LSB messages would only allow to switch between the following
set of banks:
{ 0, 1, 2, ... , 127 }
So should a synth stick with that behavior or should it detect if a device
either only sends MSB bank selects or only sends LSB bank selects and then
actually remap MSB-only selects to a set of:
{ 0, 1, 2, ... , 127 }
CU
Christian
Hello. What other sites than SourceForge hosts open source projects?
Audio and graphics projects. I'm attempting to build some kind of
developer's meta catalog of all open source projects.
Also, do people need yet another site for open source development?
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software