i'm looking for a sampler instrument file format similar to .nki, .sf2
or akai instruments. is there an open standard existing already, perhaps
even accompanied by some sort of library?
-- Leonard Ritter
As many of you already know, SuSE has entered into an interesting 5-year
plan with Microsoft. You can find the details on Slashdot and
elsewheres, so I won't rehash them here.
What isn't mentioned is the ALSA/SuSE connection. I'm pretty sure some
of the ALSA developers read these lists, and I'd like to hear from them
regarding the significance of their employer's new connections and
ALSA's IP and its continued development. Is this marriage happy news for
Linux sound or is it an unholy alliance signifying doom and destruction
for the world at large (and not just the Linux audio community ;) ?
Or will things just cruise along in business-as-usual mode ?
Any and all insight vastly appreciated.
Well, mixed results tonight.
I was able to get some sound to go across the ADAT
cables from the PC to the AW4416. But not good sound.
On the bright side, I think I more or less understand
connecting things up with jack, ecasound, and so on.
On the bad side, so far it's not working too well.
I monitored things with "jackmeter" and this meter
registered peaks near 0dB for the stuff I was playing
with ecasound, and pretty high levels for the most part.
On the AW4416, the levels were registering between -30dB
and -48dB. I guess I don't understand how ADAT works.
I was under the impression the signal going across the
cables was digital -- and so to get a reduction in levels
like that, I would expect some digital numbers would have
to go from being big numbers to being small numbers, which
seems unlikely thing to happen to numbers encoded as pulses
going down a cable. So I conclude I don't know how ADAT
works, except it's not as I imagined it did.
Oh, and besides a drastic loss of signal level, the signal
was distorted strangely. Hard to describe. This may be
due to xruns... I haven't got things to work without xruns
yet, but that shouldn't cause a drop in levels, right? Just
kind of choppiness, dropouts, crappy sound, right?
Transfering from the AW4416 to the PC did not work at all.
on capture_1 and capture_2, I got very low level white noise
apparently. Are those the s/pdif ports? On the other
channels input was dead silence.
I tried both ADAT ports on the RME board, with similar results
on each. I tried swapping the two ADAT cables in case one of
the cables was bad... this did not seem to make a difference.
Maybe the RME just transmits harder than the Yamaha, so it's
signal makes it across (just barely, crossing the finish
line at -48dB) while the yamaha's signal dies.
I did change the RME's frequency to 44.1kHz in qjackctl's
Maybe there are some clues in here:
[root@zuul R15]# cat /proc/asound/R15/rme9652
RME Digi9636 (Rev 1.5) (Card #2)
Buffers: capture f6a00000 playback f6400000
IRQ: 10 Registers bus: 0xea000000 VM: 0xf88a2000
Control register: 48029
Latency: 1024 samples (2 periods of 4096 bytes)
Hardware pointer (frames): 1024
Clock mode: autosync
Pref. sync source: ADAT1
ADAT1 Input source: ADAT1 optical
IEC958 input: Internal
IEC958 output: Coaxial only
IEC958 quality: Consumer
IEC958 emphasis: off
IEC958 Dolby: off
IEC958 sample rate: error flag set
ADAT Sample rate: 44100Hz
ADAT1: No Lock
ADAT3: No Lock
Timecode signal: no
1: off 2: off 3: off 4: off 5: off 6: off 7: off 8: off
9: off 10: off 11: off 12: off 13: off 14: off 15: off 16: off
17: off 18: off
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
i'm very happy to announce that marc-olivier barre will be maintaining
the linux-audio-* lists from now on.
let me take this opportunity to ask for a few more volunteers to
moderate linux-audio-announce. get this: for years, brilliant minds like
ingo molnar, robert love and lee revellhave been toiling with the kernel
for a few measly microseconds gain - as a linux-audio-announce
moderator, you can cut latencies by hours if not days. how is that for a
claim to fame? please get in touch with marc-olivier.
it's been a pleasure to participate in this linux audio community for
all those years, and i have profited immensely from the great work done
here! thanks everyone, and i hope to see you around at LAC 2007!
home://germany/45128 essen/lortzingstr. 11/
if you are a free (as in "free speech") software developer
and you happen to be travelling near my home, drop me a line
and come round for a free (as in "free beer") beer. :-D
On Saturday 11 November 2006 21:00, Tony Nelson wrote:
>At 4:21 PM -0500 11/11/06, Gene Heskett wrote:
This thread might be of interest to the linux-audio-dev group, so I've
added them to the Cc:
>>Yup, and its been a constant src of amazement to this old fart that
>> when the midi spec was setup, they used a serial port, thats fine, but
>> when they set the data rate at only 31,250 baud, ...
>>Consistently attrocious timeing, with the horns always 1/16 beat late
>>unless the actual output order of each instrument is scrambled in the
>>order output. That would make it sound a heck of a lot less
>> mechanical. And there isn't a heck of a lot that can be done until we
>> put midi on an optical circuit running at several megabytes/sec.
>> Something like TOS maybe?
>Firewire. Many products already, plenty of speed, almost robust enough.
>1/8 millisecond isoch cycle times; each cycle can contain packets from
> many senders; each packet can contain lots of notes.
More robust IMO than the din connectors now used for midi interconnects,
however the cabling itself can't help but be more fragile when subjected
to the rigors of a jam session with bodies walking on them all night.
And that has to be a consideration else the first users will get
discouraged at the high cable failure rates and revert, particularly if
they have a tin ear and can't hear what to many of us would be an
extremely obvious improvement.
But I like that idea, a lot. Maybe some enterprising LAD people could get
together and spec something like a midi interface running over firewire,
complete with the repeaters so it can be daisy-chained just like midi can
be, and hopefully release it into the PD as a new midi-2 interface
standard. And design it such that it never, ever gets into the snails
trail of the 31,250 baud interface it uses today.
Announcing the latest release of ghostess, a lightweight
Gtk+ host for DSSI plugins:
New in this release:
- bug fixes, build enhancements and code cleanups.
- code to export patch lists to Freewheeling.
- support for the latest JACK MIDI transport.
- blinky lights indicating MIDI activity.
ghostess is written by Sean Bolton, and copyright (c)2006 under
the GNU General Public License, version 2 or later.
DSSI is an audio plugin API for software instruments and effects,
based on LADSPA, the ALSA sequencer event types, and OSC (Open
Sound Control) communications. Learn more about it here:
The following message is produced by Debian's GCC4 in 64Studio when
compiling Csound5 for AMD64:
g++ -o frontends/fltk_gui/CsoundGlobalSettings.o -c -fexceptions -Wall
-g -gstabs -O2 -fPIC -DLINUX -DPIPES -DHAVE_LIBSNDFILE=1016 -DHAVE_FLTK
-DBETA -DHAVE_FCNTL_H -DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_SYS_TIME_H
-DHAVE_SYS_TYPES_H -DHAVE_TERMIOS_H -DHAVE_SOCKETS -DHAVE_DIRENT_H -I.
-IH -I/usr/local/include -I/usr/include -I/usr/X11R6/include
frontends/fltk_gui/CsoundGlobalSettings.cpp: In constructor
frontends/fltk_gui/CsoundGlobalSettings.cpp:47: internal compiler error:
output_operand: invalid expression as operand
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
Preprocessed source stored into /tmp/ccDt1tHZ.out file, please attach
this to your bugreport.
scons: *** [frontends/fltk_gui/CsoundGlobalSettings.o] Error 1
scons: building terminated because of errors.
John ffitch has successfully compiled Cs5 for AMD64 with FLTK support,
but he used GCC3. I've tried the various options for scons, but got no
joy whenever I used Word64=1, the build always dies at the same point.
Yes, I do see the compiler report request, but when I searched Google I
found documents stating that this particular error was supposed to be
resolved already by GCC4.
Does anyone see what needs to be done to get past this point with the
FLTK stuff in Cs5 ? Any suggestions for a fix ? I'll gladly furnish any
other imformation required, just let me know what's needed.
is there a way to restart jack out of an application, or is this the reason,
why ardour need a running jackd.
i want to write an application with a "reinit app" button and need a way to
restart jackd, if it has been crashed.
cool it guys...
It sounds like the person who asked the question only really needs to
use sound in a really simple way and that performance is not a huge
I would like to ask what other libraries are being used in your
application.. how portable you want it to be...