Linux-audio-dev November 2006

linux-audio-dev@lists.linuxaudio.org

61 participants
35 discussions

[linux-audio-dev] LAC-Konzertreport auf SWR2 15.5. 23h (German only)

by Michael Iber

Hi lists, my little report on the lac-concerts and some other subjects of the lac in Karlsruhe will be broadcasted tomorrow on SWR2 JetztMusik Magazin at 23h. Michael

17 years, 9 months

[linux-audio-dev] sampler instrument definition standard needed

by Leonard "paniq" Ritter

hi everybody, 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 -- http://www.leonard-ritter.com -- http://www.paniq.org

17 years, 10 months

[linux-audio-dev] M$/SuSE/ALSA ?

by Dave Phillips

Greetings: 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. Best, dp

18 years

[linux-audio-dev] Re: [linux-audio-user] Recording ADAT inputs on RME hammerfall 9636/52

by Stephen Cameron

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 setup window. 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 Passthru: no 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 ADAT2: Sync ADAT3: No Lock Timecode signal: no Punch Status: 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 http://mail.yahoo.com

18 years

[linux-audio-dev] [admin] maintainership passes on...

by Joern Nettingsmeier

hi everyone! 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! best wishes, jörn -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 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

18 years

[linux-audio-dev] Re: MIDI

by Gene Heskett

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. -- Cheers, Gene

18 years

[linux-audio-dev] [ANN] ghostess 20061127 release

by Sean Bolton

Announcing the latest release of ghostess, a lightweight Gtk+ host for DSSI plugins: http://home.jps.net/~musound/ghostess-20061127.tar.gz 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: http://dssi.sourceforge.net/ Enjoy! -Sean

18 years

[linux-audio-dev] C++ guru needed (again)

by Dave Phillips

Greetings: 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 -Iinterfaces -I/usr/include/freetype2 frontends/fltk_gui/CsoundGlobalSettings.cpp frontends/fltk_gui/CsoundGlobalSettings.cpp: In constructor 'CsoundGlobalSettings::CsoundGlobalSettings()': 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, see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>. 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. Best, dp

18 years

[linux-audio-dev] restarting jack

by conrad berhörster

Hello all, 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. thanks c~

18 years

[linux-audio-dev] Re: alsa, oss , efficiency?

by Danni Coy

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 issue.... I would like to ask what other libraries are being used in your application.. how portable you want it to be...

18 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev November 2006