[linux-audio-dev] Re: [linux-audio-user] Commercial "clone" of ZynAddSubFX?
Dave Phillips skrev: <...> Zyn will occasionally just pop itself out of the JACK graph, I'm not sure why. I understand where this is coming from and Zyn is at fault here but the problem is not as grave as one can be led to believe, Zyn does not HAVE to be popped out. This all stems from the fact that Jack by default kicks all clients that cannot, for whatever reason, meet the deadline for each roundtrip. Personally I don't think this is a good practice outside of a development environment, the data may still be useful and the incident will be logged. It's a bit like using asserts to make sure you're catching ugly problems during development but in the release-version asserts are normally disabled. It is very easy to reconfigure jack to give all applications some slack using: jackd -t 4000 -d -s -t 4000 extends timeout to 4000 milliseconds -s sets jack in softmode (set for the backend I believe) (I think that's the right parameters, don't have acccess to a system right now.) Regards, Robert
Re: [linux-audio-dev] Old hat - comparison against windows
Hi, [EMAIL PROTECTED] skrev: On Tue, Jan 30, 2007 at 09:18:06PM +, Bob Ham wrote: On Tue, 2007-01-30 at 21:05 +, Bob Ham wrote: On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: Can anyone suggest ways to compare audio/midi performance between Linux and Windows that ... make Linux compare favorably? I work for a company that sells a Linux based piece of hardware that plays windows VSTs. The word "FUD" comes to mind. No idea why. Further to that, something constructive: perhaps you could try telling your customers why *you* chose linux, rather than trying to find reasons to tell them *they* should. the customers dont notice. they still use windows or no computers at all. it looks rather like a question from the management. Whatever the reasons, it's a valid and interesting question. In truth Linux is often touted (not the least with respect to audio) as a better performer than Windows. Though I can't say that I have personally experienced this. It is hard work getting a Linux system "tuned", I have actually never succeeded without some drawback that have forced me back to generic configurations. Not that I complain, my current (k)ubuntu kernel performs "good enough"tm, but I am certain it would be no problem getting equal performance under Windows. My choice of using Linux has more to do with the freedom of opensourceness (it's a word!..now atleast). Steve's idea with a vst timing plugin sounds very interesting. One using LADSPA would be equally interesting for comparing Linux to Linux. Are there other performance measurements that would be nice? xruns under load I suppose. Having a test suite for system performance would be great! I would not rule out that Linux is found to perform worse under some circumstances. But that is ok. Adaptability is one of the strong points of open source, once we know the problems we can start fixing them. Regards, Robert
Re: [linux-audio-dev] LADSPA needs & wishes
On Saturday 27 January 2007 06:47, Loki Davison wrote: > On 1/27/07, Fraser <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > I've been converting my old VST plugins over to LADSPA and have come > > across something in the api which I really miss - the inability separate > > the algorithmic to the displayed value of a parameter. > > I'm finding this inability is leading to non-ideal programming habits. > > why are you coding new stuff for a depreciated system? Why not LV2? And why should you code for a plugin standard that nothing supports? Besides, is LV2 even finished? Suggesting that LADSPA is deprecated is a bit of a stretch. It may not be perfect, but it's well supported. /Robert > It's extensible so if anything is missing you can add it. > http://lv2plug.in/ > > Loki > > p.s. > > hiking in yunnan / tibet border area is pretty awesome!
[linux-audio-dev] linux vst
Hi, I noticed that the Linux-VST site has gone online now: http://linux-vst.com /Robert -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] integrating qt apps with common plugin interface
Hi Patrick, On Monday 08 January 2007 09:04, Patrick Stinson wrote: > has anyone gotten a qt-based gui to work with audiounits, vst, rtas, dxi, > or another commercial plugin framework? No, but why should it not work? What is the problem you are expecting, event loop interference? Regards, Robert -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Re: crossplatform atomics
On Friday 26 May 2006 01:24, Loki Davison wrote: > On 5/26/06, Lee Revell <[EMAIL PROTECTED]> wrote: > > On Thu, 2006-05-25 at 19:57 +0300, Kai Vehmanen wrote: > > > Does someone have a good reference on this? I think the writes just > > > are not atomic, but you can use some tricks [1] to implement atomic > > > behaviour by spinning until the operation succeeds. > > > > Do we still care about 32 bit sparc? > > > > Lee > > Doing audio on a 32 bit sparc mmm. Why not buy a spend 150 euro > and by a 2-3 ghz intel/amd machine new? I think the idea was that since one (old) architecture does not have atomic ints there might be more. Since I really could not care less about 32bit sparc, the more interesting question would be; is it possible that non atomic ints will crop up in future hardware designs? To me it just sounds, really, really, really, improbable. 0.02 SEK /Robert
[linux-audio-dev] Re: [linux-audio-user] [ANN] netjack-0.11
Awesome! /Robert On Sunday 16 Apr 2006 22:22, [EMAIL PROTECTED] wrote: > netjack-0.11 > > > Warp your jack ports over an IP network. Also have Transport synced > between 2 machines. > > Work is underway in improving the latency for big channel counts, > like 24in / 24out. There seems to be a bottleneck in the kernels > handling of big UDP Packets. > > However netjack seems solid with a period size of 128 and a roundtrip > latency of 3 periods. (this is at 24/24 float on 100Mbit) The latency > does not seem to improve with Gbit. > > Also featuring: > > - improved error messages. > - some AutoConfig on the slave side. (only period and samplerate) > - alsa_in and _out improvements. > > Have Fun. -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Re: MusE 0.8.1 released
> app.cpp:2730: error: jump to case label > app.cpp:2720: error: crosses initialization of 'int ok' <...> > Looks like Frieder's Patch might fix it.. Testing.. Yes I think so. FWIW there's a new package on the site now where this is added. Regards, Robert > > Flo
Re: [linux-audio-dev] Re: MusE 0.8.1 released
On Tuesday 28 Mar 2006 10:13, Florian Schmidt wrote: <...> > > thing and now it _seems_ to build. We'll see.. > > Flo Just curious, did it work out? Regards, Robert -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Re: MusE 0.8.1 released
Hopefully it's configuration. I'll check for ladcca to be sure. To answer the previous question, the support is for lash-0.5.0, I've tested it and it works reasonbly (closing the project leads to a double-delete error in glibc which I don't know what causes) --- Also, for some reason lash has a tendency of taking down jack when closing on my system (regardless if muse is used). Does someone else see this? I should debug this a bit.. Regards, Robert On Tuesday 28 March 2006 07:31, Dave Robillard wrote: > On Tue, 2006-28-03 at 12:21 +1000, Loki Davison wrote: > > On 3/28/06, Florian Schmidt <[EMAIL PROTECTED]> wrote: > > > Hmm, i don't know what's up with that, but ./configure says "build > > > without lash support" and lateron it fails: > > > > > > /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -fno-exceptions > > > -Wall -W -D_G > > > NU_SOURCE -D_REENTRANT -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -I../.. > > > -I../../m > > > use/widgets -I/usr/share/qt3/include -I.. -I../../synti > > > -I../../muse/widgets -DQ > > > T_SHARED -DQT_THREAD_SUPPORT -DQT_PLUGIN -fPIC -O3 -ffast-math > > > -fno-exceptions - > > > g -O2 -o fluidsynth.la -rpath /usr/local/lib/muse/synthi -module > > > -avoid-versio > > > n fluidsynti.lo fluidsynthgui.lo fluidsynthguibase.lo > > > moc_fluidsynthgui.lo ../li > > > bsynti/libsynti.la -lfluidsynth -lasound -lm -ldl -L/usr/share/qt3/lib > > > -lqt-mt - > > > lqui > > > grep: /usr/lib/libladcca.la: No such file or directory > > > /bin/sed: can't read /usr/lib/libladcca.la: No such file or directory > > > libtool: link: `/usr/lib/libladcca.la' is not a valid libtool archive > > > make[5]: *** [fluidsynth.la] Error 1 > > [snip] > > > What lash is this anyway? is the modern, useful, actually handy for > > stuff lash as in http://www.nongnu.org/lash/ or the ladcca from dawn > > of time one? > > 0.5.0+ versions of LASH do not contain the phrase "ladcca" in any way > (including filenames). > > >From a quick glance, neither does Muse 0.8.1, so I would assume this is a > > system > > configuration problem. > > -DR-
[linux-audio-dev] [Announce] MusE 0.8.1 released
This release note is for MusE 0.8.1. It is basically a bug fix release for a note-off bug that crept into 0.8. [General] MusE is a multitrack virtual studio with midi, external, softsynths and audio support. And a bunch of other things. [URL] http://www.muse-sequencer.org/ [Changes from the ChangeLog] * Added next/prev marker, keyboard shortcut * Added LASH support (patch from evermind @ gentoo) this also means that ladcca is no longer supported * Reverted fix for silent softsynths, synths were not silenced upon [stop]. * Added Motif-Rack idf from europeen [Known issues] See the errata section on the homepage for the latest: http://www.muse-sequencer.org/wiki/index.php/Errata0.8 For a complete list of changes see the ChangeLog: http://cvs.sourceforge.net/viewcvs.py/lmuse/muse/ChangeLog?rev=1.214.2.147&on ly_with_tag=REL07&view=auto Source download available: http://sourceforge.net/project/showfiles.php?group_id=93414&package_id=184215&release_id=405163 Regards, /MusE Development team
[linux-audio-dev] [Announce] MusE 0.8 released
MusE 0.8 is here at last. [Introduction] MusE 0.8 was originally intended to be called 0.7.2 but for various reasons (featuritis, time, and because 'I wanna!') we decided to call it 0.8. This is most likely the last release in the old series, next up is the much rewritten 1.0. This release contains a number of new features lots of stability and usability improvements. All users are encouraged to upgrade. [Notable new features] - Syncronization with external hardware using Midi Clock now works (see Errata on homepage for known limitations) - Support for restaring jack during runtime - Import and export of midi parts with drag&drop support - Import of plugin-presets with drag&drop support - Internal lightweight wave editor + link to external editor - Lots and lots of improvements, see compressed ChangeLog below [New instrument definition files] - Emu Proteus 200 - Roland E-28 - Roland SCD-70 - Yamaha PSR-275 - MC-505 - Roland Fantom XR - Roland SRX-02 - Roland SRX-09 - Waldorf-Q - Yamaha 01v - Yamaha Motif - Yamaha P100 [Translations] - New polish translation - New german translation - Updated swedish translation - Updated french translation - Updated russian translation [Notable known issues] See the errata section on the homepage for the latest: http://www.muse-sequencer.org/wiki/index.php/Errata0.8 [Compressed list of changes from the ChangeLog] - Extern sync with partial looping support - muse now starts even if jack is not found - fixed a number of divide by zero errors mainly affecting zoom - Updated/improved swedish translation. - Fix for softsynths going silent under load. - amd64 fix for rtc timer - Added updated french translation from Intent - Fixed crash bug in pianoroll when moving several events outside part. - Added popup when enabling rec for a track unable to create it's wave file - Enlarged listeditor dialog (FR:1392090) - Fixed crash bug when arrowing left in an empty editor - Fixed bug in detection of RTC - Organ softsynth did not work correctly - VAM softsynth did not work correctly - Changed audio prefetch buffer to be dynamically sized after the jack buffers - Fixed race condition between threads caused lockup upon quit and load project. - dynamically extends parts, fixes bug:1363066 Paste outside segment - now tries both RTC and Alsa (in that sequence) for main timer - updated muse_ru.ts from Alexandre Prokoudine - removed assert, fixes bug:1376783, deleting track with pianoroll open crashes muse - fixed crash bug for showing plugin-guis when the plugin did not exist - fixed seg fault when deleting last note in pianoroll editor - Fixed bug 1329537 (User defined fonts not updated) - added emuproteus200.idf from Piotr Sawicki - added polish translation from Piotr Sawicki - Handle restart of Jack and restart of audio - Added new timer classes from Jonathan Woithe. - Solo for audio tracks improved by removing the possibility to mute Output tracks - Implemented REPLACE for midi recording - Fixes for Appearance dialog, background pic, event display - Marker window now toggling - Added "raise" to more dialog windows - bounce now stops correctly - Fixed position of import of wave files, inserted at cursor, now inserts at mouse - Added drag&drop support to plugin racks in mixer, internal and to/from disk - Added quick search to LADSPA plugin dialog - Implemented resize of waveparts - Added Idf files by Steve D for Roland FantomXR, SRX-02 and SRX-09 - Internal wave editor enabled with common operations, fade, cut, amplify, etc - Fixed bug with loading of background pixmaps - Fixed bug 1199171 (Time change: a part does not completely fit into 4 bars), part resize problem - Added scrollwheel support for vertical scrolling in arranger, pianoroll and drumeditor - Fixed bug 1056996: Multiple selection, but single paste. Possible to copy several parts in arranger - Fixed bug 1092424: bug in reposition of instruments in drumeditor - Fix for drumtracks and part export/import - Fix for opening Midi port/softsynth dialog when already open (now raised and set to active window) - Added export/import of midi parts (.mpt-files), drag & drop also possible - Fix for generating midi clock - Added Roland E-28 idf file from Jonathan Woithe (js) - Allows for several midi devices with the same name - Fix for bug 1198747, tests for fluidsynth and rtcap in configure.ac - Fix for bug 1198744, added patch for reading browser setting from config without crashing, from Philip Nelson - Fix for bug 1188767, downmix won't stop playback until reaching the right marker - the instrument list in the drumeditor now has fixed width when resizing the window - added nudge event position left/right w keyboard (ctrl+left/rightarrow as default) to pianoroll and drumeditor - added fixed length command to pianoroll, uses snap-to value - added snap/quantize patch from Petr Mazanec (snap of notes in pianoroll+drumeditor is now contr
Re: [linux-audio-dev] Re: Which widgets?
On Sunday 26 February 2006 08.11, Jan Depner wrote: > On Sat, 2006-02-25 at 16:56 +0200, Sampo Savolainen wrote: > > On Sat, 2006-02-25 at 13:15 +0100, Carlo Capocasa wrote: > > > Heh, I'm only a novice programmer, and I'm already lazy :) > > > > Ah, the sign of a good programmer. :) > > > > > KDE and Gnome both appear greedy to me. They both want me to use their > > > system and hence, tell me how to use my computer. Very little care is > > > taken to make sure individual parts can be used without installing the > > > whole whack. It's like I want to marry the girl I love but I can't > > > without also marrying her cousin, her sister and her aunt. This is the > > > Win/Mac philosophy, not the UNIX philosophy, and especially not the > > > free software philosophy. > > > > It's true that with KDE you are marrying into KDE's family with bastard > > cousins like ksycoca, kdeinit, klauncher etc. But this isn't true with > > gnome. > > I just want to point out, for those who do not already know, KDE is > not the same as Qt. KDE is built using Qt. I write most everything at > work using C++/Qt. I do not use any KDE libraries. I still get the > lovely printing, ftp, socket, mysql, etc widgets without having to run > any of the KDE stuff. Just wanted to chime in with a, I concur. If you want to build on a gui toolkit and get the least dependencies I think neither Gnome nor KDE are the right choices. The real choices here are QT or GTK. The choice is simple for me, QT, but that's just me... As for other toolkits, there are soon as many as there are stars in the sky, though most of them don't get installed on a standard system. I wonder how widespread fltk is? I checked it out a very long time ago there was a lot of things to like about it, small, gui-builder etc... /Robert -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Interaction bug between zynaddsubfx and muse.
On Sunday 01 January 2006 19.20, fons adriaensen wrote: > On Sun, Jan 01, 2006 at 06:42:02PM +0100, Robert Jonsson wrote: > > Indeed, there are several issues at work here... > > In anycase, MusE has from 0.7.2pre2 a fix that enables synths with > > identical names to be used. > > Also, in the case with ZynAdd, another option is to use only one > > instance. ZynAdd can have one patch for each midi-channel running. The > > only drawback is that you cannot apply external effects to individual > > patches, but ZynAdd has a whole bunch of nice internal effects. > > What's probably happening is that recent versions of JACK will if necessary > modify a client's name to make it unique, while ALSA doens't because IIRC > it doesn't care about the name but identifies clients by a number that it > assigns itself. > > So if you want unique names (and the same) for audio and midi, you still > have to provide them on the client's command line. OTOH, sequencers should > identify midi connections by their client number, not their name. To my understanding the client number is resolved/assigned at runtime making it practically useless when mapping sources with destinations. The only reliable solution is to assign unique names. Regards, Robert > > AMS should handle multiple patches without requiring a separate instance > for each. -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Interaction bug between zynaddsubfx and muse.
Hi Bill, On Sunday 01 January 2006 17.13, Bill Allen wrote: > Hi. I'm writing to the list as opposed to the individual app owners > since I can't really tell where the bug is. I have a sequence in which I > want to use zynaddsubfx as the bass and another instance of zynaddsubfx > for synth strings. The problem that I see is when I add the base > instance to the bass track, muse then gray's out both instances (which > have the same name, so I assume that muse is going through the list > graying out any instance with the given name). I do notice in qjackctl's > connection screen that the two instances of zynaddsubfx midi out have > the same name although obviously they are on different ports. The > zynaddsubfx audio instances have different names. This could be a bug - > I'm not familiar enough with the jack naming conventions to definitively > state this though. However, when I do the same in rosegarden4, it works > fine. Rosegarden4 seems to key its list of softsynths with the name and > port number. > > Thus, in conclusion it seems that zynaddsubfx might be at fault in that > multiple instances advertise themselves with the same midi out name. I > tested several other softsynths. It seems that ams, spiral modular synth > and hydrogen also share this characteristic. AmSynth appends a "serial > number" to new instances in the midi client list and I tested that muse > does indeed work fine with muliple instances of AmSynth. > > Muse might be at fault because it uses only the midi out name instead of > looking also at the port number. Given the number of softsynths that > follow the convention of identifying themselves by non-unique names, I > think muse should probably add the port number to the identifier to tell > instances of the same softsynth apart. Indeed, there are several issues at work here... In anycase, MusE has from 0.7.2pre2 a fix that enables synths with identical names to be used. Also, in the case with ZynAdd, another option is to use only one instance. ZynAdd can have one patch for each midi-channel running. The only drawback is that you cannot apply external effects to individual patches, but ZynAdd has a whole bunch of nice internal effects. Regards, Robert -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Re: Status of mLAN or similar?
Hi, On Thursday 03 Nov 2005 21:58, [EMAIL PROTECTED] wrote: > On Thu, Nov 03, 2005 at 11:18:23AM -0700, [EMAIL PROTECTED] wrote: > > Heh I really should get my head checked, my memory is going on me, so yea > > I looked into NetJack, it is for Linux;) You don't need to get your head checked. The unfortunate truth is that there are two more or less unrelated netjack projects, one is for MacOS, one is for Linux. As Torben points out I did get it to work with PPC Linux (to some degree atleast) but it won't work with MacOS. The network-transport mechanism is not the same between the two so it won't work using macosx-netjack <--> linux-netjack either, atleast not for the moment. Regards, Robert > > So if the author is reading > > this I may be able to give you some feedback soon on if it works > > crossplatform(x86 Linux to PPC Mac). > > > > However is there a way to get more than a stereo pair going back and > > forth, or am I limited in that function for right now? > > > >Seablade > > robert jonssen has a mac and implemented the endianess stuff. > my current work in cvs does not convert everything. i will fix this > soon. but i am focussing on getting the transport sync between the hosts > working. > > it is definitely a goal to make it work cross platform. > > because i intend to make some jam session with a friend of mine who will > return in january to germany > > in the mean time i need testers who verify cross-platform. > > and yes you are currently limited to 2 channels because stupid me > hardcoded the 2 in some places i did not tidy up yet. > but if you use 100mbit 4 channels should be possible without any > drawbacks. > > step by step. i dont have much spare time :( -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Edirol FA-101
Hi, On Friday 21 Oct 2005 21:27, Dmitry S. Baikov wrote: > > Are you using a customized jackd? What version? What command line? Do > > you have any evidence that anyone has ever made this work? > > Opps, sorry for skipping obviously needed details. Was really upset. > I tried freebob + jackd from freebob.sf.net. > libavc from svn, libiec61883 1.0, libraw1394 1.2 > cmdline: jackd -d iec61883 -o osc.udp://localhost:31000 > > FreeBoB wiki's list of working setups contains FA-101 + gentoo (my distro). > When run in the first time, jackd starts, but there's no sound, and > seems processing callbacks aren't called (no interrupts?). > > Dmitry. I have one of those and I got it to work (just did a short test). I'm not familiar with your particular error though. But you must understand that the driver is still alpha quality and is undergoing a complete rewrite, if you are planning to use it for everyday work you need to wait! For more info I agree with others, take it to the freebob list. Regards, Robert -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Re: [Jackit-devel] (1) Jack -- busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only?
Hi, On Sunday 25 Sep 2005 05:43, Stephen Travis Pope wrote: > Netjack sounds interesting, but the SourceForge site has no code and > no forum postings. > Perhaps this is a case of starting a project by claiming the spot on > SourceForge... The code is there, but it's only in cvs, there are unfortunately no releases made on that site yet (says a little about the lack of maturity). As for the technical merits I see that the discussion has been more about the transport mechanism and this project hasn't really touched on that subject yet. To keep it simple the data is sent via udp with floats directly. For lowlatency, CPU-hungry, work the interesting bit is that there is a master jack-server that drive all slave jack-servers, thus working around the sync issues. A drawback of this is that its only (easily) allowed to connect an actual soundcard to the master jack-server, the others are best suited for various processing tasks (Outboard effects, softsynths). Regards, Robert > > stp > > -- >Stephen Travis Pope -- http://create.ucsb.edu/~stp >Center for Research in Electronic Art Technology, University of > California, Santa Barbara > Really—I don't know what the meaning or purpose of life is. > But it looks exactly as if something were meant by it. — C. > G. Jung > > Begin forwarded message: > > From: Robert Jonsson <[EMAIL PROTECTED]> > > Date: September 23, 2005 1:23:28 PM PDT > > To: linux-audio-dev@music.columbia.edu > > Cc: Stephen Travis Pope <[EMAIL PROTECTED]>, jackit- > > [EMAIL PROTECTED] > > Subject: Re: [linux-audio-dev] Re: [Jackit-devel] (1) Jack -- > > busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only? > > > > > > Hi, > > > > On Friday 23 Sep 2005 21:35, Eric Dantan Rzewnicki wrote: > >> On Fri, Sep 23, 2005 at 12:10:15PM -0700, Stephen Travis Pope wrote: > >>> (2) My actual interest is in looking into the jack-udp protocol, and > >>> I tried getting this all to work on a Mac a few days ago and > >>> actually > >>> got much further, but it looks like file recv.c has problems > >>> since it > >>> doesn't appear to include any definition if the jackudp_t data type > >>> that it tries to declare in the first line of code; i.e., I get, > >>> > >>> /Users/stp/Code/jack/jack.udp/recv.c:14: error: 'jackudp_t' > >>> undeclared (first use in this function) > >>> > >>> Does jack.udp work in general? > >>> Is there any documentation of the actual protocol used? > >>> Has anyone thought of using TCP instead of UDP? > >> > >> Alban Peignier uses Rivendell with jack for radio broadcasts. As I > >> understand it he uses jack.udp to send the audio from the > >> broadcast box > >> to a separate box that does encoding for web streaming. So, there > >> is at > >> least one working use case. > > > > Distributing jack interests me, but sadly I have no time to dive > > deeper at the > > moment. > > Jackudp had a sibling called udpsync (not sure about the source > > heritage) > > which, instead of connecting two jacks through the client-interface > > (which is > > prone to sync problems) drives the "slave" through the backend. It > > does > > work, but is by no means finished. > > Don't know if it's of interest, the latest sources are here anyway: > > http://sourceforge.net/projects/netjack > > > > > > Regards, > > Robert > > > > -- > > http://spamatica.se/musicsite/ -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Re: [Jackit-devel] (1) Jack -- busted? (2) jack.udp -- busted? (3) jack-osx -- binary-only?
Hi, On Friday 23 Sep 2005 21:35, Eric Dantan Rzewnicki wrote: > On Fri, Sep 23, 2005 at 12:10:15PM -0700, Stephen Travis Pope wrote: > > (2) My actual interest is in looking into the jack-udp protocol, and > > I tried getting this all to work on a Mac a few days ago and actually > > got much further, but it looks like file recv.c has problems since it > > doesn't appear to include any definition if the jackudp_t data type > > that it tries to declare in the first line of code; i.e., I get, > > > > /Users/stp/Code/jack/jack.udp/recv.c:14: error: 'jackudp_t' > > undeclared (first use in this function) > > > > Does jack.udp work in general? > > Is there any documentation of the actual protocol used? > > Has anyone thought of using TCP instead of UDP? > > Alban Peignier uses Rivendell with jack for radio broadcasts. As I > understand it he uses jack.udp to send the audio from the broadcast box > to a separate box that does encoding for web streaming. So, there is at > least one working use case. Distributing jack interests me, but sadly I have no time to dive deeper at the moment. Jackudp had a sibling called udpsync (not sure about the source heritage) which, instead of connecting two jacks through the client-interface (which is prone to sync problems) drives the "slave" through the backend. It does work, but is by no means finished. Don't know if it's of interest, the latest sources are here anyway: http://sourceforge.net/projects/netjack Regards, Robert -- http://spamatica.se/musicsite/
Re: ZynAddSubFX was: Re: [linux-audio-dev] some new soundfiles on-line
On Friday 13 May 2005 21:02, Jens M Andreasen wrote: > On Fri, 2005-05-13 at 20:05 +0200, Robert Jonsson wrote: > > I've started to use Zyn now too :) Under mdk 10.2. > > I think it works, though they haven't packaged the instruments, which is > > a shame. > > > > What is it exactly that you don't get to work? > > Just about anything (?!) > > I can get to the dialogue with simple/advanced UI, and choose "simple". > Then I see this inviting clickable keyboard (and some knobs ..) > > Jack is running, and ... hey, let me copy/paste some of the dialogue I > see, wait ... > > >$ jackd -R -P 16 -d alsa -p 32 -n 3 -r 44100 -S >$ zynaddsubfx > > Say what? Where did the "too many notes" go? Where did the jack xrun go? > > ??? I do not get the same result today as yesterday (heh, I know you are > calling the inexprienced user card now ...) ;) Do try with a bigger buffer, I generally run with 256-512. I'd think it quite possible that it makes a differance. Zyn isn't realtime safe (yet), it's syntesis capabilities more than make up for that though. /Robert -- http://spamatica.se/musicsite/
ZynAddSubFX was: Re: [linux-audio-dev] some new soundfiles on-line
On Friday 13 May 2005 18:28, Jens M Andreasen wrote: > On Fri, 2005-05-13 at 08:13 -0400, Dave Phillips wrote: > > Greetings: > > > > Now if I can just get seq24 working with JACK... ;) > > I see that you are using zynaddsubfx. Now if only I could get that one > to work ... > > :) > > It is in Mdk-10.2 (Congratulations Paul), but it seems like nobody cared > to test it beyond that it 'compiles'. I've started to use Zyn now too :) Under mdk 10.2. I think it works, though they haven't packaged the instruments, which is a shame. What is it exactly that you don't get to work? > > > Best regards, > > > > Dave Phillips -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] list removal
Hi David, I think this is best handled by each individual. it's also easier on the admins. Try visiting this page: http://www.linuxdj.com/audio/lad/subscribelad.php There's a link for unsubscription if you scroll down. Regards, Robert On Monday 02 May 2005 17:59, David Wessel wrote: > Could you please remove me from your mailing list as I will be away > from email for an extend period of time. > > I'm David Wessel at [EMAIL PROTECTED] > > Thank you, > > David Wessel -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] debugging realtime issues with instrumented kernel
Great, thanks for all the info everybody! /Robert On Tuesday 12 Apr 2005 13:01, Florian Schmidt wrote: > On Tue, 12 Apr 2005 12:28:21 +0200 > > Robert Jonsson <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I recall someone (Lee?) mentioning something along the lines of using a > > recent kernel with Ingos patches to get feedback on realtime problems of > > your own code. It sounded very interesting! > > > > Now, I can't for the life of me find the message, if someone knows > > anything about this I would very much appreciate some more information, > > are there any links? > > > > Thanks in advance, > > Robert > > Hi, > > you need a realtime preemptive kernel. Read about them here (i just > updated the RP-patch-script to create a current kernel (the realtime lsm > version i use is a tad bit older. it should still work though, will > update when i come home from university)): > > http://www.affenbande.org/~tapas/wiki/index.php?Realtime%20Preemption > > You will need to enable user triggered tracing in the kernel hacking > section of the kernel config (i just patched up a recent RP kernel and i > cannot find the option anymore - anyone please fill me in.. maybe you > just need to enable the other tracing mechanisms there and then enable > the user triggered tracing via one of the control in /proc/sys/kernel/. > Ah damn, that's what you get for not following kernel development > closely).. > > You also need to compile jackd (i think you need the CVS version for > this) with the > > --enable-preemption-check > > flag during ./configure > > If an app is preempted now during its process() callback it will receive > a signal SIGUSR2 (iirc), and since most apps don't handle this signal, > they will exit.. The syslog will contain a report about what exactly > triggered the preemption.. > > Note though that this check is not garanteed to trigger for possibly > unsafe code.. It will trigger only if the process really is preempted. > > Flo > > P.S.: Please correct me and fill in missing details. I will then create > a page on my site about this.. -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Linux Audio Conference 2005 Live Audio/Video streams
Hi, On Thursday 14 Apr 2005 09:19, Joern Nettingsmeier wrote: > Joern Nettingsmeier wrote: > > hi everyone! > > > > > > > > for those interested in linux audio development, the linux audio > > conference 2005 (http://lac.zkm.de) at the center for arts and media in > > karlsruhe/germany will be streamed live in both vorbis and theora > > formats. > > since we've got lots and lots of bandwidth to burn on our relay network, > can somebody get this on slashdot? > > bring it on :) Uh oh :) I wasn't until very recently aware that theora had gotten to the stage that it actually works, great news. Sending a mail to the maintainers at http://theora.org would probably be a good idea as well. I'm sure they would be very interested in spreading the news. One more thing, could it be listed on the lac page where in the world the relays are? You could probably figure it out but it would be nice if the info was readily available. /Robert -- http://spamatica.se/musicsite/
[linux-audio-dev] debugging realtime issues with instrumented kernel
Hi, I recall someone (Lee?) mentioning something along the lines of using a recent kernel with Ingos patches to get feedback on realtime problems of your own code. It sounded very interesting! Now, I can't for the life of me find the message, if someone knows anything about this I would very much appreciate some more information, are there any links? Thanks in advance, Robert -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] Re: OSC-Question
On Tuesday 29 Mar 2005 18:38, Juhana Sadeharju wrote: > >From: Jan Depner <[EMAIL PROTECTED]> > > > >> >No, imho one of the main advantages is Qt's Signal/Slot mechanism > >> > >> sigc++ > > How to implement signal/slot mechanism in simplest terms with C? > In my opinion, sometimes it is unnecessary to link to a massive > code libraries if only one feature is needed. > > AlsaModularSynth uses Qt's signals and slots in audio processing, It does? If memory serves me signals and slots are not realtime safe, moreover they are only allowed to be used from one thread. Hence, if you have a GUI only that thread can utilize these features. > and thus requires the whole Qt and mixes GUI toolkit to audio side. > It could be wise to use sigc++ or minimal S/S code in audio processing > and Qt only in GUI. > > But because Qt comes with every Linux distribution, maybe bad > dependencies can be allowed. I don't see why Qt is a bad dependency, on the contrary, having it all in one place seems like a very good way to cut down on dependencies. Since it's mostly used as a shared library the impact becomes much smaller as soon as you use more than one program linked to Qt. Though, if I'm right about the above, it might be the totally wrong choice. -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] jack.udp issues
Hi Antonio, On Monday 21 Mar 2005 05:48, Antonio "Willy" Malara wrote: > jack.udp for me means many underrun in this configuration: > > x86 pc > jackd -d alsa -d hw:0 > jack.udp recv > ^ > > | (FastEthernet network (100mbps)) > > powerpc pc > jackd -d dummy > jack.udp -r IP send > > the first thing that came in my mind was some network troubles like > mtu.. further investigation (like involving two x86 hosts, or working > directly without the switch, working with 802.11b networks...) made me > think that jack.udp uses the audiocard driver for some kind of timing. > now, i've some troubles running an audiocard with jack in the powerpc > (my main computer) there is a way to make this system usable with dummy > driver? i've noticed that this dummy driver has a "delay in microsecs" > parameter, now i think if i can calculate the right number the problem > will fade away, but i dont know how to do the math :( > > some one has an idea on this? or has solved a similar trouble? I have no real answers but as I've been thinking about using jack.udp (in exactly this setup) in a while I realize I'm up for the same problems. I think Jack uses the sound card as timing source and that is the pipe that all other apps have to dance to. With two different computers with two different jack instances, both operating with this precondition, I can't see how it can possibly work... Is anyone successfully using two jack instances like this? One use case I've been thinking about myself is offloading for example linuxsampler and brutefir (or the other IR reverb wosname) to a second computer. In case of the reverb I'd like to send data both ways. Would it be possible to change something in jack to allow one of the instances to "slave" from the other? Interesting stuff, thanks for the heads up! Regards, Robert > > another question out of this trouble: someone knows how to raise the IRQ > priority of the USB controller to an usable value? possibly not > involving the use of the realtime patch, inusable on ppc-powermac, > > thanks for attention and eventual replies, and keep the good work on > this audio software :) > > willy -- http://spamatica.se/musicsite/
Re: [linux-audio-dev] LADSPA stereo-expander
söndagen den 6 februari 2005 22.18 skrev Andrew Gaydenko: > Among other there is opportunity to play with LADSPA plugin > controls automation in Ardour. Saying "to play with stereo > effects" I mean playing with such automated parameters of > an appropriate plugin. Ah, I see, I misunderstood what you wanted to achieve, sorry. As for stereo effects in general there are a bunch in the swh kit (as listed) and the tap-plugs (http://tap-plugins.sourceforge.net) might be of interest. /Robert > > Andrew > === On Sunday 06 February 2005 23:26, Robert Jonsson wrote: === > > > Nothing special. Just want to play with stereo-effects in Ardour. > > Ok, I don't know ardour to well. > > Can't ardour do the splitting, with a bus or something? > > /Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] LADSPA stereo-expander
söndagen den 6 februari 2005 16.40 skrev Andrew Gaydenko: > Nothing special. Just want to play with stereo-effects in Ardour. Ok, I don't know ardour to well. Can't ardour do the splitting, with a bus or something? /Robert > > Andrew > > === On Sunday 06 February 2005 17:42, Robert Jonsson wrote: === > Hi, > > I think a relevant question here is what the use-case is, what is it that > you plan to accomplish ? > > /Robert > > söndagen den 6 februari 2005 11.31 skrev Stefan Turner: > ... > > > > Is there some kind of LADSPA plugin with stereo base > > > expansion capabilities? -- http://spamatica.se/music/
Re: [linux-audio-dev] LADSPA stereo-expander
Hi, I think a relevant question here is what the use-case is, what is it that you plan to accomplish ? /Robert söndagen den 6 februari 2005 11.31 skrev Stefan Turner: > > Hi! > > > > Is there some kind of LADSPA plugin with stereo base > > expansion > > capabilities? > > > > Thanks! > > Andrew > > Is this what you mean: > > http://www.plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#id1422 > > Stefan Turner -- http://spamatica.se/music/
Re: [linux-audio-dev] Mx41 update
Hi, söndagen den 30 januari 2005 01.28 skrev Jens M Andreasen: > On lör, 2005-01-29 at 21:42 +0100, Robert Jonsson wrote: > > lördagen den 29 januari 2005 21.12 skrev Robert Jonsson: > > > Hey there, > > > > > > I just realised that Mx41 now supports both alsa and jack :). > > Mx41 have supported alsa and jack since the renaming from Mx4 to mx41. A > limited version have been in circulation in beta since late autumn/early > winter with a warning that specs might change. Just me that don't pay attention then :) > > > > I took it for a spin though the result was very confusing. It seems OSS > > > is still used even if alsa is detected, atleast it seemed I don't have > > > to connect anything in alsa to get my external keyboard to make sound > > > through it. > > Correct. Mx41 will assume you'd like to play right away and grab midi-in > if possible. But if you start, say Rosegarden first, it will be happy to > supply just an Alsa interface. And yes, you can have one application > using the Alsa interface and still play along with it using OSS. I want to use it through MusE, same use case I guess. It seems to me it always supplies the OSS connection regardless if there is anything connected over alsa. I've connected the synth to MusE and regardless if I enable midi on the selected track the synth happily plays along with what I do on the keyboard, I also cannot find any connections through alsa so I assume it's the OSS connection. > > > > Also I was unable to switch patches, infact, nothing I did in the GUI > > > seemed to change anything... > > > Is there some beginners error I'm doing? > > This is strange and definately not intended? Can yo elaborate? Ah. I got it working, the synth was sending out midi on channel four or some such, so all changes I made to the instance on ch 1 had no effect what so ever. ;-) beginners error. Ofcourse the editing started to work also. I was going to complain that it was hard to edit the settings for just one oscillator when it occured to me that there was a volume for each of them. Turning it down made it work out just fine. Not that the sound I got out of it really sounded like anything ;) I'm quite inexperienced with editing synths. <> > > Lastly, updating it to a DSSI would be a great feat for the integration > > possibilities. > > Use the source! Patches are welcome ... Hehe, we'll see ;-) Regards, Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] Mx41 update
lördagen den 29 januari 2005 21.12 skrev Robert Jonsson: > Hey there, > > I just realised that Mx41 now supports both alsa and jack :). > > I took it for a spin though the result was very confusing. It seems OSS is > still used even if alsa is detected, atleast it seemed I don't have to > connect anything in alsa to get my external keyboard to make sound through > it. > Also I was unable to switch patches, infact, nothing I did in the GUI > seemed to change anything... > Is there some beginners error I'm doing? Hmmm, I had tried it as root, I tried as a normal user and it worked much better. I could also switch patches in the GUI. Editing the sounds seemed very tempermental though, I think I managed to change some parameter but not a lot... The GUI takes a little getting used to also, but for some reason that's the norm for synths ;) Lastly, updating it to a DSSI would be a great feat for the integration possibilities. /Robert > > /Robert > > lördagen den 29 januari 2005 01.01 skrev Jens M Andreasen: > > Mx41 minor update at > > http://hem.passagen.se/ja_linux > > > > This wasn't on my todo list, but I just stumbled over the missing link > > in the voice assign/stealing algorithm and couldn't help implementing > > it. Just to check out if it really worked ... and I think it did :) > > > > I now have voices in five assignment-ques: > > > > silent // absolutely idle voices > > released // voices about to become idle > > excess holdpedal // elder voices than mentioned below .. > > holdpedal// the two most recent voices for a given key > > fingered // voices where the key is still pressed > > > > ... and a short two-voice que for each key to figure out the 'excess' > > part. > > > > Voice assign will at best find a silent voice and at worst a fingered > > voice. > > > > Rolls (tremolo?) now works proper without stealing highest or lowest > > note, nor anything inbetween for that matter. Finally! > > > > > > Is there room for improvement? Yes I think so ... It is now possible to > > get 'clicks' with certain combinations of envelope and playingstyle. On > > the other hand it is also quite easy to avoid, so I will work slowly on > > this one. -- http://spamatica.se/music/
Re: [linux-audio-dev] Mx41 update
Hey there, I just realised that Mx41 now supports both alsa and jack :). I took it for a spin though the result was very confusing. It seems OSS is still used even if alsa is detected, atleast it seemed I don't have to connect anything in alsa to get my external keyboard to make sound through it. Also I was unable to switch patches, infact, nothing I did in the GUI seemed to change anything... Is there some beginners error I'm doing? /Robert lördagen den 29 januari 2005 01.01 skrev Jens M Andreasen: > Mx41 minor update at > http://hem.passagen.se/ja_linux > > This wasn't on my todo list, but I just stumbled over the missing link > in the voice assign/stealing algorithm and couldn't help implementing > it. Just to check out if it really worked ... and I think it did :) > > I now have voices in five assignment-ques: > > silent // absolutely idle voices > released // voices about to become idle > excess holdpedal // elder voices than mentioned below .. > holdpedal// the two most recent voices for a given key > fingered // voices where the key is still pressed > > ... and a short two-voice que for each key to figure out the 'excess' > part. > > Voice assign will at best find a silent voice and at worst a fingered > voice. > > Rolls (tremolo?) now works proper without stealing highest or lowest > note, nor anything inbetween for that matter. Finally! > > > Is there room for improvement? Yes I think so ... It is now possible to > get 'clicks' with certain combinations of envelope and playingstyle. On > the other hand it is also quite easy to avoid, so I will work slowly on > this one. -- http://spamatica.se/music/
Re: [linux-audio-dev] MuSE or Glame Bandpass Analog Filter
Hi Philippe, <...> > The problem is that MuSE does a strange thing. Let me explain : > > I have 2 stereo tracks > track 1 connected to Tx without effect > track 2 connected to Tx with the Glame Bandpass Analog Filter > > So, if I activate the plugin of the track 2 the track 1 looks mono and I > can hear that the effect is also acting on it. > > is this a bug in MuSE or it is the Glame Bandpass Analog Filter to claim > the fault ? Sounds weird. I tried this setup and it seems to work ok for me, apart from that the Glame plugin seems quite itchy, defaulted to a zero setting and took a while before it started to give out sound. In other news we put out a new release the other day, if haven't got it already it might be an idea to upgrade. Not that I can recall anything having been fixed in this area, but you never know... > > Best regards > > Philippe > > PS : it would be nice if the interface window of a plugin closes when we > remove the plugin from the track :) Are you sure it's when you remove them they get stuck? When I remove a plug the GUI disappears just the same. However if I open a new song the the plugins from the old song are not correctly removed. Anyway, I added it to our tracker: http://sourceforge.net/tracker/?group_id=93414 Regards, Robert -- http://spamatica.se/music/
[linux-audio-dev] Re: [ann] muse-0.7.1 is released
Ahem, the release is available at: http://muse-sequencer.org/wiki/index.php/Download or the direct link: http://sourceforge.net/project/showfiles.php?group_id=93414&package_id=99091&release_id=297035 Sorry about that ;-) /Robert
[linux-audio-dev] [ann] muse-0.7.1 is released
Hi everybody, MusE 0.7.1 has now been released. This release is mainly a bugfix release, though a number of new features have been added. All users are encouraged to upgrade. Notable new features: - New synths + DeicsOnze from Alin Weiller + SimpleDrums from Mathias Lundgren - Audio metronome - Some new instrument definition files: + Alesis QSR,QS7 and QS8 + Access Virus + Hammond XB + Waldorf Microwave + ZynAddSubFx Notable things that are planned but not yet in this release: - Getting external-midi-sync to work again - reading of muse 0.6.x songfiles Notable bugs: - See the errata section on the homepage for the latest: http://www.muse-sequencer.org/wiki/index.php/Errata0.7 A selection of changes from the ChangeLog: * Now the length is updated when importing a midi file to a project, fixes bug: 1056994 * Disabled freewheeling for bounce functions (song.cpp:_bounce) * Fixed bug: 1094622, MidiTransform now uses new controller types * Fixed bug with custom plugin guis that caused them to be uninitialized * Fixed a crash problem when using several fluidsynths * Now fluidsynth restores most memory upon deletion * Fixed crash / hang when closing connected jack apps * Insertion of tempo events in list mastereditor added * Added support for changing time signature in list master editor * Added support for changing tempo + position of tempoevents in list mastereditor * Backported auto rec-enable from HEAD branch * Added visual feedback of marker addition in ruler as well as possibility to remove markers with shift+rmb * Made it easier to resize the last track (bug: 1041798) * Fixed bug: 966005, new projects are now called "untitled" * fixed bug: 1085791, no more crashes with delete + drag * Listedit bugfixes. Consideration of part offset used for events * Fix for bug #1085796 (when renaming channel by doubleclicking it in tracklist and a part is selected, pressing return opens editor for part) * -a (No Audio) flag added, improved Dummy audio backend * fixed import of type 0 midi files * fix midi import: tick values of tempo/signature and marker events are now properly converted to internal resolution (backport from 0.8) * Added Alsa Timer as a new timing device * Made some changes to how threads are created, for systems where thread creation has been erratic, linux2.6 in various configurations. For a complete list of changes see the ChangeLog: http://cvs.sourceforge.net/viewcvs.py/lmuse/muse/ChangeLog?rev=1.214.2.41 Regards, /MusE Development team
Re: [linux-audio-dev] Plans/Roadmaps for 2005?
Hi, lördagen den 8 januari 2005 15.44 skrev Chris Cannam: <...> > A related thing I'd like to see is a DSSI synth plugin that plays > Hydrogen drumkits. I nearly wrote one a few weeks ago, but, well, time > didn't quite permit... I wonder how hard it would be to make a "backend" to adapt it to the DSSI architecture, as an alternative to the jack/alsa backend. That would be an even better choice no? Oh, I guess the question goes for any architecture. /Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
tisdagen den 4 januari 2005 21.57 skrev Chris Cannam: > On Tuesday 04 Jan 2005 20:20, Dave Robillard wrote: > > Personally, I think it's a disgusting waste of time and effort to > > make every stereo plugin have to have a mono->stereo sibling. It > > just /screams/ bad solution. > > I agree, it sounds ridiculous -- on first hearing at least. I'm going > to have to go and read some of this ardour-dev discussion (it's not a > list I subscribe to) and see if it makes any more sense to me then. > > I realise it's not easy (or even always possible) to do the Right Thing > in the host -- my own host has some way to go too -- but I don't > understand why it should be better to create dozens of spurious plugins > than to give the user the information they need and let them decide how > a plugin should be handled. In ardour, which allows for any channel configuration I guess this might be harder. In MusE only 1 and 2 channels are supported at the moment, in which case it is simpler, atleast that's how I interpret it. 1. Insert a mono plug on a stereo track and both channels will be mixed into the plugin. 2. Insert a stereo plugin into a mono track and it will be split to both inputs. /Robert > > > Chris -- http://spamatica.se/music/
Re: [linux-audio-user] Re: [linux-audio-dev] announce-list policy
Hi, I have mixed feelings about this. It sounds like the "right thing to do" having a specific announce list and the crossposting can be a bit tideous at times... But, looking at the current statistics of the mailinglists makes me feel this policy won't work. Currently there are 924 subscribers to LAU, 806 to LAD but only 355 to the announce list. First, I believe most announcements deserve a larger audience than that. Secondly, I'd think that pretty much everybody subscribed to LAU would be interested. So, what to do, should we force subscribe everybody on the LAU list to the announce list? It's possible but possibly it would offend someone. It would be interesting to know if there are people on the announce list that are not subscribed to either LAD or LAU? If that is the case the announce list does serve a purpose (it also means that even more people on LAU/LAD do not subscribe to it). If the announce subscribers also subscribe to either LAU or LAD I think it would be best to drop the announce list all together, then it does not work as I think it was intended. My 2 cents. /Robert söndagen den 12 december 2004 13.45 skrev martin rumori: > hi *, > > On Sun, Dec 12, 2004 at 01:58:08PM +0200, Kai Vehmanen wrote: > > My suggestion is that we drop this policy altogether: announcements > > should be sent to LAA and optionally to LAD and/or LAU. At least I've > > always had > > totally agreed. being subscribed to another mailing list does not > harm as long as the policy is clear and respected by everybody. > > i'd vote for an announce-only list and very few major announcements on > LAD and LAU as well. > > i am currently not subscribed to LAU, but when i used to, the > announcement crosspostings between LAD and LAU were already much more > tedious than a single announce list would have been. > > bests, > > martin -- http://spamatica.se/music/
Re: [linux-audio-dev] muse and /dev/rtc
On Monday 22 November 2004 16.33, Matthias Nagorni wrote: > On Mon, 22 Nov 2004, Alfons Adriaensen wrote: > > On Sun, Nov 21, 2004 at 03:02:24PM -0500, Lee Revell wrote: > > > > CONFIG_APM_RTC_IS_GMT=y > > > > CONFIG_RTC=m > > > > CONFIG_GEN_RTC=m > > > > CONFIG_GEN_RTC_X=y > > > > CONFIG_HPET_RTC_IRQ=y > > > > CONFIG_SENSORS_RTC8564=m > > > > CONFIG_SND_RTCTIMER=m > > > > > > OK this all looks good. I don't know, it sounds like a bug in Muse. > > > There must be some incompatibility using a binary Suse Muse package > > > with a Mandrake kernel. > > > > Maybe it doesn't look good. I found this (the message is in French, > > but the quoted part says it all): if CONFIG_HPET_RTC_IRQ is defined, > > then RTC_IRQ is undefined which in turn leads to the failing ioctl(). > Ah, good with conclusive proof. In the meantime I found out about the timer features of ALSA. http://www.alsa-project.org/alsa-doc/alsa-lib/timer.html Unless I'm missing something (which I very well might be) it seems to work regardless. Perhaps it uses the HPET? It also seems to work on PPC/Linux which solves another issue. I'm in the middle of trying to implement it in MusE, I guess I'll see if it works. Regards, Robert > Exactly: If you set > > CONFIG_HPET_RTC_IRQ=n > > and recompile the (SuSE 9.2-)kernel, MusE should work. -- http://spamatica.se/music/
Re: [linux-audio-dev] muse and /dev/rtc
söndagen den 21 november 2004 19.39 skrev Lee Revell: > On Sun, 2004-11-21 at 18:06 +0100, Robert Jonsson wrote: > > Hi Werner, > > Is this a custom compiled kernel or a binary? It's the standard Mandrake 10.1 kernel, haven't started with lowlatency tuning yet. > What is the output of: > > zgrep RTC /proc/config.gz I guess you mean /boot/config It prints: CONFIG_APM_RTC_IS_GMT=y CONFIG_RTC=m CONFIG_GEN_RTC=m CONFIG_GEN_RTC_X=y CONFIG_HPET_RTC_IRQ=y CONFIG_SENSORS_RTC8564=m CONFIG_SND_RTCTIMER=m /Robert > > ? > > Lee -- http://spamatica.se/music/
[linux-audio-dev] PPC Linux, precision timing problem
Hi, Another RTC question that is absolutely unrelated to the other one (promise ;-). Been poking at a PPC based linux system lately. Now, if I've been correctly informed (and my photagrafik memory isn't playing tricks on me) the Apple PPC platforms lacks an RTC compatible device. Major stumbling block... how does one accomplish an high resolution timer in this environment, any ideas? What does a Mac use? Regards, Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] muse and /dev/rtc
Hi Werner, söndagen den 21 november 2004 14.16 skrev Werner Schweer: > enter as root > "echo 1024 > /proc/sys/dev/rtc/max-user-freq" I had tried that previously, tried it again and it does not work for me atleast. > > this allows users to set rtc frequencies up to 1024 Hz Right, and since I'm currently trying as root it shouldn't make any difference. I get the feeling something is seriously wrong with the RTC. I tried: cat /dev/rtc which I recall previously just meant that the cat hanged on the device. Now if I do this it returns with the error: cat: /dev/rtc: Input/output error I got a mail suggesting that it could have something to do with HPET, High Precision Event Timers. Don't know if that's included in this kernel, will check. Regards, Robert > > /werner > > On Saturday 20 November 2004 21:59, Uwe Koloska wrote: > > Hello, > > > > now that my audio inteerface is working, I can try the wealth of audio > > applications. > > > > Starting the SuSE supplied muse (0.7.0) it refuses to start cause it > > cannot use /dev/rtc. Since I used the audio group also for providing the > > realtime capabilities, I changed the group and mode of /dev/rtc to > > crw-rw 1 root audio > > But then it gives the following error message: > > cannot set tick on /dev/rtc: Unpassender IOCTL (I/O-Control) > > für das Gerät > > precise timer not available > > > > What is missing? Do I have to update the provided muse to a newer > > version? > > > > Uwe -- http://spamatica.se/music/
Re: [linux-audio-dev] muse and /dev/rtc
Hi Uwe, lördagen den 20 november 2004 22.59 skrev Uwe Koloska: > Hello, > > now that my audio inteerface is working, I can try the wealth of audio > applications. > > Starting the SuSE supplied muse (0.7.0) it refuses to start cause it cannot > use /dev/rtc. Since I used the audio group also for providing the realtime > capabilities, I changed the group and mode of /dev/rtc to > crw-rw 1 root audio > But then it gives the following error message: > cannot set tick on /dev/rtc: Unpassender IOCTL (I/O-Control) > für das Gerät > precise timer not available > > What is missing? Do I have to update the provided muse to a newer version? I just posted another message here which I think is exactly the same issue. I believe something has changed or gone broken in recent 2.6 kernels that cause this behaviour. Could you give some more info about your system? Mainly kernel version. /Robert > > Uwe -- http://spamatica.se/music/
[linux-audio-dev] cannot set tick on /dev/rtc: Inappropriate ioctl for device
Hi guys, Trying to move to a 2.6 kernel here. More specifically I've tried the kernel bundled with Mandrake10.1. I'm not expecting any lowlatency miracles but I was expecting it to "work". The error I get is (when starting MusE which needs RTC): cannot set tick on /dev/rtc: Inappropriate ioctl for device rtc is there. Apparently something is wrong with it. I googled a bit and it seems this has been up here before, with other kernels, so it doesn't seem like an Mandrake issue. Anybody know what this is and what to do about it? /Robert -- http://spamatica.se/music/
[linux-audio-dev] Re: [linux-audio-user] Re: [ardour-users] more music with Ardour
On Tuesday 16 November 2004 13.44, Frank Barknecht wrote: > Hallo, > > Dave Phillips hat gesagt: // Dave Phillips wrote: > > I've added another recording to my "music made with Ardour" page, a > > guitar duet this time. It's a performance of an old Jimmy Dorsey tune > > called Maria Elena, you can check it out here: > > Very good. Dave, we really need you to perform in Karlsruhe next year. > Both of you! ;) > > Ciao Great music! :) I like the idea of announcing music that we make, to the community. I produce some stuff (see link below) nowadays but have been reluctant to post the "news" as I thought it would not really be on topic. Though it really is! I halfway solution might be to create a new mailinglist, linux-audio-music or whatever. Or should we use linux-audio-user ? Regards, Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] gtkmeter and threads?
söndagen den 31 oktober 2004 18.13 skrev Steve Harris: > On Sun, Oct 31, 2004 at 04:42:06 +, Dan Mills wrote: > > Hi all, > > I am working on a project that makes very heavy use of the gtkmeter code > > (borrowed from JAMIN), and seem to have a hard to track down problem > > > > I am using jack so there are a few threads involved and the meters are > > updated from a g_timeout_add timer callback, the update_meters function > > is protected by gdk_threads_enter/leave. The problem is that in spite of > > this I still sometimes get the GUI locking up. There are no locks shared > > between the GUI and the DSP code and when this happens the DSP continues > > to run just fine. > > > > I remember a CVS version of JAMIN used to do something similar? > > Yeah, it still does AFAIK. I never tracked it down, but didnt put too much > effort into it. > > It only happens if jack is not running in realtime mode. Hmmm, I get sporadic GUI lockups when Jack is running realtime. /Robert > > - Steve -- http://spamatica.se/music/
Re: [linux-audio-dev] Drum synth
lördagen den 18 september 2004 23.51 skrev Dmitry Baikov: > > > Hydrogen sounds like what you need: > > > http://hydrogen.sf.net/ > > > > not exactly, but is the best candidate i can think of for such a > > feature as being dicussed in this thread... i mean hydrogen could do > > quite well with some synthesis channels using the interface it has > > allready. > > As far as I understand... Hydrogen is sample-player + drum-sequencer. > Do we need a kitchen sink there? > > For me it would be better to have a separate drum-synth. So I can > drive it with seq24. As far as I know you can drive Hydrogen just fine from seq24. You don't have to use the internal sequencer unless you want to. If you really want to have a simple solution, dig out some drum soundfonts and load them into fluidsynth. > > > Comix what do you say? :) > > show us the modular API to hook sample channels in hydrogen! :)) > > > :) > > It's time to port Stomper...I suppose. That would be a nice project, yes. /Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] Announcing the Polypaudio sound server
Hi Lennart, On Wednesday 08 September 2004 14.42, Lennart Poettering wrote: > Hi! > > I am pleased to announce version 0.4 of the Polypaudio sound > server. See > > http://0pointer.de/lennart/projects/polypaudio/ > > for more information. > > I will try to push Polypaudio into both Gnome and KDE as replacement > for esound resp. aRts. I'm sorry but I think this is a dead mission. People has tried for years, and years, and years... to get this sorted out somehow. The latest I heard is that they finally are settling on gstreamer as a common backend. Stirring this up again might be in vain and possibly a bad idea. But please don't take my word for it, I'm not so well informed, do try and find out more about it. If gstreamer is not the saviour there is indeed a need for one. /Robert > I am interested in your comments on Polypaudio. > Please comment especially on the client APIs available on > > http://0pointer.de/lennart/projects/polypaudio/doxygen/ > > For a quick comparison with aRts/Esound see the FAQ: > > http://0pointer.de/lennart/projects/polypaudio/FAQ.html > > I am always interested in new devlopers: if you are interested feel > free to contact me! > > polypaudio is not a sound server for professional audio, it is a sound > server for desktop environments. Please keep that in mind when > grumbling about this software. > > Thanks for your time, >Lennart -- http://spamatica.se/music/
Re: [linux-audio-dev] OSC vs MIDI
> Getting off topic here, but there's a little more to it than that. 1 > Syntactic sugared implementation is much much more preferable to 101 > conventions for doing OOP with void pointers. > Things like typesafety, getting rid of macros in favour of inline > functions. The STL is another real reason to use C++ - the closest we have > to a standard for that sort of stuff. UML etc... There are a lot of very > practical reasons for using C++. Ahhh, I fear an outbreak of the unstoppable language zealot virus is imminent! Once it gets airborne nothing can stop it! Ahh, it's probably already to late... I can hear the sound of eager fingers tapping on keyboards... save yourselves!! ;-) /Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] Hello - FYI - intro
On Tuesday 24 August 2004 13.50, [EMAIL PROTECTED] wrote: > Thanks for your support and I will give Gentoo a shot.. > Hi Mark, I have to disagree with this advice. Though gentoo will give you immense insight into how things work and it's probably unparallelled performance I would not consider it an operating system for a beginners. I would, on similar grounds, also not recommend slackware... They are both very competitive on their own merits but this does not include ease of use/setup etc... I defintely think you should try a binary-only distibution. Fedora/Mandrake/Suse/Debian --- Some concluding remarks. This community, which I think works very well, is very much centered around these mailinglists, to get things working you are much more likely to succeed by asking here (though linux-audio-user would be more appropriate in this case) than to bang your head against the wall on your own. So... basically you are on the right track ;-). /Robert > If I have learnt anything by re-installing it is that the second+ time > around one starts getting selective and soon a lot of things don't > seem as important by the third time around. > > On 24 Aug 2004 at 12:17, [EMAIL PROTECTED] wrote: > > Don't give up just yet! > > > > On Tue, 24 Aug, 2004 at 12:38PM +0200, [EMAIL PROTECTED] spake thus: > > > energy - to drown people - to open portals of thought and > > > > Drown people? That's a Freedom that linux doesn't really give you. > > I mean in terms of surround sound with flavour and depth ?> > > > > > > > > My linux thought is that the main difference between linux and > > > windows is that under windows everything is packaged i.e. that one > > > installation will actually get that desired product to work - while > > > under linux a lot more time is spent on finding the correct patches > > > mixes matches reading than end time using/producing. Obviously linux > > > has flexibility power stability way beyond the confines of windows > > > or mac but it is the tieing up of those 'loose ends' which make it > > > easier for a new user to get going that make the ultimate > > > difference. While windows users have licence issues some linux users > > > have other. > > > > I know where you're coming from. As an experienced user, I have no > > problem with manually keeping a system udpated, patched ans running > > smoothly. Generally, I know where problems that occurr are likely to > > come from. The thing is, I don't want all that hassle. If I did, I'd > > use LFS. Instead, I use Gentoo. > > > > Gentoo isn't just for ricers. Personally, I find it has the nicest > > package management (although that's probably not the best way to > > describe it). I've also used Debian, but I still prefer Gentoo - > > mainly because it's a little more configurable (like USE flags and > > such) and it's a lot more up to date - Debian is safe, stable and > > tested to death, Gentoo has regular updates to all components, and > > still seems more stable than Debian Sid. > > > > Now, I recommend you give Gentoo a try. Sure, there'll be some pain - > > the install process consists of some instructions and a command prompt > > - but it's worth it. For a start, you know how your system is > > constructed to some degree. Secondly, installing stuff and keeping > > stuff updated is a doddle. To install Jack, I type "emerge > > jack-audio-connection-kit". When Jack gets updated, my system updates > > next time I do an "emerge world". Thirdly, the documentation is > > really nice and #gentoo on irc.freenode.net is a very helpful channel. > > > > Now, I know that other people will favour other distros. I know that > > Gentoo isn't for everybody. But I like gentoo, and I think you might, > > too. > > > > Give it a whirl. If you're reinstalling all the time anyway, why not > > try it out. > > > > Have fun. > > > > James > > > > > > > > -- > > "I'd crawl over an acre of 'Visual This++' and 'Integrated Development > > That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, > > Virginia Power) > > Be Well - Best wishes > Mark McBride > Cell 08 4414 6809 > > Tel.: +27 21 462 0044 > Fax: +27 21 465 0277 > > Bitwise Computer systems > EMail : [EMAIL PROTECTED] > EMail : [EMAIL PROTECTED] > > > > ___ >_ The information in this e-mail is confidential and is intended solely for > the addressee. Access to this e-mail by anyone else is unauthorised. If > you are not the intended recipient, any disclosure, copying, distribution > or any action taken or omitted in reliance on this, is prohibited and may > be unlawful. Whilst all reasonable steps are taken to ensure the accuracy > and integrity of information and data, and to preserve the confidentiality > thereof, no liability or responsibility whatsoever is accepted if > information or data is corrupted or does not reach its intended > destination. KFM Radio (Pty) Ltd. will not accept responsibili
Re: [linux-audio-dev] Re: [ladcca] lash directions
On Wednesday 04 August 2004 20.05, Steve Harris wrote: > On Wed, Aug 04, 2004 at 06:34:32 +0100, Bob Ham wrote: > > The properties that I had been working on have become gobjects and what > > was to be a new networking system is a seperate, gobject-based library > > to provide a high-level networking api (eg, session_scan(), > > session_join(), etc) > > > > The TLA OSC has been banded about quite a bit, and this is not out of > > the question; it would be in a set of usable lower-level protocols (or > > perhaps the set :) > > OSC is pretty neat, however it has a few features that make it not ideal > for LASH: Just throwing out ideas... What about this D-BUS thingy that seem to have a very good chance of becoming a widespread desktop ipc standard (with netwprk support)? It seems the next versions of both KDE and GNOME will utilize it atleast. /R -- http://spamatica.se/music/
[linux-audio-dev] [ANN] MusE 0.7.0 is out!
Hi everybody, It is finally here! The long awaited: # # ### ## ## ## ## # # # # # ## ## # # # # # # ## ## # # # # # # # ####### ## # # ## # ## ### ## # # # ## ## # [Introduction] A new stable release of MusE has finally seen the light of day. This release has been in development for over half a year and the list of changes is huge. This milestone release has internal as well as external redesigns resulting in much improved stability. MusE 0.7 has also improved usability as well as plenty new and improved features. [Overview] Muse is an integrated midi and audio sequencer with support for Alsa, Jack, LADSPA, internal and external softsynths and much more. All in all it is a complete music creation environment. See the MusE homepage: http://lmuse.sourceforge.net for a more comprehensive overview. [New and improved] This new version of MusE has a huge amount of changes, some highlights: * New look - MusE has a new look with both visual and usability improvements * Lots of performance improvements - Internal redesign leading to realtime performance greatly improved * Softsynths - MusE can now utilize win32 VST-Instruments natively - Internal synth interface redesigned for better performance * MusE is now always a Jack application - Interface to jack extended greatly - support for jack transport (both master and slave) - freewheeling mode for mixdown etc... * Audio functionality extended - Mixer merged with midi-mixer - Audio routing redesigned - New types of generic 'tracks' Input/Output/Aux/Group/etc * Automation - A new automation subsystem (first version) * Configuration and customization - lots of new customization options - shortcut editor * Editor improvements - drum editor improved with many shortcuts - arranger keyboard navigation and shortcuts [On the minus side] * Score editor is no longer available * Song format changed, no converter has been produced as of yet. * MusE can no longer be started 'stand alone', jack is always used. See http://lmuse.sourceforge.net/wiki/index.php/Features for a list of more bells and whistles. [Download] The source download is available at: http://sourceforge.net/projects/lmuse [Known issues] Have a look at the Errata at http://lmuse.sourceforge.net/wiki/index.php/Errata0.7 for a list of known issues with this release. [Many more changes] * do not save midi controller information in ~/.MusE file * Added message boxes when alsa and jack fails to initialize * added icons for drum-/listeditor in the arranger on rightclick * disabled midi mtc sync as its not implemented; disabled midi sync slave modes as they are currently not working * enabled sending midi clock * splitted removeTrack()/insertTrack() into three phases: pre realtime actions - realtime actions - post realtime actions; this allows to move memory allocations out of realtime task * changed undo/redo of tracks: synti instances are now really deleted on delete track * jack connection changes with qjackctrl are now recognized by MusE * applied patch from John Check to add a panic button to pianoroll editor * impl. "all notes off" for organ synti * disabled buttons for not implemented functions * added muse/wave/solo button in the trackinfo * enabled some midi sync code * dialogs for change of drummap when converting miditrack to drumtrack or changing port. * automatic trackchange in tracklist when selecting parts in arranger * added modify velocity to drumeditor + bugfix for modify velocity * fixed midi step recording * fixed bug in arranger: pressing enter after renaming part started editor * fixed --enable-rtcap configuration option * fix make MusE work on 64 bit architectures * added aux send for syntis * added info box which explains why when MusE gets kicked by Jack * added instrument definition for roland MC-505 * store a backup upon saving a new version of a song * transpose + grid patch added * added new config option: disable splash screen * fixed a crash when moving an event to tick positions < 0 * fixed: selecting a note in pianoroll editor and changing a value with note-info toolbar crashed MusE * added pianoroll velocity variation when clicking on virtual keyboard * hopefully a fix for drum in & outmap-issues in midi.cpp * FluidSynth: added support for drum patches * MusE now will not start if RTC is not available. * changed default st
Re: [linux-audio-dev] TiMidity as a CPU hog
Hi, On Friday 11 June 2004 11.26, Jens M Andreasen wrote: > Hi Dave, Takashi! > > I've got timidity up and running now, as a server under OSS. Made me > self a new option to read directly from /dev/sequencer2 (The > documentation says the input format should be similar to /dev/sequencer, > but that's wrong.) > > The first note I play actually happens, and resembles an acoustic piano > with a bit of wobbly reverb. So far so good ... > > The problem is that it stops rendering as soon as I release the note and > then only renders when there is new midi-input (as in massaging the > modulation wheel like a mad man ...). I have tried turning active > sensing ON on my keyboard to no avail. > > Then I started to look further into the sources in search for the actual > synthesizer. There is some 3MB of cross-platform C-code and headers, and > most of it is not what I'm looking for. > > So far I have only localized the soundfont loader and I am currently > reading up on the struct that defines the format. If I can find (or if > you can help me find?) the parts that actually assigns and renders a > note, then I should be able to write a new CPU-friendly voice-assigner > > The goal would be to pruduce something like a tmdt--. That is to say: > Timidity++ unbloated, a module which only includes the stuff needed to > run as a softsynth under Linux. > > So, where is the damned synthesizer? :) It's in there! ;-} Now, you might have already tried Fluidsynth, but I thought I would mention it for completeness. Fluidsynth is also a soundfont player which "might" be more aimed at realtime synth. It has it's own sets of problems though, none that really matter to me though, I think it's an excellent synth. /Robert ps. As for the CPU hogging, fluidsynth had a problem earlier when the reverb was enabled. When there was little or none signal into the reverb it went totally bonkers and consumed pretty much all cpu (a denormal problem I seem to remember). So the obvious question is, when timidity consumes all cpu, is the reverb enabled? ds. > > mvh // Jens M Andreasen > <...> -- http://spamatica.se/music/
Re: [linux-audio-dev] Knobs / widget design
On Thursday 10 June 2004 02.53, Tim Hockin wrote: > On Wed, Jun 09, 2004 at 08:39:15PM -0400, Dave Robillard wrote: > > But then you either have to click and drag up, click and drag up, click > > and drag up and so on because the motion is too slow, or you can't make > > no, I click and hold as long as I am tweaking a knob.. > > > fine adjustments. Unless someone can think of something clever that > > hasn't been though of before, you can't have both with faders. > > hold ctrl, and the movement becomes an order of magnitude finer-grained. > It works really well. > > :P In MusE I use the mouse wheel to edit both sliders and knobs. I find it to be superior to clicking and dragging. Sort of a poor mans control surface. Ctrl+wheel is used for more finegrained operation. /Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?
> > if i try out a new VST plug i open its GUI. with the GUI i get a nice > and compact look of all its controls. > If i want to use the plugin i resort to rebuilding the GUI with galan > controls (they have better functionality). > > its all there and its your choice. > but there are of course several vst plugins, where you need the GUI, > because the controls cant be mapped to knobs or sliders. Is there really? This would make automation impossible. /Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?
On Wednesday 09 June 2004 08.53, [EMAIL PROTECTED] wrote: > On Tue, Jun 08, 2004 at 07:53:43PM +0200, Frank Barknecht wrote: > > Hallo, > > Steve Harris hat gesagt: // Steve Harris wrote: > > > > > > What I meant with "nice" is more in the vein of this here: > > http://www.propellerheads.se/products/reason/img/closeup/redrum/closeup-r > >edrum450.jpg > > > > I mean, it looks like a nice piece of hardware, but what good is that > > on screen. You don't even know which button is more important that > > others. And why are there srews? And Reason gets especially terrible > > if you look at the moving cables on the back. Ah well, I could go on > > for hours on how terrible I think this is... ;) > > the moving cables are quite distracting. > but you can right click on every jack and connect it to another jack via > the menu. and you can see the connections in the menu too. > > reason also does a very good job at connecting everything for you. > this is of course only possible, because the reason building blocks are > really big. how should pd know how you wanted to have your objects > connected ? > > i consider the eyecandy RACK part of reason only for playing (fooling) > around with the effects. so that you get to know them. > > you can rightclick on every control, and add a control track to the > sequencer. > > and that is what makes reason a nice tool. the sequencer is integrated > with the rack part. > > imagine you got muse sequencing pd and you can add a control track to > muse with one mouse click on a pd control. (not to mention, that you can > record automation from pd to muses control track) Hey! That's a nice idea. Don't patent it ;) > > this is why i am still tempted to implement a full sequencer into galan > someday. But it would be much better to define some API to make this > possible in the UNIX way. That would be the way to go. I have to give this some thought... /Robert > if reason had a schematic behind the rack i would be quite happy with > it. (well should run under linux and be jackified :) -- http://spamatica.se/music/
Re: [linux-audio-dev] JACK/ALSA cannot set capture period lower than 512 with SBLive
måndagen den 7 juni 2004 23.02 skrev Lee Revell: > Hey, > > It seems to be a known issue that you cannot run JACK with the capture > period size lower than 512 with the SBLive ALSA driver. See this > thread: > > http://ccrma-mail.stanford.edu/pipermail/planetccrma/2003-December/003764.h >tml > > and this: > > http://www.music.columbia.edu/pipermail/linux-audio-user/2003-April/004040. >html > > The above threads seem to indicate that this is a hardware limitation. > However it seems to me more like a driver issue. Using the kX drivers > (on Windows, http://www.kxproject.com) with the exact same card, an old > SBLive Platinum, Ableton Live is usable with the record and playback > period sizes (set via ASIO driver config) at 64 samples (2.33 ms > latency) with nothing else running, and rock solid at 128 (~5 ms) in the > face of basically anything you throw at it. Of course it crashes, as > it's Windows, using an alpha quality third-party driver, but is quite > usable in a live music setting. 512x2 is not really usable for my > purposes. > > Is this assessment correct, and if so, can someone familiar with the > SBLive ALSA driver give me an idea as to how this could be fixed? Could > this be done via ALSA config files maybe? Your assessment is probably correct, I've brought up this issue a few times before. Fact is the ALSA driver for emu10k1 does not allow to set the capture buffer smaller than 512. Exactly why is still unknown, atleast to me. Unfortunately I don't think it can be solved with configuration. Talking to the kx people would probably be a good idea if you wish to dive deeper into this issue. The ALSA lists is another place to try. Regards, Robert > > Lee -- http://spamatica.se/music/
Re: [linux-audio-dev] Linux Live CD (Audio)
On Thursday 27 May 2004 15.46, Paul Davis wrote: > >Hi, > > > >forgive me if this question has been asked before: Is there something like > > a Linux Live CD optimized for and containing audio (editing) > > applications? Something like this > > > >http://www.frozentech.com/content/livecd.php > > > >where I can simply insert the CD, boot from it, and start working on my > > songs? > > where do you propose to store audio? If you are only doing MIDI, an usb keychain disk would be wonderful. /Robert -- http://spamatica.se/music/
Re: [linux-audio-dev] kernel 2.6.6 just out
Hi, <...> >> On my SuSE 9.0 system, this makes a *great* difference. > > Yes, I can attest to that too now. Many thanks for the various > tips - the lowest period size I can obtain now with jackstart and > --realtime in duplex with the SBLive is now 512 (which is OK) 512 is the smallest buffer size the emu10k1 driver will allow in duplex mode. The hardware can infact go much lower. I have no idea where this limitation is originating (well yes, it's in alsa, but I don't know how come). /Robert > and > it's pretty stable there. > > R
Re: [linux-audio-dev] kernel 2.6.6 just out
On Wednesday 12 May 2004 10.25, Jens M Andreasen wrote: > On mån, 2004-05-10 at 18:05, [EMAIL PROTECTED] wrote: > > Good question. I had already read that and was curious myself. Also, > > how about 2.6.6-mm1? I want to upgrade to Fedora Core 2 and a new kernel > > so I can quit pissing off Paul D. and the guys with my 2.96 gcc ;-) > > On a related question: I went to town today and saw that for ~15 euro I > can get a magazine with either Mandrake 10 (Community) or SuSE (Tech > Review) as a bonus CD. > > Both are kernel 2.6.x with ALSA "out of the box" (I believe?), but which > one should I choose? Okay, the fight is on! ;-) Being a long time user of Mandrake only, I can not vouch for the usability of Suse. I am however using Mandrake 10 in multiple installations right now so I thought I would comment. A point list of bad things: - For audio work the bundled 2.6 kernel is not good enough. - I also had problems with the the one that thac released (rpm.nyvalls.se) so I downgraded to kernel-multimedia-2.4.22.21mm.2mdk-1-1mdk, which works just fine. Now I see that thac has released new 2.6 kernels which maybe are better... I will try on a rainy day. - 10 is supposed to have very good usb support, which was not quite what I have experienced. It appears to be kernel problems though, when I downgraded the kernel my usb stuff started to work (keyboard and mouse, before you ask, YES I had a standard PS2 keyboard connected, my brainwaves was not strong enough to control it, though I tried.) The good things (more generic): - Mandrake tends (in my opinion) to favour freshness above stability. in my book this is only for the good, no stale packages, everything is up to date. - New packages appear swiftly and are freely available at a number of repositories, this is a real boon. - The config tools get better and better for each release, I don't recall having any problems with them in the current release (oh maybe with the printer now that I come to think of it) That is all, awaiting counter attack. ;) /Robert
[linux-audio-dev] kernel 2.6.6 just out
Hi, As a service to all readers, here's an excerpt of the Changelog concerning latency: ;) <[EMAIL PROTECTED]> [PATCH] Add mpage_writepages() scheduling point From: Jens Axboe <[EMAIL PROTECTED]> Takashi did some nice latency testing of the current kernel (with -mm writeback changes), and the biggest offender in general core is mpage_writepages(). <[EMAIL PROTECTED]> [PATCH] ia32: 4Kb stacks (and irqstacks) patch From: Arjan van de Ven <[EMAIL PROTECTED]> Below is a patch to enable 4Kb stacks for x86. The goal of this is to 1) Reduce footprint per thread so that systems can run many more threads (for the java people) 2) Reduce the pressure on the VM for order > 0 allocations. We see real life workloads (granted with 2.4 but the fundamental fragmentation issue isn't solved in 2.6 and isn't solvable in theory) where this can be a problem. In addition order > 0 allocations can make the VM "stutter" and give more latency due to having to do much much more work trying to defragment <[EMAIL PROTECTED]> [PATCH] reiserfs: scheduling latency improvements <[EMAIL PROTECTED]> [PATCH] unmap_vmas latency improvement unmap_vmas() will cause scheduling latency when tearing down really big vmas on !CONFIG_PREEMPT. That's a bit unkind to the non-preempt case, so let's do a cond_resched() after zapping 1024 pages. So... humbly asking, is it time yet to make the switch? :-) /Robert
Re: [linux-audio-dev] (web-based) interactive sound art?
On Tuesday 04 May 2004 12.41, Frank Barknecht wrote: > Hallo, > > Francois Dechelle hat gesagt: // Francois Dechelle wrote: > > Yep, I agree. What annoyes me in Pall Thayer's work > > (http://www.this.is/pallit/) that you mentionned in your previous mail > > is the fact that it relies on proprietary technologies (Java or Flash), > > which means that GNU/Linux users who do not want to use proprietary > > software will be excluded from it. > > And mp3-streaming... ;) Plus Flash is so slow on Linux. Do you happen > to have some pointers at hand at how to make good use of SVG for Web > based installations? Another interesting thing is the Blender game engine. In the latest Blender release the game engine was re-enabled (it was disabled since it relied on proprietary libraries, since then they where aparently opened up). It was a long time since I looked at this, but I remember there was a browser plugin for it. I don't know if the plugin has reemerged yet, I guess it will though. In any case, it seemed possible to do quite remarkable things with it. /Robert
Re: [linux-audio-dev] RFC: Disposable Soft Synth Interface
Hi, (cross posting to muse devel) On Thursday 29 April 2004 11.50, Tim Goetze wrote: > [Chris Cannam] > > >The header file is here: > > > > http://dssi.sourceforge.net/dssi.h.txt > > the header looks OK to me, reusing ALSA and LADSPA is a nice idea > indeed. however i'm a bit uneasy about the configure() method of the > plugin and its implications. a couple of points: I have not read the proposal, I really should.. just out of interest. Anyway, I see ALSA and LADSPA mentioned above and felt I should comment. The softsynth interface in MusE (MusE Experimental Software Synthesizer - M.E.S.S) used to have this layout but Werner recently changed it to a native format. I think (with emphasis on think, since I don't have the whole picture) that the reason was among others that this solution does not allow for faster than realtime execution. I think (once again, think) MESS has QT dependencies so it would probably not work as a neutral format but for interested people you can check it out here: http://cvs.sourceforge.net/viewcvs.py/lmuse/muse/synti/ Regards, Robert
Re: [linux-audio-dev] Re: FreeVSTi Compatibility List / VSTserver & FST
Great job Christian! Oh, now I want to try them myself :)!! /Robert On Wednesday 28 April 2004 12.53, Christian Frisson wrote: > Hi all, > > Dave Robillard wrote: > > What the heck is the point of it being "free" if you want to "have your > > word on all mods"? > > > > Sounds pretty un-free to me. > > Maybe should I've been more clear: I've no problems with the software I'll > release being free: like Pd patches, SynthEdit VSTi's, drivers... I just > wanna find a good way to protect my hardware works from people who already > have sales and legal strength that would make them proof from any file I > could suit against them! > > torbenh wrote: > > i have (by mistake) deleted my lad folder. and either you did not post > > your compatibility list, or i missed it. i cant tell. > > First reason matches. > I've posted it on the K-v-R forum: > http://www.kvr-vst.com/forum/viewtopic.php?t=42640 > > Because that's where i've found most of the plugins: > http://www.kvr-vst.com/get.php > > Alternatively, until the nodes change while I update my bookmarks, you can > browse all links to devs there: > http://theremin.free.fr/hunchback/index.php?nodes=|0|461|897|1098|1103| > > Let me quote one of the first answers to the thread: "The stuck notes in > some SE VSTi are most likely due to CK's Unison modules that are a little > twitchy." > > Have your copy saved on a text file, so that you can emulate a database > search. Ex: getting all interesting working plugins among all plugins > stored on a text file named "VSTi": > cat VSTi | grep ': W!' > > NB: > Do you want to practise your french? > http://fr.audiofanzine.com/apprendre/mailing_forums/index,idtopic,60705.htm >l > > > wait until after ladconf (paul and i will meet there -> synergy) > > Looking forward eagerly to receiving news from that meeting! > > Cheers, > Christian Frisson
Re: [linux-audio-dev] Anyone planned a GTK2-based Multitracker?
Hi again, revisiting an old thread. <...> > > It would be nice as you could see your entire piece from the main window, > > and see where things evolve, how control changes relate to each other, > > etc. > > > > The one (significantly more simple) feature I'd like to see in the MusE > > control editor is a line-drawing option like seq24. Just load up seq24, > > plug in a few notes and play with the control editor, you'll see what I > > mean. > > > > It would be nice to hilight all my kick drums, then draw a nice line to > > set all their velocities, for example. I found out that this infact is already possible in MusE, I'm not sure if it works as seq24 (have not come around to try it), but the feature is there. Highlight the kickdrum, draw a line, done. /Robert
Re: [linux-audio-dev] MuSE 0.9 codename "COTURNIX" - out now with documented API!
måndagen den 19 april 2004 07.03 skrev Juan Linietsky: > On Sunday 18 April 2004 08:19, jaromil wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > re all, > > > > i forward you here the announce as somebody could be interested also in > > exploring the doxyfied MuSE API, which is getting pretty stable now. > > > > see http://muse.dyne.org/codedoc > > > > ciao! > > Excellent! can you reconfigure shortcuts on this one? :) Juan, There is an unfortunate fact in that there are TWO muse projects, differing only in the use of capital letters. This one is MuSE (Multiple streaming engine) an internet streaming audio application. And there is MusE (linux Music sEquencer) the (lmuse.sourceforge.net). As I have a hard time imagine you'd configure shortcuts in a streaming engine I believe you are talking about the latter. ...for the record, it's possible to configure shortcuts in the current prerelease of MusE. Sorry for hijacking. /Robert > > cheers and congratulations on this release! > > reduz
Re: [linux-audio-dev] Audio over Ethernet?
Hi, On Wednesday 14 April 2004 09.47, Anders Torger wrote: > On Tuesday 13 April 2004 19.17, Anders Torger wrote: > > Is there any work done for transporting digital audio over ethernet? > > For example a library, an open standard or something? > > > > /Anders Torger > > Thanks for the replies. However, I should have specified in more detail > what I am after, I mean something like cobranet, but without the need > for special hardware. > > I'm thinking about trying to transfer digital audio over ethernet, with > the goal of being able to build a convolver cluster. The idea is to > have one computer with say a 24 channel sound card, and to that connect > a set of other computers through ethernet (100 megabit or gigabit > depending on requirements). > > The inputs taken from the sound card is broadcasted on the ethernet so > all other computers in the cluster get the inputs, and they send their > convolved outputs back to the sound card computer, whose only task is > to mix together the result, and put it to the sound card outputs. > > One application when this type of design would be suitable is WFS (Wave > Front Synthesis), with moving sources in simulated reverb, something > which is extremely demanding (one 3 GHz Pentium 4 can handle only one > source for a 24 channel system). > > Say if you build such a system with 10 cluster nodes plus the sound card > machine, you could render 10 dynamic WFS sources, but would have to > distribute 10 channels from the sound card machine, and get back 10 * > 24, which would be ~20 megabits/s broadcasted from the sound card > machine to the cluster nodes, and ~400 megabits/s back. One channel is > 48 kHz 32 bit floating point, that is ~1.5 megabit/s. > > Thus, I think it is necessary to implement something operating on the > ethernet level to get best performance in terms of throughput and > latency. I think Bob Ham (he's probably here somewhere) was some time ago working on an audio over ethernet layer. As I recall he was later convinced that firewire would be an easier, more reliable, solution. Now that firewire cards are quite cheap this might very well be true. I wonder if it's easy to connect this many nodes with firewire? /Robert
Re: MIDI-only sequencer, was Re: [linux-audio-dev] Linux soundapps pages updated
On Tuesday 13 April 2004 02.08, Joern Nettingsmeier wrote: > Jens M Andreasen wrote: > > Robert! > > > > Could you please repost in html table format? It is hard to follow your > > line of thought. At least to me it looks like all your columns are > > scrambled? > > for the record, html posts will be eaten by the spam filter. put the > tables on the web somewhere and post a link. For the record, the information was not mine, all credit go to Dave Phillips. But I html-ized it here: http://lmuse.sourceforge.net/wiki/index.php/Plans hopefully I got it more right than wrong, please report errors. (trying to make sense of it now I think it _must_ be wrong) I think I'd like a repost from the source ;) /Robert
Re: MIDI-only sequencer, was Re: [linux-audio-dev] Linux soundapps pages updated
måndagen den 12 april 2004 14.47 skrev Dave Phillips: > Greetings: > > I've run Master Tracks Pro under Xsteem, the MIDI I/O was fine. Ditto > for Sequencer Plus Gold under DOSemu. These programs are quite advanced > as MIDI-only sequencers, and I agree that much could be learned from > them. However, I get the impression that developers are responding to > users' requests for more audio-oriented features, so the more > interesting MIDI stuff is perhaps left for later addition. That's too > bad, but until a native Linux sequencer appears that includes the MIDI > features set of Sequencer Plus If you got the time, please do list the features you miss most. /Robert
Re: [linux-audio-dev] Anyone planned a GTK2-based Multitracker?
lördagen den 10 april 2004 18.53 skrev Dave Robillard: > On 04/10/04 04:22:49, Robert Jonsson wrote: > > Hi, <...> > > Oh, then I must ask what the feature should do more explicitly? To my > > ears the > > controller editor in MusE does exactly what you are asking for. > > Sorry, I wasn't really expecting discussion on that particular random > thought of the minute, so I didn't explain very well. :) > > I was referring to seeing control curves drawn over top of the tracks in > the master track window. Something like this screenshot of sonar (best I > could find): > > http://www.kvr-vst.com/i/b/sonar.jpg Ahh, you are right, this is not possible (yet) in MusE, it's been up for discussion though (I tend to refer to it as "automation" btw), I will add it to the TODO. > > It would be nice as you could see your entire piece from the main window, > and see where things evolve, how control changes relate to each other, etc. > > The one (significantly more simple) feature I'd like to see in the MusE > control editor is a line-drawing option like seq24. Just load up seq24, > plug in a few notes and play with the control editor, you'll see what I > mean. > > It would be nice to hilight all my kick drums, then draw a nice line to set > all their velocities, for example. Ok, I didn't try but I think I understand what you mean, this will probably come as a natural progression of the former feature . For what it's worth it's possible to use the Pen tool to draw curves atleast, if you got a stable hand you might be able to do pretty good lines to :) /Robert > > -Dave
Re: [linux-audio-dev] Anyone planned a GTK2-based Multitracker?
Hi, <...> > > > (Random thought) A MIDI sequencer where you can draw control curves > > > over the tracks (like ardour volume and whatnot) would be very cool.. > > > esp. for electronic music (like, say, trance) when the control > > > parameters are as important as the notes themselves > > > > Both MusE and Rosegarden support this. > > ... are you sure about MusE? I can't find any reference to such a thing, > or find said feature myself (I do use MusE, if not very heavily). (Yes, > MusE has a control editor of some sort of course, but that's not what I'm > talking about). Oh, then I must ask what the feature should do more explicitly? To my ears the controller editor in MusE does exactly what you are asking for. <...> /R
Re: [linux-audio-dev] LADSPA extension - Formal proposal.
Oh, here I go... On Wednesday 10 March 2004 16.21, Alfons Adriaensen wrote: > On Wed, Mar 10, 2004 at 03:59:18PM +0100, Robert Jonsson wrote: > > Richards decision would rely on the fact that LAD is in agreement, don't > > you think? > > Yes. But define 'LAD in agreement' (Robert) or 'what we agree on (Steve)'. In this case I would say that silence == no-vote. And that the guys debating must set their differences aside and find a solution. No spec is ever perfect, besides, this is mainly about open source, if the new spec won't fit the bill an uproar will occur and it will be revised to 1.2.1, the old spec will be swiftly passed on to neverneverland. I don't know enough about this so I'm definitely a yay sayer either way it goes. > > To me this means there is no formal approval procedure. This is an open community... formality isn't a strong point ;) > > Anyway this has beem debated for more than week, I've answered all > objections in some way or another and this has cost me an enormous amount > of time and energy, so unless some really new point is raised, I will now > shut up. My proposal stands as it is. I understand how you feel, lots of energy here during the last week. It's easy to have strong opinions about something you know a lot about... I've been there and done my part of argumentation in similar situations. As you probably know new revisions of ladspa has been up on the list before, I must say I find it a bit sad that none of these discussions seem to actually finalize into a new LADSPA revision. I really feel that you guys need to find some common ground, we need some progress. As they say in the military; faced with a situation, doing nothing is the worst thing you can do. Sorry for stepping on toes, but I'd hate for a good opportunity to fade away once again. Kind regards, Robert
Re: [linux-audio-dev] LADSPA extension - Formal proposal.
On Wednesday 10 March 2004 15.34, Alfons Adriaensen wrote: > On Wed, Mar 10, 2004 at 02:30:23PM +, Steve Harris wrote: > > On Wed, Mar 10, 2004 at 03:22:33 +0100, Alfons Adriaensen wrote: > > > On Wed, Mar 10, 2004 at 01:57:21PM +, Steve Harris wrote: > > > > There is a formal approval mecahnism, its whatever Richard will > > > > bless. He contacted me off-list: he is still around but hasnt been > > > > activily participating. I'l pass on whtaever we eventually agree on > > > > and he will either send it back with red ink on it or give it the OK. > > > > > > Well if that is the formal procedure, I submitted a *formal proposal*, > > > and it stands as it is. So now I will expect Richard to endorse it, or > > > reject it. > > > > It hasn't been agreed on yet. > > Iff the formal approval mechanism consists of Richard acception something > or not, as you stated, it doesn't need any ohter agreement. Richards decision would rely on the fact that LAD is in agreement, don't you think? /R
Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
On Wednesday 10 March 2004 12.05, Steve Harris wrote: > On Wed, Mar 10, 2004 at 09:36:42 +0100, Jens M Andreasen wrote: > > Uhmm .. So where do I find the midistream? > > You dont, LADSPA doesnt do MIDI. > If it's a softsynth you are making I think Jack would be the way to go. Then the synth could be a regular alsa-sequencer client. /Robert
[linux-audio-dev] Evolutionary Development, was: [ANN] First public release of Lindrum v 0.5.1
Hi, > I looked into hydrogen code. To learn. I looked into lot of little projects > code. Dead projects. To learn. And IMHO they're not useless. Maybe my > project will be dead at the end of the year. But then i made my experience > and still can join hydrogen or other projects. > I agree with you and I don't think that you, or anybody else spend their times badly if they start new projects, on the contrary, the more the merrier! :) The main requirement when you are about to create something is motivation. If you don't have that and start poking at something you will sooner or later run out of steam, unless you have an iron will. This might be the case if someone tells you which project project to start on, it'll work for a while, but then it's quite probable that you would lose interest. I've always argued that if you zoom out and look at Open Source development from a distance it is evolutionary. Apps appear and die away all the time, only the ones with good life force will continue to strive. This life force can be made of many things. For example: if the app interests a lot of people and they have found common ground in developing it together, or the app has a very stubborn lone developer that just won't give up. Both these kinds of apps will continue to live and possibly grow into something huge. Whereas some apps are started out of a need/interest but didn't attract any immediate attention and the developer lost interest, they will sooner or later die away. There is nothing wrong with that. This does also imply that open source development on a large scale is a rather slow process (not that any software development is fast), and we that are now participating in Linux Audio are working in (my opinion anyway) a very young development arena so diversity (or lack of direction if you will) is only natural at this instance in time. The more specialized projects that attract lots of developers _will_ come (there already exist a good bunch). Of course the analogy isn't perfect, (or we would have to wait millions of years :-D) with clever management we can increase the speed and skip a few iterations. Which is how I for instance would describe the success of Jack. My point is though that you can't force people into doing what they do not have any immediate interest in, their time is better spent making a larger base of developers overall, who knows, perhaps it's _their_ app that got it _right_. Not the possible predecessor. And even if their app fail, they would have learned something that they can later make use of, and the code would still be available as evidence that there once was a project in that vein. Even if the code in itself could not be reused it might serve as inspiration for others to start something. Sorry for being long winding, Robert
Re: [linux-audio-dev] Freeze?
torsdagen den 26 februari 2004 17.54 skrev Benjamin Flaming: > ... and Tinara is what I want ;) I want that too, are you a mind reader? :-o A bit more seriously, offline rendering in a tree graph works for 3d editing, and has worked for a number of years. I think it's a natural progression to try the same concepts on audio. In the end it might be that realtime resources (e.g. waiting times to get tracks rendered) are the limiting factor and then we've won nothing. But we won't know for sure until we test it. I for one will be watching closely. /Robert
Re: [linux-audio-dev] Freeze?
onsdagen den 25 februari 2004 23.00 skrev Paul Davis: > >> I still think about this from time to time and I would really like to > >> see a REAL implementation of the proposal. :-) > > ardour basically allows this already, although it is not > automatic. there is no way to know what the user wants, so we leave up > to the user to initiate "freezing" any particular track. you cannot > "freeze" a bus since it may receive input from outside of ardour. Yes, so I've heard, and that's really great. It was, however, the automatic merits that I wished mainly to explore. Freezing has it's merits, but it requires that you dedicate some brain cycles to deciding when and where you wish to freeze/unfreeze something. I could sure use those cycles for keeping creativity flowing. ... and I do think you can freeze a bus, but it requires that the app has full knowledge of the connection graph. Mmmm, I see a jack extension forming ;)) /Robert
Re: [linux-audio-dev] Freeze?
> > Me guesses you are referring to > this:[http://www.eca.cx/lad/2001/Nov/0310.html] message I posted back then. > > I'd have to say that they where probably not influenced by that Oh, skipping through the entire thread, the post by Nelson Posse Lago comes scaringly close to describing freeze. Kinda makes you wonder... /Robert
Re: [linux-audio-dev] Freeze?
On Wednesday 25 February 2004 20.25, Juhana Sadeharju wrote: > Hello. > > Recently Logic 6's Freeze feature was mentioned here, and Freeze > is mentioned in a new interview at Emagic's webpage: > > Q: Any other favorite feature in Logic 6, that you use most? > > Boris Blank [of Yello]: I think Freeze is ingenious. [ ... ] > > I'm wondering did Emagic borrow the idea from this list, as the > freeze feature was discussed here at november 2001. And soon after > that the feature stands in their software. Me guesses you are referring to this:[http://www.eca.cx/lad/2001/Nov/0310.html] message I posted back then. I'd have to say that they where probably not influenced by that, if they where their implementation would have been much more advanced and definitely cooler ;-P. Besides, the ideas might have been new for audio purposes but the technology in itself is not new. The ideas suggested where adaptations of similar features in the 3d-graphics world. Logic may very well have peeked that way too. I still think about this from time to time and I would really like to see a REAL implementation of the proposal. :-) /Robert
Re: [linux-audio-dev] Interesting MIDI project
lördagen den 21 februari 2004 00.47 skrev Fred Gleason: > On Thursday 19 February 2004 23:27, Erik de Castro Lopo wrote: > > http://www.nbb.cornell.edu/neurobio/land/STUDENTPROJ/2002to2003/lil2/ Speechless /R > > Now, who says fuzzy logic has no place in audio programming? > > > > Cheers! > > |-| > | Frederick F. Gleason, Jr. | Director of Broadcast Software Development | > | > | | Salem Radio Labs| > | > |-| > |The real problem with hunting elephants is carrying the decoys. | > | -- Anonymous| > |-|
[linux-audio-dev] ms-windows sources
Hilarious comment from slashdot about this debacle, there's a lot of truth there though, if you happen to come across it, don't touch it. /Robert > Gandalf: No! Don't ever use it! > > Frodo: How do we know it's source to the One OS of the Dark Lord? > > Gandalf tosses a CD-R into the burner, and burns > Windows.Source.Code.w2k.nt4.wxp.tar onto it. When the CD is done, there are > glowing fiery letters on it. > > Frodo : I can't read the fiery letters. > > Gandalf : There are few who can. The language is that of Redmond, which I > will not utter here. In the common tongue, it says "One OS To Rule Them > All, One OS To Find Them, One OS To Bring Them All And With The NDA Bind > Them" > > Frodo: Take the source code Gandalf! > > Gandalf : Noo! Do not tempt me with it! I dare not take it! Not even to > keep it safe! You must understand Frodo, that I would be tempted to use > this source code, for good. To disclose hidden API's, help the WINE > project. But through me, all of open source would be tainted, and the > LawyerWraiths of The Dark Lord will sure destroy us. > > Frodo : But it cannot stay here! > > Gandalf : No, no it can't. > > Frodo : What must I do? > > Gandalf : It must be sent to the fires of /dev/null, where it will be > undone, and we will be kept safe from the Lawyers of Evil. > > So remember folks, don't download it, or look at it, or attempt to build > it! It is evil, and answers only to the hand of The Dark One. > >
Re: [linux-audio-dev] DRI + Jack conflict?
On Tuesday 10 February 2004 14.07, Vincent Touquet wrote: > On Tue, Feb 10, 2004 at 01:45:49PM +0100, Robert Jonsson wrote: > >I'm running quite happily with DRI enabled on my ATI card now, the problem > > was definitely that it was trying to lock too much memory. > > Ok. I assume that you have a Firegl T2 with 128Mb Ram (using the ATI 3.7.0 > drivers) ? > > >Since shrinking the > >amount of vidmem that X utilizes I haven't run into this problem again > > (see other message for the actual remedy). > > Yep, I read that message. > I wasn't so sure if that was a complete solution though, as Paul talked > about faillure to lock memory for _various_ reasons :) I'm no expert at this, but my own findings support only that the problem is the amount of memory being locked, not the type of memory, neither that it happens to be the same memory we are locking. > So another solution would be to add more RAM to the machine you're working > on ? :) > That's my prefered solution, buy my way out of trouble ;-P. /Robert > best regards, > > Vincent
Re: [linux-audio-dev] DRI + Jack conflict?
On Tuesday 10 February 2004 13.32, Vincent Touquet wrote: > On Mon, Feb 09, 2004 at 07:32:35PM -0500, Paul Davis wrote: > >its a basic problem with real time software, the POSIX API etc. > >JACK tries to lock *all* the process memory. > > This is to ensure that nothing gets swapped out, right ? > Else it is very hard to ensure real time performance ? > (sorry for being somewhat ignorant in this matter). > > >POSIX doesn't offer any > >APIs that would allow us to lock only the parts we need locked without > >a lot of impossibly ugly, non-portable kludgery. > >the part that needs > >locking consists of any memory that will be touched by the code run in > >the JACK-managed "audio" thread. > >the implementation of DRI by certain video interface drivers means > >that we end up trying to lock the video memory as well, and this tends > >to fail for various reasons. > > Is this faillure due to the nature of the memory that we are trying to lock > ? Or is the problem that we try to lock the same part of memory multiple > times ? I'm running quite happily with DRI enabled on my ATI card now, the problem was definitely that it was trying to lock too much memory. Since shrinking the amount of vidmem that X utilizes I haven't run into this problem again (see other message for the actual remedy). /Robert > > >its not what to do about this. the most obvious answer is "don't try > >to run real-time software on systems with these video drivers > >installed". i know its not very satisfactory, but its all we have for > >now. > > Would the less obvious answer consist of one of the following ?: > - change the video drivers (at least the ones that are source based) > - do something at the API level, so we can lock selectively > > From what I can gather the optimal solution would be an API that > can give us what we want (only locking the memory that gets touched > by the audio thread and nothing else), but obviously this goes beyond > the scope of jack alone ? > > Would you consider implementing a work around (aka non portable kludgery) > a waste of time ? > > regards, > > v
Re: [linux-audio-dev] DRI + Jack conflict?
On Tuesday 10 February 2004 02.11, Paul Davis wrote: > >I guess I'll have to wait for the day when I can afford two > >multi-channel audio interfaces, two multi-channel MIDI interfaces, and a > >dedicated machine to handle the visualisation aspect of things. > > or ... you could just get a Matrox video interface, since they seem to > be just about the only company that understands the way that video h/w > interacts with audio and realtime issues. or maybe i should say the > only company that actually cares about it. they even had a booth a > NAMM ... I don't argue their concern, I'm sure they are nice people. But are you sure there is really a technical difference, I thought the mapping of the memory was done way above the driver? /Robert > > --p
Re: [linux-audio-dev] DRI + Jack conflict?
On Tuesday 10 February 2004 01.32, Paul Davis wrote: > >On Mon, 2004-02-09 at 18:50, Dave Griffiths wrote: > >> jack works with intel830 DRI > > > >Hmm.. I only have Radeon's, so I'm a bit out of luck as far as testing > >other cards I guess. > > > >Anyone else have a positive/negative experience? > > > >(For clarification, it's only realtime jack (ie jackstart -R) that > >doesn't work). > > its a basic problem with real time software, the POSIX API etc. > > JACK tries to lock *all* the process memory. POSIX doesn't offer any > APIs that would allow us to lock only the parts we need locked without > a lot of impossibly ugly, non-portable kludgery. the part that needs > locking consists of any memory that will be touched by the code run in > the JACK-managed "audio" thread. > > the implementation of DRI by certain video interface drivers means > that we end up trying to lock the video memory as well, and this tends > to fail for various reasons. > > its not what to do about this. the most obvious answer is "don't try > to run real-time software on systems with these video drivers > installed". i know its not very satisfactory, but its all we have for > now. > > --p There is one other option that helped me. I had this exact problem with my ATI card. 128mb memory and QT insisted that it should be mapped into it's memory space (infact it must be mapping it twice!) In usage this meant that QT apps on my machine had a memory footprint at 300+ MB. With my 512 MB memory I could seldomly lock more than one app strange would be otherwise ;). Now, I can't disable DRI since I wanted my TV-out to work so I looked for other solutions. I found an obvious one. Decrease the amount of memory that the X-server utilizes on the card. 128MB of graphic memory is __alot__, atleast I don't need that. I added the following to my XF86Config-4 in section "Device": VideoRam 32768 Apps still report to much memory (seeminly about twice the video memory, 64MB) but it's no longer a problem. /Robert
Re: [linux-audio-dev] Looking for SF2 file format description ?
On Thursday 05 February 2004 15.12, Dominic Genest wrote: > Hello, > > Where could I find specifications of SF2 file format ? Others have pointed to descriptions of the format. I thought I'd ask what do you want it for? Possibly what you are trying to do is already available with current projects. I'm mainly thinking of Swami and it's various extensions, e.g. libinstpatch. /Robert > > Thanks > > Dom
Re: MID vs MOD - WAS : Re: [linux-audio-dev] ".mid" files playing in Linux games
Hi, On Monday 02 February 2004 16.33, Dave Phillips wrote: > Dominic Genest wrote: > >I compare MIDI to the WYMIWYG (what you MEAN is what you get), and MOD or > >other formats alike to WYSIWYG (what you SEE is what you get). > > I would say instead that MODs are WYHIWYG (what you HEAR is what you > get), i.e., it *always* sounds the same because there's no dependency > upon an external synth and/or patch set. I think it was mentioned before, but I'd just like to take another swing at prerendering your soundtrack and encode it with OGG. This is commonly used by games today and especially if you distribute by CD a _very_ good approach. It will take more space then your average module or midi file. But it also is unprecedented in sound quality and authenticity. With OGG you'll probably get away with coding in 64kbps (ogg is variable bitrate so it might vary a bit) or lower I read somewhere about a guy experimenting with stereo recordings at 4kbps. This means you should be able to get a 10 minute soundtrack in 6 MB(64kbps)... If you are thinking of distributing on diskettes this might not be feasible ;) /Robert
Re: [linux-audio-dev] Re: [linux-audio-user] Re: Firewire, what's the story?
tisdagen den 09 december 2003 13.35 skrev Steve Harris: > On Tue, Dec 09, 2003 at 12:57:16 +0100, Robert Jonsson wrote: > > I googled a little last night, some people we all know popped up here and > > there (Hi Steve, Mark and Bob). > > There was a LAD message from 2001, someone who had been in contact with > > Yamaha and it seemed they(Yamaha) where working towards making mLan a > > part of the A&M standard (I think I got that right...not sure)... now... > > I'm not entirely sure what this means. It seemed as the A&M standards > > also cost a lot of money? > > There is a connection mangement mart of mLAN that is/was not included in > the IEEE specs. > > The A+M specs are available for free: > http://inanna.ecs.soton.ac.uk/~swh/mLAN/ Ah, nice. Though I found several other/newer specs at: http://www.1394ta.org/Technology/Specifications/specifications.htm as far as I can tell they cost money though... perhaps they don't add anything of interest. /Robert > > > Do we have enough information to implement mLan support? > > Everything but the connection management. I know thats inportant, but > I dont know how important. > > Theres also the issue that some of these firewire ADDA converters might > not use mLAN or A+M. In that case things may even e easier - assuming we > can get specs from the mantufacturer. > > > As I understand it, Bob Ham had/is working on implementing 61883 support > > for Jack, which seems like it's needed for mLan, a layer below it > > perhaps? How far has this come, is there something one can test somehow, > > what hardware do one need? > > He has partly working non-61883 audio over firewire support. I think its > quite 61883 flavoured though - so if/when its working it should be hard to > make it real 61883. > > - Steve
[linux-audio-dev] Re: [linux-audio-user] Re: Firewire, what's the story?
Hi, tisdagen den 09 december 2003 12.22 skrev Steve Harris: > On Tue, Dec 09, 2003 at 09:25:42AM +0100, Clemens Ladisch wrote: > > > > I seem to recall that it does, but that the packet size is smaller, > > > > making the latency problem easier to deal with. > > > > > > Isoch - 1394 has a timer operating on the bus. This timer happens > > > (roughly) every 125uS. > > > > USB isochronous transfers happen once per millisecond. > > OK, so its the difference between 44 or 45 samples per packet at 44.1kHz > (USB) and 5 or 6 (1394). > > So, a plausible jack period of 64 samples will be 11 or 12 1395 packets, > but always 125uS of jitter of course, (10 or 11 packets at 48k). > > I dont really have any idea how bad that is, its 8% of the availble time > slot for processing the 64 samples. > > You could lessen the effect of the jitter by having triple-buffering in > software, as in a 3x64 PCI soundcard - I dont know wether thats better > than just going to 128 samples or not. > > FWIW, for my needs I rarely go below 256 samples/period anyway, even > though my setup is capable of it, but I understand there are people who > really need very low latency. > > At 256 samples/period the jitter is only 2.1% of the time slice, which is > unlilkly to matter - cache temperature and so on has a far greater effect > than that. Though it is interesting debating the technical merits of firewire, for me, atleast, it would be far more interesting to get it actually working. I'm _very_ interested in utilizing these hardwares. I googled a little last night, some people we all know popped up here and there (Hi Steve, Mark and Bob). There was a LAD message from 2001, someone who had been in contact with Yamaha and it seemed they(Yamaha) where working towards making mLan a part of the A&M standard (I think I got that right...not sure)... now... I'm not entirely sure what this means. It seemed as the A&M standards also cost a lot of money? Do we have enough information to implement mLan support? As I understand it, Bob Ham had/is working on implementing 61883 support for Jack, which seems like it's needed for mLan, a layer below it perhaps? How far has this come, is there something one can test somehow, what hardware do one need? Regards, Robert ps. I'm cc:ing LAD as I'd like to move the discussion there. Remove LAU if you respond to this. ds.
Re: [linux-audio-dev] [OT] linux audio on PPCi
Hi, CK wrote: I read: I think this an urban myth, the Nvidia drivers may be proprietary but they are well functioning. I think this is a pretty rural comment, there is more than x86, where are the nvidia binaries for 2.6, and personally I really don't feel like loading a binary only module. These are also valid arguments but they have nothing to do with the stability and quality of the nvidia drivers which is what I intended to comment about. /Robert regards, x
Re: [linux-audio-dev] [OT] linux audio on PPCi
Hi, Sunday 30 November 2003 19.00 skrev Christian Schoenebeck: > Es geschah am Donnerstag, 27. November 2003 11:42 als > > [EMAIL PROTECTED] schrieb: > > I know some applications are not ported yet to ppc and suffer from > > x86-isms, but that should be fixable I guess :) > > It's not only orphaned asm lines but also endian dependent code that makes > a lot of trouble on non intel machines. It seems that lot of programs > suffer this problem, but there is one project that takes very care about > endian correctness, what was it name? Hmmm... ah, yeah it's called > LinuxSampler I think. ;P > > Anyway, whatever brand or type you'll choose, I recommend you that it has > an ATI graphics chip, so you don't have to install extra proprietary opengl > drivers for X like it's the case with Nvidia, I think this an urban myth, the Nvidia drivers may be proprietary but they are well functioning. Actually there are opensource drivers for nvidia chips, it is true though that only the proprietary drivers support OpenGL. The situation isn't much different with ATI, tbough there may be open source OpenGL enabled drivers, last time I checked it was a real pain to get them to work and they don't support all cards. (For the record I'm running ATI cards(7500 and 9200) these days but I don't have any problems using nvidia cards. None of which are on laptops though...) > it should have no shared > memory and a good display; I wouldn't take one with a resolution lower than > 1280x1024, I chose one with a resolution of 1600x1200. Regarding the sound > chip they're all more or less the same (anybody with another experience?). This is interesting, I guess you are running the chips with ac97 compatibility drivers? I've always thought ac97 cards where badly functioning, perhaps times have changed. Good to know. > Usually and surprisingly (at least to me) sufficient for low latency > output, but for quality you will buy an external sound device. And instead > of having the best, fastest, overkilling CPU I would better spend that > money in RAM (at least 512MB, better more). Fan noise, which is very much releated to the CPU power is also something to think about. Some laptops are noisy to the point that they are unusable for audio-work (or just about anything). /Robert > > Best regards > Christian
Re: [linux-audio-dev] Singing speech synthesis test with festival
Thursday 27 November 2003 07.24 skrev Juan Linietsky: > Well, I really wondered after that thread on speech synthesis > on how something done with festival would actually sound mixed up. > I this experiment in nearly half an hour, so dont think it's > something hard. I just wrote the voices in that xml-like syntax > festival uses for singing songs. Then I wrote a very > basic arrangement in cheesetracker, plus added > some effects and a bit of compressor to the voice. > > The result is actually better than what I was expecting, > though it's hard to keep festival in tempo. > > Here's the little thing I did: > > http://reduz.com.ar/songs/evilrobot.ogg > > Have fun! Great! I never was much of a kraftwerk fan, but I think I will be soon! mmm, Juan, what do you think about making a linux2.6-theme-contest contribution out of that :) perhaps changing the wording sliightly. ;) -- I HAVE to try this myselfhowever I'm going to find time to do so :-/ /Robert
Re: [linux-audio-dev] oh no ... virtual vocalists ...
Actually there was a demo. http://www.zero-g.co.uk/index.cfm?articleid=802 Sounds very convincing in my crappy headphones... /Robert Thursday 20 November 2003 09.14 skrev Robert Jonsson: > Thursday 20 November 2003 05.09 skrev Paul Davis: > > http://news.harmony-central.com/Newp/2003/Vocaloid.html > > Oh yeah! > > Oh nooo! > > Oh... what? > > Can they do that? > > Isn't there some law or something... probably murphys law... > > - > Will be very interesting to hear how a thing like that can "sound". Anybody > wanna bet it will be audible that it's not for real? > > /R
Re: [linux-audio-dev] oh no ... virtual vocalists ...
Thursday 20 November 2003 05.09 skrev Paul Davis: > http://news.harmony-central.com/Newp/2003/Vocaloid.html Oh yeah! Oh nooo! Oh... what? Can they do that? Isn't there some law or something... probably murphys law... - Will be very interesting to hear how a thing like that can "sound". Anybody wanna bet it will be audible that it's not for real? /R
Re: [linux-audio-dev] cute idea from the VST world ...
Thursday 20 November 2003 05.08 skrev Paul Davis: > http://www.fxfreeze.com/product.html Yeah. The idea that you could forget about "poliphony" is perhaps most important though ;). Actually, I've been thinking about similar things at several occasions, I even posted a message here in a similar (though more elaborate) vein a few years ago. http://www.eca.cx/lad/2001/Nov/0310.html I read sometime ago that Logic has a freeze feature built in nowdays also. /Robert
Re: [linux-audio-dev] and just to finalize ...
Tuesday 18 November 2003 15.22 skrev Paul Davis: > >I'd like to say: woohoo! > > i suppose that if i knew this was possible 2 years ago, i would never > have written JACK. that's the upside, perhaps. should JACK exist? is > the address space isolation worth it? big questions. > As others have also noted, adress isolation is god sent. Whatever you do, unless jack crashes, almost nothing can bring your application down (a mild overstatement perhaps *). This is a _major_ feature. I also think that jack apps should be easier to design and program as opposed to plugin-centric solutions. The boundaries are dictated by the operating system, not by the plugin-architecture. In my mind jack ought to have much better long-term viability than an in-proc plugin-system. Today you can probably wring out more precious clock cycles from an in-proc system since the overhead isn't as big. But in a few years (or already now!) the overhead for this is easily traded for the added benefits. /Robert * Jack does add a few critera of it's own, can you say ZOMBIE ? ;) But this is a necessity with an in-proc system also.
[linux-audio-dev] [RFC] Request For Contest - The Linux-2.6 theme song contest !
Hi Everybody, This mail is a direct consequence of the song Austin Acton posted recently. :) A nice little tune made with linux, about linux, that has been quite successful with very little advertisement. After a few brain rotations (before you ask, yes, I think by rotating my brain) I came to the conclusion that RIGHT NOW is a wonderful time to start a write_the_best_linux_song_contest! My reasoning is that linux-2.6 is just around the corner, people are hungry for any kind of linux related information, no matter how far fetched (I don't even think this is very far fetched). Making a little contest to choose THE linux-2.6-theme-song seems like a very good way to attract some easy publicity, the main thing we want to do is make people interested in (and aware of) audio production under linux. I'm confident that Slashdot (or any news site in the free software world for that matter) would gladly do a story on this event. BUT before we get to that, let's atleast produce some music ! :) Some criteria I thought would be applicable: - The song must be about linux in some way (about linux 2.6 seems the obvious choice). - The song must be (atleast) processed with a computer and that computer must run linux. - No computer running an operating system that is nonfree can be used in the production. (External synthesizers or similar stuff with advanced capabilties don't count as computers and can thus be used) - The song must be written by the artist (possibly used with permission). - The song would preferably contain some kind of voice track ( it might be hard to hear that it's about linux otherwise, and it would be nice to know how you people sound :-) - the better the audio quality the better, though I think there are other qualities of the recordings that count. - Some info about the applications/gear used should be included (atleast applications). - No prices, just free publicity for anybody that joins, and most publicity for those that reach the top in the event that we actually pull of a vote. We already got one song, Austins! I'm in the middle of producing a naive electronic piece myself (I mainly play the guitar) that I think will be applicable also. But... two songs don't make a contest... So, what do you say? Are we up to it? I'm calling all linux-artist wannabees, this is the time! I dare all developers that aren't on a deadline to take some time of from coding and also participate, bring out the artist in you! :) Wouldn't you just die to hear "The ballad of Alan Cox", or "Linus' Theme" or "The Bitkeeper Blues" :) (those are free btw if anyone gets any bright ideas ;) >From now til, say, December 14, one month, might be enough time to do something creative, yes? Let me know if there is any interest for this then I will try to formalize things a bit, website etc. Well don't just sit there, let's do it! :) /Robert
Re: [linux-audio-dev] Does NI run Traktor FS on Linux through Wine ?
Tuesday 04 November 2003 11.38 skrev Florian Schirmer: > Hi, > > > May I forward this to the german Keyboards magazine? Just kidding. ;) > > Don't feed the trolls ;-) Let's wait until we have something which is more > linux'ish to show... > Aha! This suggests there IS something more linuxish coming? :) /Robert
[linux-audio-dev] Performance utilities of the future.
Hi, This seems like an interesting article, describeing a new kernel service/application in 2.6. http://www-106.ibm.com/developerworks/library/l-oprof.html?ca=dnt-441 It's called OProfiler. "OProfile can help you identify issues such as loop unrolling, poor cache utilization, inefficient type conversion and redundant operations, branch mispredictions, and so on." Just thought I'd pass it on. /Robert
