From lazzaro at eecs.berkeley.edu Thu Dec 1 13:23:32 2005 From: lazzaro at eecs.berkeley.edu (lazzaro) Date: Thu Dec 1 13:21:24 2005 Subject: [linux-audio-dev] Re: [admin] attention gmail users [...] In-Reply-To: <200512011705.jB1H5Zsq012073@roar.music.columbia.edu> References: <200512011705.jB1H5Zsq012073@roar.music.columbia.edu> Message-ID: On Dec 1, 2005, at 9:05 AM, linux-audio-dev- request@music.columbia.edu wrote: > > it seems that gmail has an unfortunate default setting that some > people > are not aware of... gmail users, please fix your settings! To be specific, in Settings, choose the "use UTF-8" option for "Outgoing message encoding" on the General page. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- From dsbaikov at gmail.com Thu Dec 1 15:08:53 2005 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Thu Dec 1 15:08:57 2005 Subject: [linux-audio-dev] Re: [admin] attention gmail users [...] In-Reply-To: References: <200512011705.jB1H5Zsq012073@roar.music.columbia.edu> Message-ID: <70a871c80512011208l6e185605y1eadccfc60d2e3fd@mail.gmail.com> > To be specific, in Settings, choose the "use UTF-8" option for> "Outgoing message encoding" on the General page. Thank you. Best regards,Dmitry. From arnold.krille at gmail.com Tue Dec 6 05:51:59 2005 From: arnold.krille at gmail.com (Arnold Krille) Date: Tue Dec 6 05:52:04 2005 Subject: [linux-audio-dev] more on my tascam problem... Message-ID: <2def88b80512060251q9777f89v@mail.gmail.com> Hi all, some weeks ago I sent some mails ranting about problems getting my tascam us-122 to run on a turion64 running gentoo. As time has gone and new kernels arrived I have reached a state where I can play (synths, effects, ardour, etc) and "record" ie. sent the incoming audio to effects and back out. But: If I want to record to disk I get the same old error (should not be here with counts=0) again and sound stops completely. The computer freezes if I try to restart jackd... Some tests showed that this doesn't happen if I record into ram (using /dev/shm to save the recordings). I modified the driver to give some more debug and to not stop at the first error (see the attached usbusx2yaudio.c for details) but still after some more function-calls the driver stops working. Sadly there isn't much documentation in the source so I am a bit lost there. Can someone give my some hints? Thanks in advance, Arnold -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern k?nnte, w?rde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen. -------------- next part -------------- A non-text attachment was scrubbed... Name: messages.log Type: text/x-log Size: 1024 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051206/27d022da/messages-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: usbusx2yaudio.c Type: text/x-csrc Size: 30384 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051206/27d022da/usbusx2yaudio-0001.bin From rlrevell at joe-job.com Tue Dec 6 20:00:43 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Dec 6 19:59:59 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051102114858.013e1840@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102114858.013e1840@mango.fruits.de> Message-ID: <1133917243.15592.8.camel@mindpipe> On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote: > On Wed, 2 Nov 2005 11:05:34 +0100 > St?phane Letz wrote: > > > In Jackdmp we have tested 2 system for inter-process synchronization: > > fifo (the way it was done in regular jackd) and POSIX named semaphore > > (which are built on top of futex on recent system version) > > > > In both cases, each already running client get access to the > > synchronization primitive (fifo or POSIX named sema) defined by a new > > coming client. The synchronization primitive is "opened" once when a > > new client appears and is "closed" when the client quits. The > > synchronization primitive that has to be signaled then depends of the > > graph topology. > > > > > But ISTR that OSX only has named shared futexes (i.e. accessed > > > via a file descriptor), and then of course the problem remains. > > > > On OSX, on can use Mach semaphore (internal and non portable...) > > POSIX named semaphore or fifo. > > > > Stephane > > What results did you get? Did the semaphore perform better/worse than > the fifo? What about pthread condition variables with pshared flag set? > I read somewhere it should be implemented by now (at least on 2.6 > systems). I've tested process shared mutexes/CVs with NPTL 2.3.5 on Linux 2.6 and it works perfectly - I'm able to synchronize multiple processes via a mutex/CV residing in shared memory, backed by an mmap'ed file in /tmp. The performance is indistinguishable from the single multithreaded process case. Is there any good reason JACK could not use this rather than FIFOs? Lack of robustness? Lee From letz at grame.fr Wed Dec 7 03:30:28 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Wed Dec 7 03:31:27 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <1133917243.15592.8.camel@mindpipe> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102114858.013e1840@mango.fruits.de> <1133917243.15592.8.camel@mindpipe> Message-ID: <949CC7AA-5838-417E-8060-411D94F7F9A2@grame.fr> Le 7 d?c. 05 ? 02:00, Lee Revell a ?crit : > On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote: >> On Wed, 2 Nov 2005 11:05:34 +0100 >> St?phane Letz wrote: >> >>> In Jackdmp we have tested 2 system for inter-process >>> synchronization: >>> fifo (the way it was done in regular jackd) and POSIX named >>> semaphore >>> (which are built on top of futex on recent system version) >>> >>> In both cases, each already running client get access to the >>> synchronization primitive (fifo or POSIX named sema) defined by a >>> new >>> coming client. The synchronization primitive is "opened" once when a >>> new client appears and is "closed" when the client quits. The >>> synchronization primitive that has to be signaled then depends of >>> the >>> graph topology. >>> >>>> But ISTR that OSX only has named shared futexes (i.e. accessed >>>> via a file descriptor), and then of course the problem remains. >>> >>> On OSX, on can use Mach semaphore (internal and non portable...) >>> POSIX named semaphore or fifo. >>> >>> Stephane >> >> What results did you get? Did the semaphore perform better/worse than >> the fifo? What about pthread condition variables with pshared flag >> set? >> I read somewhere it should be implemented by now (at least on 2.6 >> systems). > > I've tested process shared mutexes/CVs with NPTL 2.3.5 on Linux 2.6 > and > it works perfectly - I'm able to synchronize multiple processes via a > mutex/CV residing in shared memory, backed by an mmap'ed file in /tmp. Do you have any test code you could share? > The performance is indistinguishable from the single multithreaded > process case. > > Is there any good reason JACK could not use this rather than FIFOs? > Lack of robustness? > jackd (of jackdmp in "synch" mode) where the server waits for all clients to finish in a given cycle require the used synchronization primitive to have a "wait with time-out" operation. Fifo can do that (using poll), Mach semaphore on OSX can do that, but POSIX named semaphore not. Do process shared mutexes/CVs have a "wait with time-out" operation.? Thanks Stephane From mista.tapas at gmx.net Wed Dec 7 06:12:49 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Wed Dec 7 06:13:00 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <949CC7AA-5838-417E-8060-411D94F7F9A2@grame.fr> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102114858.013e1840@mango.fruits.de> <1133917243.15592.8.camel@mindpipe> <949CC7AA-5838-417E-8060-411D94F7F9A2@grame.fr> Message-ID: <20051207121249.1bd1ee32@mango.fruits.de> On Wed, 7 Dec 2005 09:30:28 +0100 St?phane Letz wrote: > jackd (of jackdmp in "synch" mode) where the server waits for all > clients to finish in a given cycle require the used synchronization > primitive to have a "wait with time-out" operation. Fifo can do that > (using poll), Mach semaphore on OSX can do that, but POSIX named > semaphore not. > > Do process shared mutexes/CVs have a "wait with time-out" operation.? Well, there's int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex, const struct timespec *abstime); (from man "pthread_cond_wait") which probably works with a condition variable/mutex pair in shared memoryu, too. But i don't know anything about any timing guarantees. I suppose POSIX simply doesn't make any. Anyways, the precision of the timed wait is probably implementation dependent. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From rlrevell at joe-job.com Wed Dec 7 13:13:07 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Dec 7 13:12:12 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <949CC7AA-5838-417E-8060-411D94F7F9A2@grame.fr> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102114858.013e1840@mango.fruits.de> <1133917243.15592.8.camel@mindpipe> <949CC7AA-5838-417E-8060-411D94F7F9A2@grame.fr> Message-ID: <1133979187.17901.3.camel@mindpipe> On Wed, 2005-12-07 at 09:30 +0100, St?phane Letz wrote: > Le 7 d?c. 05 ? 02:00, Lee Revell a ?crit : > > > On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote: > >> On Wed, 2 Nov 2005 11:05:34 +0100 > >> St?phane Letz wrote: > >> > >>> In Jackdmp we have tested 2 system for inter-process > >>> synchronization: > >>> fifo (the way it was done in regular jackd) and POSIX named > >>> semaphore > >>> (which are built on top of futex on recent system version) > >>> > >>> In both cases, each already running client get access to the > >>> synchronization primitive (fifo or POSIX named sema) defined by a > >>> new > >>> coming client. The synchronization primitive is "opened" once when a > >>> new client appears and is "closed" when the client quits. The > >>> synchronization primitive that has to be signaled then depends of > >>> the > >>> graph topology. > >>> > >>>> But ISTR that OSX only has named shared futexes (i.e. accessed > >>>> via a file descriptor), and then of course the problem remains. > >>> > >>> On OSX, on can use Mach semaphore (internal and non portable...) > >>> POSIX named semaphore or fifo. > >>> > >>> Stephane > >> > >> What results did you get? Did the semaphore perform better/worse than > >> the fifo? What about pthread condition variables with pshared flag > >> set? > >> I read somewhere it should be implemented by now (at least on 2.6 > >> systems). > > > > I've tested process shared mutexes/CVs with NPTL 2.3.5 on Linux 2.6 > > and > > it works perfectly - I'm able to synchronize multiple processes via a > > mutex/CV residing in shared memory, backed by an mmap'ed file in /tmp. > > Do you have any test code you could share? > > Sorry I can't share the code as it belongs to my employer. But I based it on the "Interprocess Locking" example in this Solaris man page: http://www.scit.wlv.ac.uk/cgi-bin/mansec?3T+mutex_lock Lee From taybin at earthlink.net Wed Dec 7 20:36:19 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Wed Dec 7 20:36:38 2005 Subject: [linux-audio-dev] RELEASE jack-audio-connection-kit-0.100.7 Message-ID: <8D5CB56D-4DB2-4FD7-964A-638E268D790C@earthlink.net> Minor bug fixes since last release. Notable changes: * Attempt to let client timeout option work again on realtime mode * Let jackd quit gracefully when USB soundcard or power cable is unplugged * Better support for US428 USB soundcard * SSE/E3DNow mixing support. Disabled by default. Enable with -- enable-dynsimd JACK is available at http://jackit.sf.net and our new website http:// jackaudio.org. From jwoithe at physics.adelaide.edu.au Thu Dec 8 01:20:37 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Thu Dec 8 01:25:01 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required In-Reply-To: <1132944217.20390.25.camel@mindpipe> from "Lee Revell" at Nov 25, 2005 01:43:36 PM Message-ID: <200512080620.jB86Kbfr013996@sprite.physics.adelaide.edu.au> > On Fri, 2005-11-25 at 11:10 +1030, Jonathan Woithe wrote: > > I have since discovered (thanks to strace) that the problem lies in an > > mmap2() call which requests a size of around 8MB. It appears to be > > part of the NPTL pthread_create() function. The error returned by > > mmap2() (EAGAIN) indicates either a locked file or "too much locked > > memory" (according to the manpage). Because this is an anonymous map > > the problem must have been the latter. Increasing the "locked memory" > > limit from 20MB to 40MB made jackd start without having to resort to > > the LD_ASSUME_KERNEL hack. > > I stumbled across the same problem a few weeks ago working on another > project. This is glibc allocating an 8MB (!) stack for each thread. It > gets the default thread stack size from getrlimit(). With mlockall() > you will go OOM really fast like that. > > The real fix is for JACK to set a reasonable thread stack size in > jack_create_thread. You can work around the problem by appending this > line to /etc/security/limits.conf: > > * hard stack 512 > > for a 512KB stack. I tried this. Although this reduced the size of the mlock calls I found I still needed an mlock limit of at least 40MB for jack and ardour to start. However, even with this loading a large session into ardour failed to load with no error given (beyond the fact that the loading failed). You mentioned in another post that you're working on a "proper" fix for jack. I'll wait for this to be implemented before digging into this issue further since the correct fix might change things. Drop me a line when a fix has made it into CVS and I'll resume my testing. Regards jonathan From smithbone at gmail.com Thu Dec 8 10:18:14 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 10:18:17 2005 Subject: [linux-audio-dev] Replacement for my M-Audio Audiophile USB Message-ID: <8a0c36780512080718h3fd3bd14lcd9aa9f17e27d1b3@mail.gmail.com> After several frustrating weeks playing with my Audiophile USB I'mgoing to punt and get something else. For the archives: ALSA users interested in high-end capture should_not_ buy this device.(FWIW it sucks in windows too) - Its only a USB 1.1 device and 24bit 96k is half-duplex only.- Its (almost) S24_3BE so you have to use plughw or jackd has to bepatched to use it. I say almost because the few times I did get thecard to record something I had to reorder the byte data to get it notto sound like white noise.- As of ALSA 1.0.10 capture is broken. So I'm looking for a replacement. I bought this card because it had areally good recording specs (I just missed the half-duplex part) and Idont' need a pro-multi channel since all I'm tyring to do is recordLPs to CD. Can someone recommend a 24bit 96kHz full-duplex card that they thinkhas good enough recording specs for LP's that not going to cause me topull all my hair out trying to work with ALSA. --Richard A. Smith From idragosani at chapelperilous.net Thu Dec 8 10:27:59 2005 From: idragosani at chapelperilous.net (Brett McCoy) Date: Thu Dec 8 10:28:21 2005 Subject: [linux-audio-dev] Replacement for my M-Audio Audiophile USB In-Reply-To: <8a0c36780512080718h3fd3bd14lcd9aa9f17e27d1b3@mail.gmail.com> References: <8a0c36780512080718h3fd3bd14lcd9aa9f17e27d1b3@mail.gmail.com> Message-ID: <439850FF.9090709@chapelperilous.net> Richard Smith wrote: > After several frustrating weeks playing with my Audiophile USB > I'mgoing to punt and get something else. For the archives: ALSA > users interested in high-end capture should_not_ buy this > device.(FWIW it sucks in windows too) - Its only a USB 1.1 device and > 24bit 96k is half-duplex only.- Its (almost) S24_3BE so you have to > use plughw or jackd has to bepatched to use it. I say almost > because the few times I did get thecard to record something I had to > reorder the byte data to get it notto sound like white noise.- As of > ALSA 1.0.10 capture is broken. So I'm looking for a replacement. I > bought this card because it had areally good recording specs (I just > missed the half-duplex part) and Idont' need a pro-multi channel > since all I'm tyring to do is recordLPs to CD. Can someone recommend > a 24bit 96kHz full-duplex card that they thinkhas good enough > recording specs for LP's that not going to cause me topull all my > hair out trying to work with ALSA. --Richard A. Smith How about the M-Audio 2496 card? It's a PCI card, works right out of the box with ALSA and is reasonably priced ($99). And it's full duplex, zero-latency monitoring, digital I/O as well as analog RCA I/O -- Brett From tim at quitte.de Thu Dec 8 11:31:19 2005 From: tim at quitte.de (Tim Goetze) Date: Thu Dec 8 11:33:52 2005 Subject: [linux-audio-dev] 2.4.x patches? Message-ID: http://www.zip.com.au/~akpm/ (and schedlat.html below it) seems to have gone 404. Is anyone out there mirroring it? Thanks, Tim From rlrevell at joe-job.com Thu Dec 8 13:35:49 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 13:34:38 2005 Subject: [linux-audio-dev] 2.4.x patches? In-Reply-To: References: Message-ID: <1134066950.3919.7.camel@mindpipe> On Thu, 2005-12-08 at 17:31 +0100, Tim Goetze wrote: > http://www.zip.com.au/~akpm/ (and schedlat.html below it) seems to > have gone 404. > > Is anyone out there mirroring it? You seem to be stuck in 2001. Try a 2.6 kernel, it's great! Lee From rlrevell at joe-job.com Thu Dec 8 13:46:16 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 13:45:12 2005 Subject: [linux-audio-dev] Cross compiling the kernel Message-ID: <1134067577.3919.16.camel@mindpipe> Hello, All I am trying to do is compile an x86_64 kernel on i386 machine. It dos not work: $ ARCH=x86_64 make oldconfig $ ARCH=x86_64 make CHK include/linux/version.h SPLIT include/linux/autoconf.h -> include/config/* CC arch/x86_64/kernel/asm-offsets.s arch/x86_64/kernel/asm-offsets.c:1: error: code model 'kernel' not supported in the 32 bit mode make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1 make: *** [prepare0] Error 2 What gives? Do I need a different compiler to build for x86_64? Shouldn't this Just Work? Lee From kairuemmler at yahoo.de Thu Dec 8 14:48:32 2005 From: kairuemmler at yahoo.de (Kai Ruemmler) Date: Thu Dec 8 14:48:37 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134067577.3919.16.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> Message-ID: <20051208194832.GA9174@dings.kai> * Lee Revell wrote: > All I am trying to do is compile an x86_64 kernel on i386 machine. It > dos not work: > $ ARCH=x86_64 make oldconfig > > $ ARCH=x86_64 make [...] > What gives? Do I need a different compiler to build for x86_64? Yes. Cross compiling the kernel works like this: $ make ARCH= CROSS_COMPILE= The gcc cross compiler for x86_64 is usually named x86_64-linux-gcc. In the special case of x86 -> x86_64 a 64 bit enabled gcc is sufficient though (if your binutils support 64 bit). In all other cases you need a "real" cross compiler. Kai ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de From tim at quitte.de Thu Dec 8 14:56:14 2005 From: tim at quitte.de (Tim Goetze) Date: Thu Dec 8 14:58:34 2005 Subject: [linux-audio-dev] 2.4.x patches? In-Reply-To: <1134066950.3919.7.camel@mindpipe> References: <1134066950.3919.7.camel@mindpipe> Message-ID: [Lee Revell] >You seem to be stuck in 2001. Try a 2.6 kernel, it's great! OK, one more try later, 2.6.13-rt14 does it ... and it's great indeed! jackd does 64/44.1 without xrunning even while I switch to text mode and back to X. Quite impressive -- I think I'll be stuck in 2005 for the next few years. :) Thanks, Tim From rlrevell at joe-job.com Thu Dec 8 15:28:08 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 15:29:09 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <20051208194832.GA9174@dings.kai> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> Message-ID: <1134073689.5149.7.camel@mindpipe> On Thu, 2005-12-08 at 20:48 +0100, Kai Ruemmler wrote: > * Lee Revell wrote: > > All I am trying to do is compile an x86_64 kernel on i386 machine. It > > dos not work: > > > $ ARCH=x86_64 make oldconfig > > > > > $ ARCH=x86_64 make > > [...] > > > What gives? Do I need a different compiler to build for x86_64? > > Yes. > > Cross compiling the kernel works like this: > > $ make ARCH= CROSS_COMPILE= > > The gcc cross compiler for x86_64 is usually named x86_64-linux-gcc. > > In the special case of x86 -> x86_64 a 64 bit enabled gcc is sufficient > though (if your binutils support 64 bit). In all other cases you need > a "real" cross compiler. Can you tell me which Ubuntu/Debian packages to install to make this work? I did "apt-cache search | grep 64" and did not see any GCC or binutils packages. The closest thing I saw was lib64gcc1 which I'm installing now. Lee From rlrevell at joe-job.com Thu Dec 8 16:32:55 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 16:31:43 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <20051208194832.GA9174@dings.kai> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> Message-ID: <1134077576.6188.4.camel@mindpipe> On Thu, 2005-12-08 at 20:48 +0100, Kai Ruemmler wrote: > * Lee Revell wrote: > > All I am trying to do is compile an x86_64 kernel on i386 machine. It > > dos not work: > > > $ ARCH=x86_64 make oldconfig > > > > > $ ARCH=x86_64 make > > [...] > > > What gives? Do I need a different compiler to build for x86_64? > > Yes. > > Cross compiling the kernel works like this: > > $ make ARCH= CROSS_COMPILE= > > The gcc cross compiler for x86_64 is usually named x86_64-linux-gcc. > > In the special case of x86 -> x86_64 a 64 bit enabled gcc is sufficient > though (if your binutils support 64 bit). In all other cases you need > a "real" cross compiler. > Does not work. I installed binutils-multiarch and lib64gcc1 but I still get the exact same error: $ make ARCH=x86_64 CROSS_COMPILE=x86_64-linux- make: x86_64-linux-gcc: Command not found CHK include/linux/version.h CC arch/x86_64/kernel/asm-offsets.s /bin/sh: x86_64-linux-gcc: command not found make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 127 make: *** [prepare0] Error 2 There does not seem to be any x86_64-linux-gcc package at all for Ubuntu. If I omit CROSS_COMPILE I get the same error as before: $ make ARCH=x86_64 CHK include/linux/version.h CC arch/x86_64/kernel/asm-offsets.s arch/x86_64/kernel/asm-offsets.c:1: error: code model 'kernel' not supported in the 32 bit mode make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1 make: *** [prepare0] Error 2 Why does GCC insist on running in "the 32 bit mode" even though I told it ARCH is x86-64? Why doesn't this Just Work, is Ubuntu really such a piece of shit that there's no easy way to do it? Lee From smithbone at gmail.com Thu Dec 8 16:42:27 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 16:42:30 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134077576.6188.4.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> Message-ID: <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> > Why does GCC insist on running in "the 32 bit mode" even though I told> it ARCH is x86-64?>> Why doesn't this Just Work, is Ubuntu really such a piece of shit that> there's no easy way to do it? My experince with all the embedded processors I deal with is thatcross compiling almost never "just works". You might try gettingcrosstool and building a 64bit toolchain. That will take a hour or 2though. Unless you have a screaming machine. --Richard A. Smith From smithbone at gmail.com Thu Dec 8 16:54:05 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 16:54:09 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> Message-ID: <8a0c36780512081354l2cac8b11pd88571a301c2e28b@mail.gmail.com> > cross compiling almost never "just works". You might try getting> crosstool and building a 64bit toolchain. That will take a hour or 2 Or perhaps try booting the Kanotix64 livecd and compile under that? --Richard A. Smith From rlrevell at joe-job.com Thu Dec 8 16:57:23 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 16:56:11 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> Message-ID: <1134079044.6188.12.camel@mindpipe> On Thu, 2005-12-08 at 15:42 -0600, Richard Smith wrote: > > Why does GCC insist on running in "the 32 bit mode" even though I told> it ARCH is x86-64?>> Why doesn't this Just Work, is Ubuntu really such a piece of shit that> there's no easy way to do it? > My experince with all the embedded processors I deal with is thatcross compiling almost never "just works". You might try gettingcrosstool and building a 64bit toolchain. That will take a hour or 2though. Unless you have a screaming machine. > --Richard A. Smith > Ugh, there's no way to do this by just installing packages? x86-64 isn't some bizarre embedded arch, it must be the #1 or #2 selling PC processor today. I can't believe there's no easy way to do it. This is bullshit. Lee From rlrevell at joe-job.com Thu Dec 8 17:05:30 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 17:04:16 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> Message-ID: <1134079530.6188.17.camel@mindpipe> On Thu, 2005-12-08 at 15:42 -0600, Richard Smith wrote: > > Why does GCC insist on running in "the 32 bit mode" even though I told> it ARCH is x86-64?>> Why doesn't this Just Work, is Ubuntu really such a piece of shit that> there's no easy way to do it? > My experince with all the embedded processors I deal with is thatcross compiling almost never "just works". You might try gettingcrosstool and building a 64bit toolchain. That will take a hour or 2though. Unless you have a screaming machine. > --Richard A. Smith > OK, brilliant. Apparently the only way to do this is to install the "toolchain-source" package and, yep, BUILD A TOOLCHAIN FROM SOURCE. http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation Christ, I cannot believe what a pain in the ass this is. At this rate it will have taken me 2 days to get this working. Lee From smithbone at gmail.com Thu Dec 8 17:13:23 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 17:13:26 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134079044.6188.12.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079044.6188.12.camel@mindpipe> Message-ID: <8a0c36780512081413j70c17d67kef3e125fd31e330c@mail.gmail.com> > Ugh, there's no way to do this by just installing packages? x86-64> isn't some bizarre embedded arch, it must be the #1 or #2 selling PC> processor today. I can't believe there's no easy way to do it. This is> bullshit. Google seems to suggest that 32->64 is a compile option. http://lists.freebsd.org/pipermail/freebsd-amd64/2004-November/002681.htmlIts for BSD but still gcc. Here's something that says there is a kernel-image-amd64 package thatcross compiles. http://lists.debian.org/debian-amd64/2005/02/msg00059.html --Richard A. Smith From smithbone at gmail.com Thu Dec 8 17:17:07 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 17:17:10 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134079530.6188.17.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> Message-ID: <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> >> OK, brilliant. Apparently the only way to do this is to install the> "toolchain-source" package and, yep, BUILD A TOOLCHAIN FROM SOURCE.>> http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation>> Christ, I cannot believe what a pain in the ass this is. At this rate> it will have taken me 2 days to get this working. Yep. thats about par for the course. Perhaps if you ask on thedebian-amd64 some kind soul has unofficial packages you can use. --Richard A. Smith From rlrevell at joe-job.com Thu Dec 8 17:17:37 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 17:19:49 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081354l2cac8b11pd88571a301c2e28b@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <8a0c36780512081354l2cac8b11pd88571a301c2e28b@mail.gmail.com> Message-ID: <1134080257.6188.24.camel@mindpipe> On Thu, 2005-12-08 at 15:54 -0600, Richard Smith wrote: > > cross compiling almost never "just works". You might try getting> crosstool and building a 64bit toolchain. That will take a hour or 2 > Or perhaps try booting the Kanotix64 livecd and compile under that? I don't have a 64 bit machine - that's the whole problem. I am trying to reproduce a problem an x86_64 user at a remote location is having. I have their kernel sources and .config. I expected to be able to install a gcc-x86_64 package and be done with it. Apparently I was wrong, and this is going to be a nightmare to get working. Grr. Lee From smithbone at gmail.com Thu Dec 8 17:20:10 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 17:20:13 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> Message-ID: <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> > > Christ, I cannot believe what a pain in the ass this is. At this rate> > it will have taken me 2 days to get this working.>> Yep. thats about par for the course. Perhaps if you ask on the> debian-amd64 some kind soul has unofficial packages you can use.> Try here: http://debian.speedblue.org/ --Richard A. Smith From rlrevell at joe-job.com Thu Dec 8 17:13:19 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 17:20:40 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081354l2cac8b11pd88571a301c2e28b@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <8a0c36780512081354l2cac8b11pd88571a301c2e28b@mail.gmail.com> Message-ID: <1134080000.6188.18.camel@mindpipe> On Thu, 2005-12-08 at 15:54 -0600, Richard Smith wrote: > > cross compiling almost never "just works". You might try getting> crosstool and building a 64bit toolchain. That will take a hour or 2 > Or perhaps try booting the Kanotix64 livecd and compile under that? Would take weeks to download. Lee From rlrevell at joe-job.com Thu Dec 8 17:38:10 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 17:36:56 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081413j70c17d67kef3e125fd31e330c@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079044.6188.12.camel@mindpipe> <8a0c36780512081413j70c17d67kef3e125fd31e330c@mail.gmail.com> Message-ID: <1134081491.6188.27.camel@mindpipe> On Thu, 2005-12-08 at 16:13 -0600, Richard Smith wrote: > > Ugh, there's no way to do this by just installing packages? x86-64> isn't some bizarre embedded arch, it must be the #1 or #2 selling PC> processor today. I can't believe there's no easy way to do it. This is> bullshit. > Google seems to suggest that 32->64 is a compile option. > http://lists.freebsd.org/pipermail/freebsd-amd64/2004-November/002681.htmlIts for BSD but still gcc. > Here's something that says there is a kernel-image-amd64 package thatcross compiles. > http://lists.debian.org/debian-amd64/2005/02/msg00059.html > Ubuntu does not have a kernel-image-amd64 and all combinations of -m64 and -mcpu=x86-64 in CFLAGS produce the same error. It is as if the Ubuntu gcc (in fact all of Ubuntu) simply has no support at all for x86-64. Lee From rlrevell at joe-job.com Thu Dec 8 17:40:34 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 17:39:20 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> Message-ID: <1134081634.6188.29.camel@mindpipe> On Thu, 2005-12-08 at 16:20 -0600, Richard Smith wrote: > > > Christ, I cannot believe what a pain in the ass this is. At this rate> > it will have taken me 2 days to get this working.>> Yep. thats about par for the course. Perhaps if you ask on the> debian-amd64 some kind soul has unofficial packages you can use.> > Try here: > http://debian.speedblue.org/ > Thanks. Apparenly Ubuntu/Debian do not support any cross compiling whatsoever OOTB. The only explanation I can think of is that they want to keep the install small. Lee From smithbone at gmail.com Thu Dec 8 17:48:23 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 17:48:26 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134081634.6188.29.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> <1134081634.6188.29.camel@mindpipe> Message-ID: <8a0c36780512081448v51387af3t378fd3e9047f98cd@mail.gmail.com> >> Thanks. Apparenly Ubuntu/Debian do not support any cross compiling> whatsoever OOTB. The only explanation I can think of is that they want> to keep the install small. Welcome. Like you said its only us bizzare embeded dudes that really use thatstuff. So its not worth the trouble. Especially when you can just geta live CD to bootstrap when you actuall have 64bit hardware. BTW. I found that using 'apt-get.org'. It's really helpful for stuff like that. --Richard A. Smith From Dr.Graef at t-online.de Thu Dec 8 18:03:31 2005 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu Dec 8 18:01:17 2005 Subject: [linux-audio-dev] ANN: "Modern Computer Music and DSP Programming Tools" Workshop in Mainz/Germany Message-ID: <4398BBC3.6050202@t-online.de> Dear LAD'ers, our Department of Music-Informatics at the Johannes Gutenberg University of Mainz is organizing a little workshop with introductory courses on Faust, SuperCollider and Q by Yann Orlarey (Grame, Lyon), Stefan Kersten (TU Berlin) and me. The workshop is sponsored by the "Interdisciplinary Working Group of Music and Arts Informatics" of the Johannes Gutenberg University, so it's free, and takes place at the Institute of Musicology (Philosophicum, Jakob-Welder-Weg 18 on the campus) on Tuesday, Dec 20th 2005, from 14:00 h to 18:00 h. If you'd like to participate, then please *please* register (just mail me at Dr.Graef@t-online.de or my secretary, Mrs. Felicitas Volke, at volke@uni-mainz.de). Registration is free but mandatory, as we can only accommodate a limited number of participants. If you register, please also indicate whether you can bring your own laptop, as the Linux PC and MIDI equipment available for the workshop is even more restricted than the amount of available chairs, coffee and Christmas cookies. ;-) More information can be found in the attached text file. Information on how to find us on the campus is available at http://www.uni-mainz.de/zentral/75.php. You can also contact me at Dr.Graef@t-online.de if you have any further questions. Please feel free to pass this around to your friends, colleagues and other mailing lists as you see fit. Cheers, Albert Graef -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag -------------- next part -------------- Workshop Modern Computer Music and DSP Programming Tools Location: Johannes Gutenberg-Universit??t Mainz, Philosophicum, Jakob-Welder-Weg 18, Alter Fakult??tssaal (Room P 01-185) Date: Tuesday, Dec 20th 2005, from 14:00 h to 18:00 h Workshop language: English The number of participants is limited, (free) registration is required. Registration: Tel.: +49 (0)6131 3925142, Email: volke@uni-mainz.de Programme: 14:00 h Albert Gr??f (University of Mainz): Functional Multimedia Programming with Q 15:00 h Yann Orlarey (Grame): FAUST Coffee Break 16:00 h Stefan Kersten (Technical University of Berlin): SuperCollider 18:00 h End 14:00 h Albert Gr??f: Functional Multimedia Programming with Q This presentation gives a hands-on introduction to the equational programming language "Q", and some of its facilities for multimedia programming. Q can best be described as a kind of modern-style "functional scripting language." Q's multimedia library comprises interfaces to Grame's MidiShare and Faust, as well as an OSC-based SuperCollider interface, and thus provides the necessary tools to create advanced computer music applications in the context of a very-high-level, non-imperative programming language. Albert Gr??f is head of the Dept. of Music-Informatics at the Institute of Musicology of the Johannes Gutenberg University Mainz. His research interests include the mathematical theory of music and advanced functional programming tools for computer music and other real-time multimedia applications. 15:00 h Yann Orlarey: FAUST FAUST (Functional AUdio STreams) is a programming language for real-time signal processing and synthesis that targets sample-level high-performance signal processing applications and audio plugins. FAUST proposes an innovative approach to signal processing that combines two programming models: functional programming and block diagram composition, in a highly structured textual syntax that can be compiled into efficient C/C++ code. The presentation will give an overview of the main features of the language and its compiler through several simple and practical examples. Composer and researcher in computer music, Yann Orlarey is currently the Scientific Director of Grame - Centre National de Cr??ation Musicale in France. His main research interests are music programming languages, with a particular focus on lambda-calculus and functional programming, and real-time distributed systems. He is the author and co-author of various musical softwares and systems including MidiShare. 16:00 h Stefan Kersten: SuperCollider SuperCollider is a real-time synthesis engine and object oriented composition language. This course introduces the architecture and the working environment on OSX and Linux and provides an introduction to basic synthesis techniques and sequencing strategies. Stefan Kersten (*1978) is currently studying communication and computer science at the Technical University of Berlin. He has ported SuperCollider to Linux and is the author of SCUM, SuperCollider's GUI module for Linux. He uses SuperCollider for most of his projects in research and music. From rlrevell at joe-job.com Thu Dec 8 18:16:31 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 18:17:45 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> Message-ID: <1134083791.6188.36.camel@mindpipe> On Thu, 2005-12-08 at 16:20 -0600, Richard Smith wrote: > > > Christ, I cannot believe what a pain in the ass this is. At this rate> > it will have taken me 2 days to get this working.>> Yep. thats about par for the course. Perhaps if you ask on the> debian-amd64 some kind soul has unofficial packages you can use.> > Try here: > http://debian.speedblue.org/ > Thanks, it looks like this will work. Unfortunately gcc-4.0-x86-64 + deps are an 80MB download but I guess that's better than nothing. I'm still disgusted at having to use third party .debs to accomplish something so utterly trivial. FWIW I tried -m64 as described in one of the other links you sent and got these errors. I wonder if this is why so many x86-64 users use Gentoo despite its apparent complexity: because the 64 bit support in other distros is shit. $ make CFLAGS="-m64 -mcpu=x86-64" ARCH=x86_64 CHK include/linux/version.h CC arch/x86_64/kernel/asm-offsets.s In file included from include/asm/system.h:5, from include/asm/processor.h:18, from include/asm/thread_info.h:17, from include/linux/thread_info.h:21, from include/linux/spinlock.h:53, from include/linux/capability.h:45, from include/linux/sched.h:7, from arch/x86_64/kernel/asm-offsets.c:7: include/linux/kernel.h:105: warning: conflicting types for built-in function 'snprintf' include/linux/kernel.h:107: warning: conflicting types for built-in function 'vsnprintf' In file included from include/linux/bitmap.h:8, from include/linux/cpumask.h:82, from include/linux/sched.h:15, from arch/x86_64/kernel/asm-offsets.c:7: include/linux/string.h:18: warning: conflicting types for built-in function 'strspn' include/linux/string.h:19: warning: conflicting types for built-in function 'strcspn' etc Lee From smithbone at gmail.com Thu Dec 8 18:50:10 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 18:50:13 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134083791.6188.36.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> <1134083791.6188.36.camel@mindpipe> Message-ID: <8a0c36780512081550l202ef4bdk265cea668d7c0970@mail.gmail.com> > Thanks, it looks like this will work. Unfortunately gcc-4.0-x86-64 +> deps are an 80MB download but I guess that's better than nothing. I'm> still disgusted at having to use third party .debs to accomplish> something so utterly trivial. This is kinda getting OT. But why do you think its "utterly trivial?" Also I found this on the Debian AMD64 page ---Minimalistic AMD64 runtime support for i386 The official i386 distribution actually includes minimalistic AMD64support, consisting of a 64bit kernel, gcc-3.4 able to create 64bitbinaries and the amd64-libs package to run third-party amd64 binarieswith native shared libraries.--- So somebody thinks Debian proper can do this. Try installing thegcc-3.4 package and see if it works. --Richard A. Smith From rlrevell at joe-job.com Thu Dec 8 19:05:46 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 19:09:22 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134083791.6188.36.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> <1134083791.6188.36.camel@mindpipe> Message-ID: <1134086747.6188.54.camel@mindpipe> (I apologise if anyone finds this thread OT, it is relevant to Linux audio development and the kernel people don't want to hear about toolchain problems) On Thu, 2005-12-08 at 18:16 -0500, Lee Revell wrote: > On Thu, 2005-12-08 at 16:20 -0600, Richard Smith wrote: > > > > Christ, I cannot believe what a pain in the ass this is. At this rate > > > > it will have taken me 2 days to get this working. > > > Yep. thats about par for the course. Perhaps if you ask on the > > > debian-amd64 some kind soul has unofficial packages you can use. > > > > Try here: > > http://debian.speedblue.org/ > > > > Thanks, it looks like this will work. Unfortunately gcc-4.0-x86-64 + > deps are an 80MB download but I guess that's better than nothing. I'm > still disgusted at having to use third party .debs to accomplish > something so utterly trivial. > > FWIW I tried -m64 as described in one of the other links you sent and > got these errors. Hmm, now I am getting somwhere. I had failed to run "make mrproper" so include/asm was still symlinked to include/asm-i386. After fixing that, I got a bit farther. LD usr/built-in.o ld: warning: i386 architecture of input file `usr/initramfs_data.o' is incompatible with i386:x86-64 output This one is worrisome, maybe I also need to pass LDFLAGS? CC arch/x86_64/kernel/process.o CC arch/x86_64/kernel/signal.o AS arch/x86_64/kernel/entry.o arch/x86_64/kernel/entry.S: Assembler messages: arch/x86_64/kernel/entry.S:204: Error: cannot represent relocation type BFD_RELOC_X86_64_32S arch/x86_64/kernel/entry.S:275: Error: cannot represent relocation type BFD_RELOC_X86_64_32S arch/x86_64/kernel/entry.S:762: Error: cannot represent relocation type BFD_RELOC_X86_64_32S arch/x86_64/kernel/entry.S:815: Error: cannot represent relocation type BFD_RELOC_X86_64_32S arch/x86_64/kernel/entry.S:536: Error: cannot represent relocation type BFD_RELOC_64 arch/x86_64/kernel/entry.S:536: Error: cannot represent relocation type BFD_RELOC_64 arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64 arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64 make[1]: *** [arch/x86_64/kernel/entry.o] Error 1 make: *** [arch/x86_64/kernel] Error 2 Assembler problem? So it looks like my GCC is OK but the assembler and linker still are not happy. Any ideas? Lee From smithbone at gmail.com Thu Dec 8 19:23:47 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 19:23:57 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134086747.6188.54.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> <1134083791.6188.36.camel@mindpipe> <1134086747.6188.54.camel@mindpipe> Message-ID: <8a0c36780512081623y7d85e39fx2e0380bd048e7a34@mail.gmail.com> > ld: warning: i386 architecture of input file `usr/initramfs_data.o' is incompatible with i386:x86-64 output>> This one is worrisome, maybe I also need to pass LDFLAGS?>> CC arch/x86_64/kernel/process.o> CC arch/x86_64/kernel/signal.o> AS arch/x86_64/kernel/entry.o> arch/x86_64/kernel/entry.S: Assembler messages:> arch/x86_64/kernel/entry.S:204: Error: cannot represent relocation type BFD_RELOC_X86_64_32S> arch/x86_64/kernel/entry.S:275: Error: cannot represent relocation type BFD_RELOC_X86_64_32S> arch/x86_64/kernel/entry.S:762: Error: cannot represent relocation type BFD_RELOC_X86_64_32S> arch/x86_64/kernel/entry.S:815: Error: cannot represent relocation type BFD_RELOC_X86_64_32S> arch/x86_64/kernel/entry.S:536: Error: cannot represent relocation type BFD_RELOC_64> arch/x86_64/kernel/entry.S:536: Error: cannot represent relocation type BFD_RELOC_64> arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64> arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64> make[1]: *** [arch/x86_64/kernel/entry.o] Error 1> make: *** [arch/x86_64/kernel] Error 2>> Assembler problem?>> So it looks like my GCC is OK but the assembler and linker still are not> happy. Any ideas? Mmmmm... ick. you may need some patches... http://sourceware.org/ml/binutils/2005-03/msg00850.htmlhttp://sources.redhat.com/ml/binutils/2005-06/msg00451.html --Richard A. Smith From rlrevell at joe-job.com Thu Dec 8 19:30:35 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 19:31:19 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134086747.6188.54.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> <1134083791.6188.36.camel@mindpipe> <1134086747.6188.54.camel@mindpipe> Message-ID: <1134088235.6188.56.camel@mindpipe> On Thu, 2005-12-08 at 19:05 -0500, Lee Revell wrote: > (I apologise if anyone finds this thread OT, it is relevant to Linux > audio development and the kernel people don't want to hear about > toolchain problems) Never mind, this is actually quite OT and I should take it to the debian-amd64 list. Thanks, Lee From rlrevell at joe-job.com Thu Dec 8 19:39:15 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 19:51:00 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081623y7d85e39fx2e0380bd048e7a34@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> <1134083791.6188.36.camel@mindpipe> <1134086747.6188.54.camel@mindpipe> <8a0c36780512081623y7d85e39fx2e0380bd048e7a34@mail.gmail.com> Message-ID: <1134088755.6188.60.camel@mindpipe> On Thu, 2005-12-08 at 18:23 -0600, Richard Smith wrote: > > ld: warning: i386 architecture of input file `usr/initramfs_data.o' is incompatible with i386:x86-64 output>> This one is worrisome, maybe I also need to pass LDFLAGS?>> CC arch/x86_64/kernel/process.o> CC arch/x86_64/kernel/signal.o> AS arch/x86_64/kernel/entry.o> arch/x86_64/kernel/entry.S: Assembler messages:> arch/x86_64/kernel/entry.S:204: Error: cannot represent relocation type BFD_RELOC_X86_64_32S> arch/x86_64/kernel/entry.S:275: Error: cannot represent relocation type BFD_RELOC_X86_64_32S> arch/x86_64/kernel/entry.S:762: Error: cannot represent relocation type BFD_RELOC_X86_64_32S> arch/x86_64/kernel/entry.S:815: Error: cannot represent relocation type BFD_RELOC_X86_64_32S> arch/x86_64/kernel/entry.S:536: Error: cannot represent relocation type BFD_RELOC_64> arch/x86_64/kernel/entry.S:536: Error: cannot represent relocation type BFD_RELOC_64> arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64> arch/x86_64/kerne! > l/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64> make[1]: *** [arch/x86_64/kernel/entry.o] Error 1> make: *** [arch/x86_64/kernel] Error 2>> Assembler problem?>> So it looks like my GCC is OK but the assembler and linker still are not> happy. Any ideas? > Mmmmm... ick. you may need some patches... > http://sourceware.org/ml/binutils/2005-03/msg00850.htmlhttp://sources.redhat.com/ml/binutils/2005-06/msg00451.html > --Richard A. Smith > Yup, my binutils changelog stops two months before that bug was fixed. Thanks! Lee From smithbone at gmail.com Thu Dec 8 19:54:05 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu Dec 8 19:54:15 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134088235.6188.56.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> <1134083791.6188.36.camel@mindpipe> <1134086747.6188.54.camel@mindpipe> <1134088235.6188.56.camel@mindpipe> Message-ID: <8a0c36780512081654x786461c2iee0433d820937050@mail.gmail.com> > On Thu, 2005-12-08 at 19:05 -0500, Lee Revell wrote:> > (I apologise if anyone finds this thread OT, it is relevant to Linux> > audio development and the kernel people don't want to hear about> > toolchain problems)>> Never mind, this is actually quite OT and I should take it to the> debian-amd64 list. Sorry I couldn't help you more. Cross compile to Amd64 is not oneI've messed with yet. --Richard A. Smith From rlrevell at joe-job.com Thu Dec 8 20:07:15 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 8 20:06:01 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <8a0c36780512081654x786461c2iee0433d820937050@mail.gmail.com> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> <8a0c36780512081417y53c002c9yc4c34831b04e9802@mail.gmail.com> <8a0c36780512081420w71e0c261q43b4cff8fe090800@mail.gmail.com> <1134083791.6188.36.camel@mindpipe> <1134086747.6188.54.camel@mindpipe> <1134088235.6188.56.camel@mindpipe> <8a0c36780512081654x786461c2iee0433d820937050@mail.gmail.com> Message-ID: <1134090435.11053.6.camel@mindpipe> On Thu, 2005-12-08 at 18:54 -0600, Richard Smith wrote: > > On Thu, 2005-12-08 at 19:05 -0500, Lee Revell wrote:> > (I apologise if anyone finds this thread OT, it is relevant to Linux> > audio development and the kernel people don't want to hear about> > toolchain problems)>> Never mind, this is actually quite OT and I should take it to the> debian-amd64 list. > Sorry I couldn't help you more. Cross compile to Amd64 is not oneI've messed with yet. No problem, you were quite helpful, I just didn't want to bug the list with a bunch of kernel stuff. I guess I just assumed it would be easy because so many people have amd64... Lee From astochlia at msn.com Thu Dec 8 22:21:57 2005 From: astochlia at msn.com (ARRON STOCHLIA) Date: Thu Dec 8 22:22:00 2005 Subject: [linux-audio-dev] non graphical vu meter Message-ID: I am trying to write an application that will monitor volume level coming in through the line-in jack on my soundcard. Is this possible using alsa, and if so, does anyone know of any examples, or am I in the wrong place? _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From loki.davison at gmail.com Thu Dec 8 23:55:32 2005 From: loki.davison at gmail.com (Loki Davison) Date: Thu Dec 8 23:55:48 2005 Subject: [linux-audio-dev] Re: Replacement for my M-Audio Audiophile USB In-Reply-To: <439850FF.9090709@chapelperilous.net> References: <8a0c36780512080718h3fd3bd14lcd9aa9f17e27d1b3@mail.gmail.com> <439850FF.9090709@chapelperilous.net> Message-ID: On 12/9/05, Brett McCoy wrote: > Richard Smith wrote: > > > After several frustrating weeks playing with my Audiophile USB > > I'mgoing to punt and get something else. For the archives: ALSA > > users interested in high-end capture should_not_ buy this > > device.(FWIW it sucks in windows too) - Its only a USB 1.1 device and > > 24bit 96k is half-duplex only.- Its (almost) S24_3BE so you have to > > use plughw or jackd has to bepatched to use it. I say almost > > because the few times I did get thecard to record something I had to > > reorder the byte data to get it notto sound like white noise.- As of > > ALSA 1.0.10 capture is broken. So I'm looking for a replacement. I > > bought this card because it had areally good recording specs (I just > > missed the half-duplex part) and Idont' need a pro-multi channel > > since all I'm tyring to do is recordLPs to CD. Can someone recommend > > a 24bit 96kHz full-duplex card that they thinkhas good enough > > recording specs for LP's that not going to cause me topull all my > > hair out trying to work with ALSA. --Richard A. Smith > > How about the M-Audio 2496 card? It's a PCI card, works right out of the > box with ALSA and is reasonably priced ($99). And it's full duplex, > zero-latency monitoring, digital I/O as well as analog RCA I/O > > -- Brett > > > I record vinyl (new) on a very regular basis with my griffin imic. Cheap usb gear if that's what you need. only 24 / 48k though. Sounds good to me though. I use ortofon needles and run the turntables through my ecler mixer. All round sound quality is very good. Loki From kairuemmler at yahoo.de Fri Dec 9 04:38:46 2005 From: kairuemmler at yahoo.de (Kai Ruemmler) Date: Fri Dec 9 04:38:53 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134079530.6188.17.camel@mindpipe> References: <1134067577.3919.16.camel@mindpipe> <20051208194832.GA9174@dings.kai> <1134077576.6188.4.camel@mindpipe> <8a0c36780512081342p2d81cd1l6c470b3addc5a7b8@mail.gmail.com> <1134079530.6188.17.camel@mindpipe> Message-ID: <20051209093846.GA11486@dings.kai> * Lee Revell wrote: > > My experince with all the embedded processors I deal with is > > thatcross compiling almost never "just works". You might try > > gettingcrosstool and building a 64bit toolchain. That will take a > > hour or 2though. Unless you have a screaming machine. > OK, brilliant. Apparently the only way to do this is to install the > "toolchain-source" package and, yep, BUILD A TOOLCHAIN FROM SOURCE. Sorry for being slow, but it was sleeping time here in Germany. :-) Just for the records (You took the thread to debian-amd64 further down the road): You don't need a full toolchain for compiling kernel stuff, binutils and gcc are enough. The kernel doesn't link against glibc. :-) You could install binutils and gcc into a temporary directory (let's say /tmp/cross), put /tmp/cross/bin in front of $PATH and you are set. This way you can just rm -rf /tmp/cross if you want to get rid of it again. I am not subscribed to debian-amd64 so I don't know if you were successful already, but if you want I can send you my script I use for this kind of tasks per PM. > Christ, I cannot believe what a pain in the ass this is. At this rate > it will have taken me 2 days to get this working. I don't think so. Setting up a full toolchain may take a bit longer, but for compiling kernels you really just need the easy part of it. Kai -- ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de From smithbone at gmail.com Fri Dec 9 09:38:26 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri Dec 9 09:38:29 2005 Subject: [linux-audio-dev] non graphical vu meter In-Reply-To: References: Message-ID: <8a0c36780512090638h5dae5a2fw7eb57d3a70ce7dab@mail.gmail.com> On 12/8/05, ARRON STOCHLIA wrote:> I am trying to write an application that will monitor volume level coming in> through the line-in jack on my soundcard. Is this possible using alsa, and> if so, does anyone know of any examples, or am I in the wrong place? arecord -vv aready does this. Note thats 2 'v's and not a 'w'. On my system the font makes themlook the same. --Richard A. Smith From smithbone at gmail.com Fri Dec 9 09:46:35 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri Dec 9 09:46:39 2005 Subject: [linux-audio-dev] Re: Replacement for my M-Audio Audiophile USB In-Reply-To: References: <8a0c36780512080718h3fd3bd14lcd9aa9f17e27d1b3@mail.gmail.com> <439850FF.9090709@chapelperilous.net> Message-ID: <8a0c36780512090646w44a1e5d8k9d92463dfcac5f11@mail.gmail.com> > I record vinyl (new) on a very regular basis with my griffin imic.> Cheap usb gear if that's what you need. only 24 / 48k though. Sounds> good to me though. I use ortofon needles and run the turntables> through my ecler mixer. All round sound quality is very good. I'm taking a break from USB soundcards. *grin*. I purchased an Audiophile 2496. Even though my first M-Audio productexperience sucked. There's loads of stuff about success's with the2496 and it's recording specs were almost just a good as theaudiophile USB. Newegg had them for $89 bucks. Thank's for the info. Looks like I need to get an ortofon needle formy new Stanton turntable. You are the 2nd person to call them out. --Richard A. Smith From brinkman at math.TU-Berlin.DE Fri Dec 9 20:52:15 2005 From: brinkman at math.TU-Berlin.DE (Peter Brinkmann) Date: Fri Dec 9 20:52:25 2005 Subject: [linux-audio-dev] ALSA MIDI Sync Message-ID: <20051210015215.GA4655@fuchs.math.tu-berlin.de> Hi, I'm trying to figure out how to build an ALSA MIDI sequencer that'll sync with other sequencers. I've looked around but didn't see any recent information. (The closest hits were a five-year-old page of Takashi Iwai's, a three-year-old LAD thread with the subject line "MIDI sync and ALSA sequencer", and a LAU thread from last year, none of which sounded entirely encouraging.) So, my question is, what's the recommended way of synchronizing two MIDI sequencers these days, using ALSA? Is there any protocol (MTC, MMC...) that you would recommend so as to be compatible with a large number of other software packages? Any hints would be appreciated. Pointers to sample implementations of MIDI sync with ALSA would be great. Best, Peter From rlrevell at joe-job.com Fri Dec 9 23:43:05 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Dec 9 23:47:42 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required In-Reply-To: <200512080620.jB86Kbfr013996@sprite.physics.adelaide.edu.au> References: <200512080620.jB86Kbfr013996@sprite.physics.adelaide.edu.au> Message-ID: <1134189786.18432.72.camel@mindpipe> On Thu, 2005-12-08 at 16:50 +1030, Jonathan Woithe wrote: > > On Fri, 2005-11-25 at 11:10 +1030, Jonathan Woithe wrote: > > > I have since discovered (thanks to strace) that the problem lies in an > > > mmap2() call which requests a size of around 8MB. It appears to be > > > part of the NPTL pthread_create() function. The error returned by > > > mmap2() (EAGAIN) indicates either a locked file or "too much locked > > > memory" (according to the manpage). Because this is an anonymous map > > > the problem must have been the latter. Increasing the "locked memory" > > > limit from 20MB to 40MB made jackd start without having to resort to > > > the LD_ASSUME_KERNEL hack. > > > > I stumbled across the same problem a few weeks ago working on another > > project. This is glibc allocating an 8MB (!) stack for each thread. It > > gets the default thread stack size from getrlimit(). With mlockall() > > you will go OOM really fast like that. > > > > The real fix is for JACK to set a reasonable thread stack size in > > jack_create_thread. You can work around the problem by appending this > > line to /etc/security/limits.conf: > > > > * hard stack 512 > > > > for a 512KB stack. > > I tried this. Although this reduced the size of the mlock calls I found I > still needed an mlock limit of at least 40MB for jack and ardour to start. > However, even with this loading a large session into ardour failed to load > with no error given (beyond the fact that the loading failed). > > You mentioned in another post that you're working on a "proper" fix for > jack. I'll wait for this to be implemented before digging into this > issue further since the correct fix might change things. Drop me a line > when a fix has made it into CVS and I'll resume my testing. Um, all my fix will do is reduce the thread stack size to something more reasonable, say 256KB per thread. You're still going to need an mlock limit of more than 40MB to do anything useful. Lee From loki.davison at gmail.com Sat Dec 10 02:03:35 2005 From: loki.davison at gmail.com (Loki Davison) Date: Sat Dec 10 02:03:40 2005 Subject: [linux-audio-dev] Re: Replacement for my M-Audio Audiophile USB In-Reply-To: <8a0c36780512090646w44a1e5d8k9d92463dfcac5f11@mail.gmail.com> References: <8a0c36780512080718h3fd3bd14lcd9aa9f17e27d1b3@mail.gmail.com> <439850FF.9090709@chapelperilous.net> <8a0c36780512090646w44a1e5d8k9d92463dfcac5f11@mail.gmail.com> Message-ID: On 12/10/05, Richard Smith wrote: > > I record vinyl (new) on a very regular basis with my griffin imic.> Cheap > usb gear if that's what you need. only 24 / 48k though. Sounds> good to me > though. I use ortofon needles and run the turntables> through my ecler > mixer. All round sound quality is very good. > I'm taking a break from USB soundcards. *grin*. > I purchased an Audiophile 2496. Even though my first M-Audio > productexperience sucked. There's loads of stuff about success's with > the2496 and it's recording specs were almost just a good as theaudiophile > USB. Newegg had them for $89 bucks. > Thank's for the info. Looks like I need to get an ortofon needle formy new > Stanton turntable. You are the 2nd person to call them out. > --Richard A. Smith > Stanton turntable? STR8-130 or whatever they are called, the one with the spdif out? If so, don't use the spdif out. Use the normal phono out a standard preamp. I'm assuming it would come with stanton needles which, as somewhat of a generalisation, suck. If it's just for recording get one of the cheaper eliptical ortofon needles. The om 5e is nice and cheap. If you get into the concord range it's mostly about djing stuff, i.e better tracking, more sturdy and the extra cash doesn't always mean better sound quality. For djing stuff i'd recommend the elektro (the white one). Loki From smithbone at gmail.com Sat Dec 10 16:45:49 2005 From: smithbone at gmail.com (Richard Smith) Date: Sat Dec 10 16:45:52 2005 Subject: [linux-audio-dev] Re: Replacement for my M-Audio Audiophile USB In-Reply-To: References: <8a0c36780512080718h3fd3bd14lcd9aa9f17e27d1b3@mail.gmail.com> <439850FF.9090709@chapelperilous.net> <8a0c36780512090646w44a1e5d8k9d92463dfcac5f11@mail.gmail.com> Message-ID: <8a0c36780512101345y1bef27e0q39aaab2ff30e4fd0@mail.gmail.com> > Stanton turntable? STR8-130 or whatever they are called, the one with> the spdif out? If so, don't use the spdif out. Use the normal phono> out a standard preamp. STR8-100. It has spdif, line and phono. I'm currently using the line.Very nice unit I can see why djers would like them. > I'm assuming it would come with stanton needles> which, as somewhat of a generalisation, suck. If it's just for> recording get one of the cheaper eliptical ortofon needles. The om 5e> is nice and cheap. Yep it has a stanton 505 on it. Thanks for the needle suggestion. I'm assuming I need a cartridge rather than a stylus? Guess I shouldcall the guy at the store and make sure I get what I need. Gmailgives me needledoctor.com as a sponsored link and they show an OM 5ecartridge for $45. Anyone have good or bad about needledoctor.com? --Richard A. Smith From dak at gnu.org Sat Dec 10 16:52:59 2005 From: dak at gnu.org (David Kastrup) Date: Sat Dec 10 16:52:40 2005 Subject: [linux-audio-dev] Merging digital sampling sessions Message-ID: <857jacwres.fsf@lola.goethe.zz> Hi, I have a minidisc player with S/PDIF output and an ALSA supported soundcard (details if the card are not really important for the problem at hand). I sample recordings via arecord -D spdif -f cd Ok, and here is the rub: playback is not perfect, and neither seems to be the sampling. Probably at times error interpolation sets in, probably at times samples get lost or replicated. Not much, perhaps once per minute or so. This leads to audible clicks, of course. Then there are leading and trailing zeros. Now what I want to do is just sample the stuff three times and do a three-way merge. Never mind clever click detecting and interpolation schemes: just use redundancy. I have not found a tool for that. Anybody have a clue how to go about that? If things come to worst, I'll have to write a merging tool. Bonus points would be if the thing worked on-line, taking one recording, sampling new samples and just writing the diff out. Run this three times, then run a merge program on the first complete sampling as well as all diffs. That would save quite a bit of disk space. However, it is not really mandatory: just merging three full size files would be fine. Anybody have an idea whether there is some suitable starting point or utility for this kind of thing? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From rlrevell at joe-job.com Sat Dec 10 17:09:52 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Sat Dec 10 17:08:11 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <857jacwres.fsf@lola.goethe.zz> References: <857jacwres.fsf@lola.goethe.zz> Message-ID: <1134252592.18432.155.camel@mindpipe> On Sat, 2005-12-10 at 22:52 +0100, David Kastrup wrote: > I have a minidisc player with S/PDIF output and an ALSA supported > soundcard (details if the card are not really important for the > problem at hand). > > I sample recordings via > > arecord -D spdif -f cd > > Ok, and here is the rub: playback is not perfect, and neither seems to > be the sampling. Probably at times error interpolation sets in, > probably at times samples get lost or replicated. Not much, perhaps > once per minute or so. This leads to audible clicks, of course. Well, it would be better to figure out why arecord doesn't work than try to work around it. Use "arecord -v -D spdif -f cd" and see if a rate conversion plugin is used. The ALSA SRC is not great so if that is the case then you'll get better results sampling at 48KHz (-f dat) then downsampling to 44.1 afterward. Lee From dak at gnu.org Sat Dec 10 17:39:48 2005 From: dak at gnu.org (David Kastrup) Date: Sat Dec 10 17:39:30 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <1134252592.18432.155.camel@mindpipe> (Lee Revell's message of "Sat, 10 Dec 2005 17:09:52 -0500") References: <857jacwres.fsf@lola.goethe.zz> <1134252592.18432.155.camel@mindpipe> Message-ID: <851x0kwp8r.fsf@lola.goethe.zz> Lee Revell writes: > On Sat, 2005-12-10 at 22:52 +0100, David Kastrup wrote: >> I have a minidisc player with S/PDIF output and an ALSA supported >> soundcard (details if the card are not really important for the >> problem at hand). >> >> I sample recordings via >> >> arecord -D spdif -f cd >> >> Ok, and here is the rub: playback is not perfect, and neither seems to >> be the sampling. Probably at times error interpolation sets in, >> probably at times samples get lost or replicated. Not much, perhaps >> once per minute or so. This leads to audible clicks, of course. > > Well, it would be better to figure out why arecord doesn't work than try > to work around it. > > Use "arecord -v -D spdif -f cd" and see if a rate conversion plugin is > used. The ALSA SRC is not great so if that is the case then you'll get > better results sampling at 48KHz (-f dat) then downsampling to 44.1 > afterward. Does not appear to be the case, and anyway, there would not be a reason that rate conversion leads to glitches. Here you are: Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Hardware PCM card 0 'C-Media PCI CMI8738-MC6' device 2 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 16384 period_size : 4096 period_time : 92879 tick_time : 1000 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 4096 xfer_align : 4096 start_threshold : 1 stop_threshold : 16384 silence_threshold: 0 silence_size : 0 boundary : 1073741824 Aborted by signal Interrupt... On another note: it would seem like a simple enough task to let the recording start with the first non-zero sample. I have been completely unable to make head or tails of the manual page descriptions of the arecord options presumably intended for that and have found absolutely no setting that would not either drop quite more than just the initial zeros, or not drop anything at all. I'd also like to prune trailing zeros at some point of time. arecord does not seem to have options for doing that, I guess. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From rlrevell at joe-job.com Sat Dec 10 17:54:50 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Sat Dec 10 17:53:09 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <851x0kwp8r.fsf@lola.goethe.zz> References: <857jacwres.fsf@lola.goethe.zz> <1134252592.18432.155.camel@mindpipe> <851x0kwp8r.fsf@lola.goethe.zz> Message-ID: <1134255291.18432.173.camel@mindpipe> On Sat, 2005-12-10 at 23:39 +0100, David Kastrup wrote: > On another note: it would seem like a simple enough task to let the > recording start with the first non-zero sample. I have been > completely unable to make head or tails of the manual page > descriptions of the arecord options presumably intended for that and > have found absolutely no setting that would not either drop quite more > than just the initial zeros, or not drop anything at all. > > I'd also like to prune trailing zeros at some point of time. arecord > does not seem to have options for doing that, I guess. Well arecord is more of a debugging tool and a demonstration of the ALSA API than a full featured recording app. Check the list archives, I am pretty sure this was discussed not long ago. Lee From dak at gnu.org Sat Dec 10 18:00:19 2005 From: dak at gnu.org (David Kastrup) Date: Sat Dec 10 18:00:01 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <1134255291.18432.173.camel@mindpipe> (Lee Revell's message of "Sat, 10 Dec 2005 17:54:50 -0500") References: <857jacwres.fsf@lola.goethe.zz> <1134252592.18432.155.camel@mindpipe> <851x0kwp8r.fsf@lola.goethe.zz> <1134255291.18432.173.camel@mindpipe> Message-ID: <85wticv9q4.fsf@lola.goethe.zz> Lee Revell writes: > On Sat, 2005-12-10 at 23:39 +0100, David Kastrup wrote: >> On another note: it would seem like a simple enough task to let the >> recording start with the first non-zero sample. I have been >> completely unable to make head or tails of the manual page >> descriptions of the arecord options presumably intended for that and >> have found absolutely no setting that would not either drop quite more >> than just the initial zeros, or not drop anything at all. >> >> I'd also like to prune trailing zeros at some point of time. arecord >> does not seem to have options for doing that, I guess. > > Well arecord is more of a debugging tool and a demonstration of the ALSA > API than a full featured recording app. Check the list archives, I am > pretty sure this was discussed not long ago. Any keywords? I skimmed the subject lines from the past few months and don't think I hit anything obvious. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From loki.davison at gmail.com Sat Dec 10 23:16:00 2005 From: loki.davison at gmail.com (Loki Davison) Date: Sat Dec 10 23:16:03 2005 Subject: [linux-audio-dev] Re: Replacement for my M-Audio Audiophile USB In-Reply-To: <8a0c36780512101345y1bef27e0q39aaab2ff30e4fd0@mail.gmail.com> References: <8a0c36780512080718h3fd3bd14lcd9aa9f17e27d1b3@mail.gmail.com> <439850FF.9090709@chapelperilous.net> <8a0c36780512090646w44a1e5d8k9d92463dfcac5f11@mail.gmail.com> <8a0c36780512101345y1bef27e0q39aaab2ff30e4fd0@mail.gmail.com> Message-ID: On 12/11/05, Richard Smith wrote: > > Stanton turntable? STR8-130 or whatever they are called, the one with> the > spdif out? If so, don't use the spdif out. Use the normal phono> out a > standard preamp. > STR8-100. It has spdif, line and phono. I'm currently using the line.Very > nice unit I can see why djers would like them. > > I'm assuming it would come with stanton needles> which, as somewhat of a > generalisation, suck. If it's just for> recording get one of the cheaper > eliptical ortofon needles. The om 5e> is nice and cheap. > Yep it has a stanton 505 on it. Thanks for the needle suggestion. I'm > assuming I need a cartridge rather than a stylus? Guess I shouldcall the > guy at the store and make sure I get what I need. Gmailgives me > needledoctor.com as a sponsored link and they show an OM 5ecartridge for > $45. Anyone have good or bad about needledoctor.com? > --Richard A. Smith > ahh, 505 and 500al sound are pretty horrible. That om 5e cart is good and cheap for recording stuff. Yeah, you need the whole thing rather than just the tip. When you have an ortofon cart all the OM and concord tips can be interchanged. Loki From tito at rumford.de Sun Dec 11 09:06:08 2005 From: tito at rumford.de (Wolfgang Woehl) Date: Sun Dec 11 09:06:16 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <857jacwres.fsf@lola.goethe.zz> References: <857jacwres.fsf@lola.goethe.zz> Message-ID: <200512111506.08188.tito@rumford.de> David Kastrup : > arecord -D spdif -f cd > > Ok, and here is the rub: playback is not perfect, and neither seems > to be the sampling. Probably at times error interpolation sets in, > probably at times samples get lost or replicated. Not much, perhaps > once per minute or so. This leads to audible clicks, of course. You're assuming a flawed spdif stream and, well, people keep suggesting changing the spdif cable. It's supposed to have an effect on stream quality worth mentioning. Don't know myself. But try setting the c-media card to respect the incoming spdif clock. That should make a difference. Wolfgang From paniq at paniq.org Sun Dec 11 10:32:21 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sun Dec 11 10:31:11 2005 Subject: [linux-audio-dev] python and jack, performance report In-Reply-To: <20050714212322.GA829@phlunky.Belkin> References: <20050714212322.GA829@phlunky.Belkin> Message-ID: <1134315141.3234.4.camel@zeitgeist> frustrated by the poor implementation of the jack bindings for python (pyjack), i wrote my own in native python using ctypes. the first test client mixed a 440hz sine wave using native python lists, and the cpu usage was about ~11%. i reimplemented the sine generator with numerics, and got it down to ~2%. i believe that considering the overhead of the python implementation, that result isn't too bad, and maybe allows for more than just prototyping. i attached the jack wrapper with the test client contained for those who are interested. its not entirely wrapped and lacks some functionality. -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org -------------- next part -------------- A non-text attachment was scrubbed... Name: jack.py Type: text/x-python Size: 8405 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051211/1856f20c/jack-0001.py From paniq at paniq.org Sun Dec 11 10:33:29 2005 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Sun Dec 11 10:32:14 2005 Subject: [linux-audio-dev] python and jack, performance report Message-ID: <1134315209.3234.5.camel@zeitgeist> -- oops, the first one was sent as a reply, here's the whole thing as a new thread. frustrated by the poor implementation of the jack bindings for python (pyjack), i wrote my own in native python using ctypes. the first test client mixed a 440hz sine wave using native python lists, and the cpu usage was about ~11%. i reimplemented the sine generator with numerics, and got it down to ~2%. i believe that considering the overhead of the python implementation, that result isn't too bad, and maybe allows for more than just prototyping. i attached the jack wrapper with the test client contained for those who are interested. its not entirely wrapped and lacks some functionality. -- -- leonard "paniq" ritter -- http://www.mjoo.org -- http://www.paniq.org -------------- next part -------------- A non-text attachment was scrubbed... Name: jack.py Type: text/x-python Size: 8405 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051211/8c6afc32/jack.py From fw at deneb.enyo.de Sun Dec 11 13:21:53 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun Dec 11 13:22:04 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <1134067577.3919.16.camel@mindpipe> (Lee Revell's message of "Thu, 08 Dec 2005 13:46:16 -0500") References: <1134067577.3919.16.camel@mindpipe> Message-ID: <87bqznh4u6.fsf@mid.deneb.enyo.de> * Lee Revell: > All I am trying to do is compile an x86_64 kernel on i386 machine. It > dos not work: This a few helper scripts; building an AMD64 kernel on i386 is not exactly cross-compiling. Basically, the helper scripts must invoke "gcc -m64" when no -m32 option is given, and "gcc" if there's an "-m32" option ("-m64 -m32" does *not* override the -m64). More magic is required for objcopy, otherwise the compiled kernel will crash on boot. The Debian kernel package building infrastructure contains the necessary scripts AFAIK. From rlrevell at joe-job.com Sun Dec 11 14:24:44 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Dec 11 14:31:36 2005 Subject: [linux-audio-dev] Cross compiling the kernel In-Reply-To: <87bqznh4u6.fsf@mid.deneb.enyo.de> References: <1134067577.3919.16.camel@mindpipe> <87bqznh4u6.fsf@mid.deneb.enyo.de> Message-ID: <1134329084.6019.20.camel@mindpipe> On Sun, 2005-12-11 at 19:21 +0100, Florian Weimer wrote: > * Lee Revell: > > > All I am trying to do is compile an x86_64 kernel on i386 machine. It > > dos not work: > > This a few helper scripts; building an AMD64 kernel on i386 is not > exactly cross-compiling. Basically, the helper scripts must invoke > "gcc -m64" when no -m32 option is given, and "gcc" if there's an > "-m32" option ("-m64 -m32" does *not* override the -m64). More magic > is required for objcopy, otherwise the compiled kernel will crash on > boot. > > The Debian kernel package building infrastructure contains the > necessary scripts AFAIK. > Actually I was able to get this fixed. This was a bug in the kernel build system where it didn't grok biarch toolchains like Ubuntu provides. Andi Kleen sent me a kernel patch, presumably it will be fixed in 2.6.15. Check the LKML archives for the past few days for details. Lee From dak at gnu.org Sun Dec 11 17:44:32 2005 From: dak at gnu.org (David Kastrup) Date: Sun Dec 11 17:44:22 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <200512111506.08188.tito@rumford.de> (Wolfgang Woehl's message of "Sun, 11 Dec 2005 15:06:08 +0100") References: <857jacwres.fsf@lola.goethe.zz> <200512111506.08188.tito@rumford.de> Message-ID: <85mzj7z227.fsf@lola.goethe.zz> Wolfgang Woehl writes: > David Kastrup : > >> arecord -D spdif -f cd >> >> Ok, and here is the rub: playback is not perfect, and neither seems >> to be the sampling. Probably at times error interpolation sets in, >> probably at times samples get lost or replicated. Not much, perhaps >> once per minute or so. This leads to audible clicks, of course. > > You're assuming a flawed spdif stream and, well, people keep suggesting > changing the spdif cable. It's supposed to have an effect on stream > quality worth mentioning. Don't know myself. > > But try setting the c-media card to respect the incoming spdif clock. > That should make a difference. Any idea how? I have had just a few weird experiences: without any preparation, recording (and monitoring) is just one crackly mess. If I do aplay /usr/share/sounds/startup.wav while arecord -D spdif has not yet given up with an error, (the recording has this muted), then the recording will turn into working pretty much transparently. However, starting a new recording session will revert to snack, crackle and pop. If I do aplay -D spdif /usr/share/sounds/startup.wav however, a subsequent arecord -D spdif command will not revert to crackle mode. So there is already something going on which I don't understand. In "crackle mode", there is basically just noise, but the noise level is correlated with the amplitude of the sound source. So what would one actually have to do to have the "incoming spdif clock" respected? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From jwoithe at physics.adelaide.edu.au Sun Dec 11 19:39:02 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Sun Dec 11 19:37:01 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required In-Reply-To: <1134189786.18432.72.camel@mindpipe> from "Lee Revell" at Dec 09, 2005 11:43:05 PM Message-ID: <200512120039.jBC0d2jN003302@auster.physics.adelaide.edu.au> > On Thu, 2005-12-08 at 16:50 +1030, Jonathan Woithe wrote: > > > On Fri, 2005-11-25 at 11:10 +1030, Jonathan Woithe wrote: > > > > I have since discovered (thanks to strace) that the problem lies in an > > > > mmap2() call which requests a size of around 8MB. It appears to be > > > > part of the NPTL pthread_create() function. The error returned by > > > > mmap2() (EAGAIN) indicates either a locked file or "too much locked > > > > memory" (according to the manpage). Because this is an anonymous map > > > > the problem must have been the latter. Increasing the "locked memory" > > > > limit from 20MB to 40MB made jackd start without having to resort to > > > > the LD_ASSUME_KERNEL hack. > > > > > > I stumbled across the same problem a few weeks ago working on another > > > project. This is glibc allocating an 8MB (!) stack for each thread. It > > > gets the default thread stack size from getrlimit(). With mlockall() > > > you will go OOM really fast like that. > > > > > > The real fix is for JACK to set a reasonable thread stack size in > > > jack_create_thread. You can work around the problem by appending this > > > line to /etc/security/limits.conf: > > > > > > * hard stack 512 > > > > > > for a 512KB stack. > > > > I tried this. Although this reduced the size of the mlock calls I found I > > still needed an mlock limit of at least 40MB for jack and ardour to start. > > However, even with this loading a large session into ardour failed to load > > with no error given (beyond the fact that the loading failed). > > > > You mentioned in another post that you're working on a "proper" fix for > > jack. I'll wait for this to be implemented before digging into this > > issue further since the correct fix might change things. Drop me a line > > when a fix has made it into CVS and I'll resume my testing. > > Um, all my fix will do is reduce the thread stack size to something more > reasonable, say 256KB per thread. You're still going to need an mlock > limit of more than 40MB to do anything useful. How large is reasonable? I'm finding that for large (2 hours, 12 tracks) ardour sessions I'm needing an mlock limit of in excess of 128 MB when running under NPTL (I use 256 MB to be safe); otherwise ardour can't even open the session, let alone allow any work to be done. When NPTL *isn't* in use an mlock limit of the order of 40 MB (or even 20 MB) is perfectly fine for the same ardour session and doesn't even result in any error/warning messages regarding mlock failures. Regards jonathan From tito at rumford.de Sun Dec 11 19:50:24 2005 From: tito at rumford.de (Wolfgang Woehl) Date: Sun Dec 11 19:50:20 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <85mzj7z227.fsf@lola.goethe.zz> References: <857jacwres.fsf@lola.goethe.zz> <200512111506.08188.tito@rumford.de> <85mzj7z227.fsf@lola.goethe.zz> Message-ID: <200512120150.24830.tito@rumford.de> David Kastrup : > So what would one actually have to do to have the "incoming spdif > clock" respected? The linux settings tool for my HDSP has "Preferred Sync Reference" that lets me choose between internal wordclock, ADAT and SPDIF in's. Your card should have that too. I'd check ALSA docs or the manual. Wolfgang From jwoithe at physics.adelaide.edu.au Sun Dec 11 20:22:15 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Sun Dec 11 20:20:26 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <200512111534.jBBFXh7o006672@roar.music.columbia.edu> from "linux-audio-dev-request@music.columbia.edu" at Dec 11, 2005 10:34:37 AM Message-ID: <200512120122.jBC1MFV9006688@auster.physics.adelaide.edu.au> David Kastrup writes: > On another note: it would seem like a simple enough task to let the > recording start with the first non-zero sample. ... I'd also like to prune > trailing zeros at some point of time. Although it is not a native ALSA app (due mainly to me not having the time to port it yet), batchrec does this. It still works with ALSA through the OSS emulation layer; adding native ALSA support is on my todo list for the next few months. You can grab it from http://www.physics.adelaide.edu.au/~jwoithe/batchrec-1.2.0.tgz It's pretty raw (no configure script yet) but shouldn't be too hard to compile on most systems. Batchrec can be requested to wait for signal above a certain amplitude before it records. It will also stop recording after the same threshold has been present for a user-specified time (if desired); at that point recording will stop, the file will be closed and the program will then wait for signal above the threshold again. I've used it extensively with analog inputs (hense the use of a threshold rather than exactly 0). The only fly in the ointment will be whether the SPDIF input on your soundcard can be mapped in the OSS emulation layer in such a way that OSS applications can use it. Regards jonathan From rlrevell at joe-job.com Mon Dec 12 01:35:47 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Dec 12 01:37:22 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required In-Reply-To: <200512120039.jBC0d2jN003302@auster.physics.adelaide.edu.au> References: <200512120039.jBC0d2jN003302@auster.physics.adelaide.edu.au> Message-ID: <1134369348.9702.16.camel@mindpipe> On Mon, 2005-12-12 at 11:09 +1030, Jonathan Woithe wrote: > > On Thu, 2005-12-08 at 16:50 +1030, Jonathan Woithe wrote: > > > > On Fri, 2005-11-25 at 11:10 +1030, Jonathan Woithe wrote: > > > > > I have since discovered (thanks to strace) that the problem lies in an > > > > > mmap2() call which requests a size of around 8MB. It appears to be > > > > > part of the NPTL pthread_create() function. The error returned by > > > > > mmap2() (EAGAIN) indicates either a locked file or "too much locked > > > > > memory" (according to the manpage). Because this is an anonymous map > > > > > the problem must have been the latter. Increasing the "locked memory" > > > > > limit from 20MB to 40MB made jackd start without having to resort to > > > > > the LD_ASSUME_KERNEL hack. > > > > > > > > I stumbled across the same problem a few weeks ago working on another > > > > project. This is glibc allocating an 8MB (!) stack for each thread. It > > > > gets the default thread stack size from getrlimit(). With mlockall() > > > > you will go OOM really fast like that. > > > > > > > > The real fix is for JACK to set a reasonable thread stack size in > > > > jack_create_thread. You can work around the problem by appending this > > > > line to /etc/security/limits.conf: > > > > > > > > * hard stack 512 > > > > > > > > for a 512KB stack. > > > > > > I tried this. Although this reduced the size of the mlock calls I found I > > > still needed an mlock limit of at least 40MB for jack and ardour to start. > > > However, even with this loading a large session into ardour failed to load > > > with no error given (beyond the fact that the loading failed). > > > > > > You mentioned in another post that you're working on a "proper" fix for > > > jack. I'll wait for this to be implemented before digging into this > > > issue further since the correct fix might change things. Drop me a line > > > when a fix has made it into CVS and I'll resume my testing. > > > > Um, all my fix will do is reduce the thread stack size to something more > > reasonable, say 256KB per thread. You're still going to need an mlock > > limit of more than 40MB to do anything useful. > > How large is reasonable? I'm finding that for large (2 hours, 12 tracks) > ardour sessions I'm needing an mlock limit of in excess of 128 MB when > running under NPTL (I use 256 MB to be safe); otherwise ardour can't even > open the session, let alone allow any work to be done. When NPTL *isn't* in > use an mlock limit of the order of 40 MB (or even 20 MB) is perfectly fine > for the same ardour session and doesn't even result in any error/warning > messages regarding mlock failures. OK. I'm not sure what causes this. But I have two ideas. I have looked at the NPTL (2.3.5) source, and unless you use pthread_attr_setstack() to manage the stacks yourself, it maintains an internal cache of thread stacks that could be related to this problem - I didn't look hard enough to figure out at which point it starts to free() things - possibly the cache is allowed to grow very big. And since NPTL does not care as it assumes that thread stacks are pageable I can see where with mlock()ed stacks this could get quite big. Also, I've found that if a thread is created joinable (the default) and exits but is never joined, the parent thread will leak ~200 bytes of memory for each thread until you go OOM. Creating the threads detached prevents the memory leak. Lee From alex-contact at caoua.org Mon Dec 12 15:23:22 2005 From: alex-contact at caoua.org (Alexandre Ratchov) Date: Mon Dec 12 15:23:27 2005 Subject: [linux-audio-dev] ALSA MIDI Sync In-Reply-To: <20051210015215.GA4655@fuchs.math.tu-berlin.de> References: <20051210015215.GA4655@fuchs.math.tu-berlin.de> Message-ID: <20051212202322.GA27826@moule.localdomain> On Sat, Dec 10, 2005 at 02:52:15AM +0100, Peter Brinkmann wrote: > > > Hi, > I'm trying to figure out how to build an ALSA MIDI sequencer that'll > sync with other sequencers. I've looked around but didn't see any > recent information. (The closest hits were a five-year-old page of > Takashi Iwai's, a three-year-old LAD thread with the subject line > "MIDI sync and ALSA sequencer", and a LAU thread from last year, > none of which sounded entirely encouraging.) > > So, my question is, what's the recommended way of synchronizing two > MIDI sequencers these days, using ALSA? Is there any protocol (MTC, > MMC...) that you would recommend so as to be compatible with a large > number of other software packages? Any hints would be appreciated. > Pointers to sample implementations of MIDI sync with ALSA would be > great. hello, imho a simple way to synchonize 2 (or more) midi sequencers is to use the midi start, stop and clock messages (status codes 0xfa, 0xfc, 0xf8) i've successfuly used this approcach to synchronize a software sequencer (midish) to a hardware (external) one. I also could synchonize multiple instances of midish to each other. i dont know how to implement this specificaly with the alsa api, since i used the raw midi devices /dev/midiXX; you can check the source of midish (http://caoua.org/midish/midish-0.2.2.tar.gz, see mux.c). this approch should be compatible with most software or hardware midi sequencers. regards, -- Alexandre From jens.andreasen at chello.se Mon Dec 12 22:24:38 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Dec 12 22:24:47 2005 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning Message-ID: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> Hi! Seems like the father of FM-synthesis has joined wikipedia. Some of you guys might care to take a brief look at the FM-synthesis page, just once in a while, so it wont get vandalised again? -- mvh // Jens M Andreasen From jens.andreasen at chello.se Mon Dec 12 23:00:12 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Dec 12 23:00:36 2005 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning In-Reply-To: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> References: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1134446412.9097.9.camel@c80-216-124-251.cm-upc.chello.se> The missing link: http://en.wikipedia.org/wiki/Talk:Frequency_modulation_synthesis On Tue, 2005-12-13 at 04:24 +0100, Jens M Andreasen wrote: > Hi! > > Seems like the father of FM-synthesis has joined wikipedia. Some of you > guys might care to take a brief look at the FM-synthesis page, just once > in a while, so it wont get vandalised again? > > -- From clemens at ladisch.de Tue Dec 13 04:02:28 2005 From: clemens at ladisch.de (Clemens Ladisch) Date: Tue Dec 13 04:03:13 2005 Subject: [linux-audio-dev] ALSA MIDI Sync In-Reply-To: <20051210015215.GA4655@fuchs.math.tu-berlin.de> References: <20051210015215.GA4655@fuchs.math.tu-berlin.de> Message-ID: <20051213090228.GA23750@turing.informatik.uni-halle.de> Peter Brinkmann wrote: > I'm trying to figure out how to build an ALSA MIDI sequencer that'll > sync with other sequencers. I've looked around but didn't see any > recent information. > So, my question is, what's the recommended way of synchronizing two > MIDI sequencers these days, using ALSA? Is there any protocol (MTC, > MMC...) that you would recommend so as to be compatible with a large > number of other software packages? ALSA itself doesn't support any synchronization protocol; the only possible timer source is some hardware timer interrupt. It is possible to adjust the queue tempo relative to the timer interrupt frequency with snd_seq_queue_tempo_set_skew(). > Pointers to sample implementations of MIDI sync with ALSA would be > great. AFAICS Ardour supports MTC. HTH Clemens From artemio at kdemail.net Tue Dec 13 15:22:27 2005 From: artemio at kdemail.net (Artemiy Pavlov) Date: Tue Dec 13 15:22:56 2005 Subject: [linux-audio-dev] dealing with complex numbers Message-ID: <200512132222.28013.artemio@kdemail.net> Hey everybody! This may be a little bit off-topic, but can anyone suggest me any reading on how to use complex numbers in C or C++? Is there any library or ++ classes for such computations? I'd appreciate any help. Thanks! With respect, Artemiy. From idragosani at chapelperilous.net Tue Dec 13 15:40:58 2005 From: idragosani at chapelperilous.net (Brett McCoy) Date: Tue Dec 13 15:41:46 2005 Subject: [linux-audio-dev] dealing with complex numbers In-Reply-To: <200512132222.28013.artemio@kdemail.net> References: <200512132222.28013.artemio@kdemail.net> Message-ID: <439F31DA.3070205@chapelperilous.net> Artemiy Pavlov wrote: > This may be a little bit off-topic, but can anyone suggest me any reading on > how to use complex numbers in C or C++? Is there any library or ++ classes > for such computations? There are complex functions and generic templates that are part of the standard C++ library. A Google search on "C++ complex numbers" should yield a ton of links. ISO C99 introduces complex types into C also: http://www.gnu.org/software/libc/manual/html_node/Complex-Numbers.html -- Brett From larsl at users.sourceforge.net Tue Dec 13 15:45:56 2005 From: larsl at users.sourceforge.net (Lars Luthman) Date: Tue Dec 13 15:43:48 2005 Subject: [linux-audio-dev] dealing with complex numbers In-Reply-To: <200512132222.28013.artemio@kdemail.net> References: <200512132222.28013.artemio@kdemail.net> Message-ID: <1134506756.7566.8.camel@c213-100-50-8.swipnet.se> On Tue, 2005-12-13 at 22:22 +0200, Artemiy Pavlov wrote: > Hey everybody! > > This may be a little bit off-topic, but can anyone suggest me any reading on > how to use complex numbers in C or C++? Is there any library or ++ classes > for such computations? In C++ you have the template class std::complex in the header file . -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051213/84b6c132/attachment.bin From mle+la at mega-nerd.com Tue Dec 13 16:05:04 2005 From: mle+la at mega-nerd.com (Erik de Castro Lopo) Date: Tue Dec 13 16:05:12 2005 Subject: [linux-audio-dev] dealing with complex numbers In-Reply-To: <200512132222.28013.artemio@kdemail.net> References: <200512132222.28013.artemio@kdemail.net> Message-ID: <20051214080504.7b9557eb.mle+la@mega-nerd.com> Artemiy Pavlov wrote: > Hey everybody! > > This may be a little bit off-topic, but can anyone suggest me any reading on > how to use complex numbers in C or C++? Is there any library or ++ classes > for such computations? In C++: #include which is a template clase. You can then do: typedef std::complex dcomplex ; Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Open Source and Free Software means that you never sacrifice quality of the code for meeting deadlines set up by people not participating directly in the software development process. From taybin at earthlink.net Tue Dec 13 16:26:39 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Tue Dec 13 16:26:49 2005 Subject: [linux-audio-dev] dealing with complex numbers Message-ID: <32270275.1134509199340.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> ISO C99 supports complex as a variable type and the GNU compiler supports that. Taybin -----Original Message----- From: Erik de Castro Lopo Sent: Dec 13, 2005 4:05 PM To: The Linux Audio Developers' Mailing List Subject: Re: [linux-audio-dev] dealing with complex numbers Artemiy Pavlov wrote: > Hey everybody! > > This may be a little bit off-topic, but can anyone suggest me any reading on > how to use complex numbers in C or C++? Is there any library or ++ classes > for such computations? In C++: #include which is a template clase. You can then do: typedef std::complex dcomplex ; Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ Open Source and Free Software means that you never sacrifice quality of the code for meeting deadlines set up by people not participating directly in the software development process. From taybin at earthlink.net Tue Dec 13 16:30:10 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Tue Dec 13 16:30:13 2005 Subject: [linux-audio-dev] dealing with complex numbers Message-ID: <15710719.1134509410793.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> Sorry, meant to include this link: http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Complex.html http://www.gnu.org/software/libc/manual/html_node/Complex-Numbers.html 'nando's C++ usage looked a bit cleaner to me, IMHO. Taybin -----Original Message----- From: Artemiy Pavlov Sent: Dec 13, 2005 3:22 PM To: The Linux Audio Developers' Mailing List Subject: [linux-audio-dev] dealing with complex numbers Hey everybody! This may be a little bit off-topic, but can anyone suggest me any reading on how to use complex numbers in C or C++? Is there any library or ++ classes for such computations? I'd appreciate any help. Thanks! With respect, Artemiy. From taybin at earthlink.net Tue Dec 13 16:32:49 2005 From: taybin at earthlink.net (Taybin Rutkin) Date: Tue Dec 13 16:32:53 2005 Subject: [linux-audio-dev] dealing with complex numbers Message-ID: <7393077.1134509569524.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> And by 'nando, I meant Eric. :/ Taybin -----Original Message----- From: Taybin Rutkin Sent: Dec 13, 2005 4:30 PM To: The Linux Audio Developers' Mailing List , The Linux Audio Developers' Mailing List Subject: Re: [linux-audio-dev] dealing with complex numbers Sorry, meant to include this link: http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Complex.html http://www.gnu.org/software/libc/manual/html_node/Complex-Numbers.html 'nando's C++ usage looked a bit cleaner to me, IMHO. Taybin -----Original Message----- From: Artemiy Pavlov Sent: Dec 13, 2005 3:22 PM To: The Linux Audio Developers' Mailing List Subject: [linux-audio-dev] dealing with complex numbers Hey everybody! This may be a little bit off-topic, but can anyone suggest me any reading on how to use complex numbers in C or C++? Is there any library or ++ classes for such computations? I'd appreciate any help. Thanks! With respect, Artemiy. From b0ef at esben-stien.name Tue Dec 13 22:23:33 2005 From: b0ef at esben-stien.name (Esben Stien) Date: Tue Dec 13 20:29:52 2005 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning In-Reply-To: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> (Jens M. Andreasen's message of "Tue, 13 Dec 2005 04:24:38 +0100") References: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <871x0gicp6.fsf@quasar.esben-stien.name> Jens M Andreasen writes: > Some of you guys might care to take a brief look It's so sad that wikipedia has let us down. We are now required to register to add new pages. I hope there will soon be a fork, cause I'm not going there anymore. Anyone know of any forks of this project or a similar site that offers a truly free wiki encyclopedia?. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From jwoithe at physics.adelaide.edu.au Tue Dec 13 20:40:42 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Tue Dec 13 20:38:33 2005 Subject: [linux-audio-dev] Jackd and cards with multiple PCM interfaces In-Reply-To: <200512131704.jBDH3K7o009934@roar.music.columbia.edu> from "linux-audio-dev-request@music.columbia.edu" at Dec 13, 2005 12:04:14 PM Message-ID: <200512140140.jBE1ehc1025832@auster.physics.adelaide.edu.au> Hi all I am currently working on an ALSA driver enhancement for a card which actually contains two seemingly sample-locked ADCs. I'm making the second ADC accessable via a second PCM interface attached to the card. In general things work fine - under OSS emulaion I can open both (one as /dev/dsp, the other as /dev/adsp). However, jackd doesn't seem to know or care about the second pcm interface on the card and I can't find any obvious way to tell jack about it. It seems suitable entries in .asoundrc might help but it's not clear to me that this will work without xruns (see http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php). Can jackd work with multiple PCMs from the same card, and if so, what's the best way? Regards jonathan From artemio at kdemail.net Wed Dec 14 02:08:12 2005 From: artemio at kdemail.net (Artemiy Pavlov) Date: Wed Dec 14 02:08:48 2005 Subject: [linux-audio-dev] dealing with complex numbers In-Reply-To: <32270275.1134509199340.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> References: <32270275.1134509199340.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> Message-ID: <200512140908.12996.artemio@kdemail.net> Hey everybody, thanks so much for your help! The fact that GCC/Glibc have complex numbers as standard is really cool. Thanks a lot again for the replies! With respect, Artemiy. From yaqtil at gmail.com Wed Dec 14 02:42:36 2005 From: yaqtil at gmail.com (c) Date: Wed Dec 14 02:42:45 2005 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning In-Reply-To: <871x0gicp6.fsf@quasar.esben-stien.name> References: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> <871x0gicp6.fsf@quasar.esben-stien.name> Message-ID: <21e8fdff0512132342n3df53053k7c014f6f71f2836b@mail.gmail.com> > It's so sad that wikipedia has let us down. We are now required to > register to add new pages. I hope there will soon be a fork, cause I'm > not going there anymore. yeah, i had to register to use this mailing list. how do i unsubscribe? what was i thinking... wikipedia is always fairly boring compared to what you can turn up with a yahoogle search. sanitized textbook dreck..if you make a fork let me know i have a few spoons in hiding From yaqtil at gmail.com Wed Dec 14 04:34:25 2005 From: yaqtil at gmail.com (c) Date: Wed Dec 14 04:34:30 2005 Subject: [linux-audio-dev] Jackd and cards with multiple PCM interfaces In-Reply-To: <200512140140.jBE1ehc1025832@auster.physics.adelaide.edu.au> References: <200512131704.jBDH3K7o009934@roar.music.columbia.edu> <200512140140.jBE1ehc1025832@auster.physics.adelaide.edu.au> Message-ID: <21e8fdff0512140134v72a64648k87ea5d506f3dccf4@mail.gmail.com> > Can jackd work with multiple PCMs from the same card, and if so, what's the > best way? jack opens hw:0,0,0 thru hw:0,0,7 on my card. no idea how this would be different from a hw:0,0 thru hw:0,7 or hw:0,0 thru hw:7,0 from a driver standpoint - guess id try making them show up contiguously as a subdevice of a single PCM but you can always use jack_diplomat even if theyre seperate cards entirely.. From aamehl at actcom.net.il Wed Dec 14 06:48:29 2005 From: aamehl at actcom.net.il (Aaron) Date: Wed Dec 14 06:47:43 2005 Subject: [linux-audio-dev] playing ascii? Message-ID: <20051214114829.GQ7606@actcom.net.il> Hi I need help with a conceptual and practical problem. How do you get sync between- audio/midi and ascii text plus notation displayed in a graphical program written in gtk+2? Here is the problem: I have notation is lilypond (www.lilypond.org) in a text editor, either vim emacs jedit or a custom text editor if need be. the audio of that text as midi or wav lets say the same notation displayed Graphically in Denemo (www.denemo.sourceforge.net) The result needed is: 1. to add text in the editor and have them show up graphically, and to add notes graphically and have them show up as text. Also the cursors in the applications should stay in sync. 2. Playback: To have audio playback of the sound either in midi or wav where the cursor in Denemo and the text editor stay in synce, and scroll karoke style. 2a. Have a scrub feature where a specific measure or set of notes can be played either from the ascii text or the graphic notation in Denemo. ------------------------------------------- So first conceptually how can this be acheived? Can I use a preexisting text editor such as VIM, Emacs or Jedit or must I create my own to acheive this? What libs scripts apps would help ease the implementation of the above. Is this a reasonable feature to hope to implement? And if it isn't, how could it be done anyways. thanks Aaron From loki.davison at gmail.com Wed Dec 14 09:43:33 2005 From: loki.davison at gmail.com (Loki Davison) Date: Wed Dec 14 09:43:37 2005 Subject: [linux-audio-dev] Re: playing ascii? In-Reply-To: <20051214114829.GQ7606@actcom.net.il> References: <20051214114829.GQ7606@actcom.net.il> Message-ID: > ------------------------------------------- > So first conceptually how can this be acheived? > > Can I use a preexisting text editor such as VIM, Emacs or Jedit or > must I create my own to acheive this? > > What libs scripts apps would help ease the implementation of the > above. > > Is this a reasonable feature to hope to implement? And if it isn't, > how could it be done anyways. > Sounds like an interesting project, both for writing lyrics and singing along. I'm pretty sure something like this would be doable interfacing with emacs or you could include the ktext widget in your app, i.e the one from kate, etc. It's designed to be embedded and might do the job, but i don't know how scriptable it is. Loki From aamehl at actcom.net.il Wed Dec 14 11:34:45 2005 From: aamehl at actcom.net.il (Aaron) Date: Wed Dec 14 11:34:04 2005 Subject: [linux-audio-dev] Re: playing ascii? In-Reply-To: References: <20051214114829.GQ7606@actcom.net.il> Message-ID: <20051214163445.GU7606@actcom.net.il> * Loki Davison [051214 18:27]: > > ------------------------------------------- > > So first conceptually how can this be acheived? > > > > Can I use a preexisting text editor such as VIM, Emacs or Jedit or > > must I create my own to acheive this? > > > > What libs scripts apps would help ease the implementation of the > > above. > > > > Is this a reasonable feature to hope to implement? And if it isn't, > > how could it be done anyways. > > > > Sounds like an interesting project, both for writing lyrics and > singing along. I'm pretty sure something like this would be doable > interfacing with emacs or you could include the ktext widget in your > app, i.e the one from kate, etc. It's designed to be embedded and > might do the job, but i don't know how scriptable it is. > wow, I wasn't talking about lyrics at all but you are right that would be neat. in lilypond a measure of 4/4 a'4 a' b'8 b' c'' | would need to synce with the graphic notation. Aaron > Loki From loki.davison at gmail.com Wed Dec 14 11:53:04 2005 From: loki.davison at gmail.com (Loki Davison) Date: Wed Dec 14 11:53:06 2005 Subject: [linux-audio-dev] Re: playing ascii? In-Reply-To: <20051214163445.GU7606@actcom.net.il> References: <20051214114829.GQ7606@actcom.net.il> <20051214163445.GU7606@actcom.net.il> Message-ID: On 12/15/05, Aaron wrote: > * Loki Davison [051214 18:27]: > > > ------------------------------------------- > > > So first conceptually how can this be acheived? > > > > > > Can I use a preexisting text editor such as VIM, Emacs or Jedit or > > > must I create my own to acheive this? > > > > > > What libs scripts apps would help ease the implementation of the > > > above. > > > > > > Is this a reasonable feature to hope to implement? And if it isn't, > > > how could it be done anyways. > > > > > > > Sounds like an interesting project, both for writing lyrics and > > singing along. I'm pretty sure something like this would be doable > > interfacing with emacs or you could include the ktext widget in your > > app, i.e the one from kate, etc. It's designed to be embedded and > > might do the job, but i don't know how scriptable it is. > > > > wow, I wasn't talking about lyrics at all but you are right that would > be neat. > > > in lilypond a measure of 4/4 > > a'4 a' b'8 b' c'' | > would need to synce with the graphic notation. > > Aaron > > > > Loki > ;-) the positives of me not getting what you where talking about Loki From James at superbug.co.uk Wed Dec 14 12:38:57 2005 From: James at superbug.co.uk (James Courtier-Dutton) Date: Wed Dec 14 12:39:01 2005 Subject: [linux-audio-dev] playing ascii? In-Reply-To: <20051214114829.GQ7606@actcom.net.il> References: <20051214114829.GQ7606@actcom.net.il> Message-ID: <43A058B1.4090904@superbug.co.uk> Aaron wrote: > Hi > I need help with a conceptual and practical problem. > > How do you get sync between- audio/midi and ascii text plus notation > displayed in a graphical program written in gtk+2? > > Here is the problem: > > I have notation is lilypond (www.lilypond.org) in a text editor, either vim emacs jedit > or a custom text editor if need be. > > the audio of that text as midi or wav lets say > > the same notation displayed Graphically in Denemo > (www.denemo.sourceforge.net) > > > The result needed is: > 1. > to add text in the editor and have them show up graphically, and to > add notes graphically and have them show up as text. > > Also the cursors in the applications should stay in sync. > > 2. > Playback: > To have audio playback of the sound either in midi or wav where the > cursor in Denemo and the text editor stay in synce, and scroll karoke > style. > > 2a. Have a scrub feature where a specific measure or set of notes can > be played either from the ascii text or the graphic notation in > Denemo. > > > ------------------------------------------- > So first conceptually how can this be acheived? > > Can I use a preexisting text editor such as VIM, Emacs or Jedit or > must I create my own to acheive this? > > What libs scripts apps would help ease the implementation of the > above. > > Is this a reasonable feature to hope to implement? And if it isn't, > how could it be done anyways. > > thanks > > Aaron > > > I can help from a sync point of view. You use a global clock. i.e. the clock you can get form the midi device, or get_time_of_day() You then sync each stream of information to the global clock. That is generally quite easy to do. A by-product of that, is all the streams then appear synced together, although that is not how you implement it. James From rlrevell at joe-job.com Wed Dec 14 13:04:16 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Dec 14 13:06:08 2005 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning In-Reply-To: <871x0gicp6.fsf@quasar.esben-stien.name> References: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> <871x0gicp6.fsf@quasar.esben-stien.name> Message-ID: <1134583456.12086.22.camel@mindpipe> On Wed, 2005-12-14 at 04:23 +0100, Esben Stien wrote: > Jens M Andreasen writes: > > > Some of you guys might care to take a brief look > > It's so sad that wikipedia has let us down. We are now required to > register to add new pages. I hope there will soon be a fork, cause I'm > not going there anymore. Um, they had a very good reason. People were using the site to anonymously slander others. Lee From rlrevell at joe-job.com Wed Dec 14 13:06:07 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Dec 14 13:06:10 2005 Subject: [linux-audio-dev] Jackd and cards with multiple PCM interfaces In-Reply-To: <200512140140.jBE1ehc1025832@auster.physics.adelaide.edu.au> References: <200512140140.jBE1ehc1025832@auster.physics.adelaide.edu.au> Message-ID: <1134583568.12086.25.camel@mindpipe> On Wed, 2005-12-14 at 12:10 +1030, Jonathan Woithe wrote: > Hi all > > I am currently working on an ALSA driver enhancement for a card which > actually contains two seemingly sample-locked ADCs. I'm making the second > ADC accessable via a second PCM interface attached to the card. > > In general things work fine - under OSS emulaion I can open both (one as > /dev/dsp, the other as /dev/adsp). However, jackd doesn't seem to know > or care about the second pcm interface on the card and I can't find any > obvious way to tell jack about it. It seems suitable entries in .asoundrc > might help but it's not clear to me that this will work without xruns > (see http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php). > > Can jackd work with multiple PCMs from the same card, and if so, what's the > best way? Well, does the hardware have a mechanism to stop and start them in sync? If so you could modify the driver to expose all the channels as a big multichannel PCM like I did with the emu10k1 driver. Lee From luisgarrido at users.sourceforge.net Wed Dec 14 13:08:39 2005 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Wed Dec 14 13:08:49 2005 Subject: [linux-audio-dev] playing ascii? In-Reply-To: <20051214114829.GQ7606@actcom.net.il> References: <20051214114829.GQ7606@actcom.net.il> Message-ID: I did a video player http://xjadeo.sourceforge.net/ that syncs to audio using jack transport: http://jackit.sourceforge.net/docs/reference/html/transport-design.html The basic idea is to poll jack transport at a certain frequency (10-20times per second) and update your visual stuff accordingly. Regards, Luis From tim at pluginz.com Wed Dec 14 13:19:04 2005 From: tim at pluginz.com (Tim Orford) Date: Wed Dec 14 13:24:53 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <85mzj7z227.fsf@lola.goethe.zz> References: <857jacwres.fsf@lola.goethe.zz> <200512111506.08188.tito@rumford.de> <85mzj7z227.fsf@lola.goethe.zz> Message-ID: <20051214181904.GC13025@tim.gateway.2wire.net> On Sun, Dec 11, 2005 at 11:44:32PM +0100, David Kastrup wrote: > >> Ok, and here is the rub: playback is not perfect, and neither seems > >> to be the sampling. Probably at times error interpolation sets in, > >> probably at times samples get lost or replicated. Not much, perhaps > >> once per minute or so. This leads to audible clicks, of course. xruns? do you still get the clicks when the card is in loop-back mode? (this will completely bypass the OS and all driver or xrun issues) > So there is already something going on which I don't understand. In > "crackle mode", there is basically just noise, but the noise level is > correlated with the amplitude of the sound source. This sounds like you might possibly be a victim of a known bug on this hardware. Try changing the "IEC958 In Phase Inverse" switch. > So what would one actually have to do to have the "incoming spdif > clock" respected? There is nothing to set on this card. It automatically syncs to the incoming spdif when this input is selected. cheers -- Tim Orford From aamehl at actcom.net.il Wed Dec 14 13:37:41 2005 From: aamehl at actcom.net.il (Aaron) Date: Wed Dec 14 13:37:00 2005 Subject: [linux-audio-dev] playing ascii? In-Reply-To: <43A058B1.4090904@superbug.co.uk> References: <20051214114829.GQ7606@actcom.net.il> <43A058B1.4090904@superbug.co.uk> Message-ID: <20051214183740.GW7606@actcom.net.il> > I can help from a sync point of view. > You use a global clock. i.e. the clock you can get form the midi device, or get_time_of_day() > JACK? > You then sync each stream of information to the global clock. > That is generally quite easy to do. > A by-product of that, is all the streams then appear synced together, although that is not how you > implement it. > Does it matter what text editor is used? Also this is just the playback issue right? how do we acheive the text and graphical notes updating each other? Aaron > James From aamehl at actcom.net.il Wed Dec 14 13:43:57 2005 From: aamehl at actcom.net.il (Aaron) Date: Wed Dec 14 13:43:14 2005 Subject: [linux-audio-dev] playing ascii? In-Reply-To: References: <20051214114829.GQ7606@actcom.net.il> Message-ID: <20051214184356.GX7606@actcom.net.il> * Luis Garrido [051214 20:38]: > I did a video player > http://xjadeo.sourceforge.net/ > that syncs to audio using jack transport: > http://jackit.sourceforge.net/docs/reference/html/transport-design.html > The basic idea is to poll jack transport at a certain frequency (10-20times per second) and update your visual stuff accordingly. Yes I heard of this option, the question is the text editor part, so that the cursor in a text editor syncs with midi and denemo. Aaron > Regards, > Luis From dak at gnu.org Wed Dec 14 14:01:25 2005 From: dak at gnu.org (David Kastrup) Date: Wed Dec 14 14:01:27 2005 Subject: [linux-audio-dev] Merging digital sampling sessions In-Reply-To: <20051214181904.GC13025@tim.gateway.2wire.net> (Tim Orford's message of "Wed, 14 Dec 2005 18:19:04 +0000") References: <857jacwres.fsf@lola.goethe.zz> <200512111506.08188.tito@rumford.de> <85mzj7z227.fsf@lola.goethe.zz> <20051214181904.GC13025@tim.gateway.2wire.net> Message-ID: <85r78fijui.fsf@lola.goethe.zz> Tim Orford writes: > On Sun, Dec 11, 2005 at 11:44:32PM +0100, David Kastrup wrote: >> >> Ok, and here is the rub: playback is not perfect, and neither seems >> >> to be the sampling. Probably at times error interpolation sets in, >> >> probably at times samples get lost or replicated. Not much, perhaps >> >> once per minute or so. This leads to audible clicks, of course. > > xruns? None. > do you still get the clicks when the card is in loop-back mode? I think, occasionally. This can also partly (though not completely) be a problem of the signal source. Whatever the source of the problem, it would be easy enough to rectify it using multiple passes. >> So there is already something going on which I don't understand. In >> "crackle mode", there is basically just noise, but the noise level is >> correlated with the amplitude of the sound source. > > This sounds like you might possibly be a victim of a known bug on > this hardware. Try changing the "IEC958 In Phase Inverse" switch. Of course, I tried that. IIRC it might possibly changes the overall sound of the noise, but does not change it from being noise. And once the card is in working mode, I don't think it makes a difference. >> So what would one actually have to do to have the "incoming spdif >> clock" respected? > > There is nothing to set on this card. It automatically syncs to the > incoming spdif when this input is selected. Ok, thanks. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From indigo at bitglue.com Wed Dec 14 14:06:47 2005 From: indigo at bitglue.com (Phil Frost) Date: Wed Dec 14 14:06:58 2005 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning In-Reply-To: <1134583456.12086.22.camel@mindpipe> References: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> <871x0gicp6.fsf@quasar.esben-stien.name> <1134583456.12086.22.camel@mindpipe> Message-ID: <20051214190646.GB14568@unununium.org> On Wed, Dec 14, 2005 at 01:04:16PM -0500, Lee Revell wrote: > On Wed, 2005-12-14 at 04:23 +0100, Esben Stien wrote: > > Jens M Andreasen writes: > > > > > Some of you guys might care to take a brief look > > > > It's so sad that wikipedia has let us down. We are now required to > > register to add new pages. I hope there will soon be a fork, cause I'm > > not going there anymore. > > Um, they had a very good reason. People were using the site to > anonymously slander others. Libel, not slander :) Also, there is the issue of general wiki spam, posting crap, advertisements, etc. From ce at christeck.de Wed Dec 14 15:33:18 2005 From: ce at christeck.de (Christoph Eckert) Date: Wed Dec 14 15:32:22 2005 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning In-Reply-To: <871x0gicp6.fsf@quasar.esben-stien.name> References: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> <871x0gicp6.fsf@quasar.esben-stien.name> Message-ID: <200512142133.18789.ce@christeck.de> > It's so sad that wikipedia has let us down. We are now required to > register to add new pages. I'm still allowed to edit pages without registration as well as I can do so in the german Wikipedia (though I have a login for the german one, because only registered users are allowed to add media files). I agree that registering is a pain, but due to todays spammers who flood any free forum it's an annoying but necessary step. Best regards ce From rlrevell at joe-job.com Wed Dec 14 17:12:14 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Dec 14 17:13:52 2005 Subject: [linux-audio-dev] OT: Wikipedia, FM and John Chowning In-Reply-To: <200512142133.18789.ce@christeck.de> References: <1134444278.9097.6.camel@c80-216-124-251.cm-upc.chello.se> <871x0gicp6.fsf@quasar.esben-stien.name> <200512142133.18789.ce@christeck.de> Message-ID: <1134598335.12086.64.camel@mindpipe> On Wed, 2005-12-14 at 21:33 +0100, Christoph Eckert wrote: > > It's so sad that wikipedia has let us down. We are now required to > > register to add new pages. > > I'm still allowed to edit pages without registration as well as I can do > so in the german Wikipedia (though I have a login for the german one, > because only registered users are allowed to add media files). > > I agree that registering is a pain, but due to todays spammers who flood > any free forum it's an annoying but necessary step. The spam problem can theoretically be solved on a technical level. I don't think the libel problem can. Lee From pcoccoli at gmail.com Wed Dec 14 17:18:00 2005 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Dec 14 17:18:04 2005 Subject: [linux-audio-dev] playing ascii? In-Reply-To: <20051214114829.GQ7606@actcom.net.il> References: <20051214114829.GQ7606@actcom.net.il> Message-ID: <8d27a0610512141418y6a2e0f2labdbdb107b631687@mail.gmail.com> On 12/14/05, Aaron wrote: > Hi > I need help with a conceptual and practical problem. > > How do you get sync between- audio/midi and ascii text plus notation > displayed in a graphical program written in gtk+2? > > Here is the problem: > > I have notation is lilypond (www.lilypond.org) in a text editor, either vim emacs jedit > or a custom text editor if need be. > > the audio of that text as midi or wav lets say > > the same notation displayed Graphically in Denemo > (www.denemo.sourceforge.net) > > > The result needed is: > 1. > to add text in the editor and have them show up graphically, and to > add notes graphically and have them show up as text. > > Also the cursors in the applications should stay in sync. > > 2. > Playback: > To have audio playback of the sound either in midi or wav where the > cursor in Denemo and the text editor stay in synce, and scroll karoke > style. > > 2a. Have a scrub feature where a specific measure or set of notes can > be played either from the ascii text or the graphic notation in > Denemo. > > > ------------------------------------------- > So first conceptually how can this be acheived? > > Can I use a preexisting text editor such as VIM, Emacs or Jedit or > must I create my own to acheive this? > > What libs scripts apps would help ease the implementation of the > above. > > Is this a reasonable feature to hope to implement? And if it isn't, > how could it be done anyways. > > thanks > > Aaron > > I would suggest looking into the Model-View-Controller (MVC) pattern. >From what you describe, you want multiple views of the same data, each updated in real time if you edit one of them. I doubt there are many existing tools that would be useful for this, but like someone else mentioned you could probably re-use and existing text editor widget for the text view. I don't know of any text editors that let you reposition the cursor from another process (like over a local socket or something), but it's possible some exist. From aamehl at actcom.net.il Wed Dec 14 18:35:56 2005 From: aamehl at actcom.net.il (Aaron) Date: Wed Dec 14 18:35:22 2005 Subject: [linux-audio-dev] playing ascii? In-Reply-To: <8d27a0610512141418y6a2e0f2labdbdb107b631687@mail.gmail.com> References: <20051214114829.GQ7606@actcom.net.il> <8d27a0610512141418y6a2e0f2labdbdb107b631687@mail.gmail.com> Message-ID: <20051214233556.GB7606@actcom.net.il> > I would suggest looking into the Model-View-Controller (MVC) pattern. > >From what you describe, you want multiple views of the same data, each > updated in real time if you edit one of them. > > I doubt there are many existing tools that would be useful for this, > but like someone else mentioned you could probably re-use and existing > text editor widget for the text view. I don't know of any text > editors that let you reposition the cursor from another process (like > over a local socket or something), but it's possible some exist. Again I am getting the the idea for playback issues but what about ascii to graphic updates so that a c''4 written in a text editor will display as a third space quarter note on treble staff- and a third space quarter note in denemo will appear in the text editor as c''4? thanks Aaron From brinkman at math.TU-Berlin.DE Wed Dec 14 18:51:16 2005 From: brinkman at math.TU-Berlin.DE (Peter Brinkmann) Date: Wed Dec 14 18:51:22 2005 Subject: [linux-audio-dev] ALSA MIDI Sync In-Reply-To: <20051213090228.GA23750@turing.informatik.uni-halle.de> References: <20051210015215.GA4655@fuchs.math.tu-berlin.de> <20051213090228.GA23750@turing.informatik.uni-halle.de> Message-ID: <20051214235116.GF6019@fuchs.math.tu-berlin.de> Clemens, Alexandre, Thanks for your replies! > ALSA itself doesn't support any synchronization protocol; the only > possible timer source is some hardware timer interrupt. Ah, that would explain the lack of documented sync features;) Are there any plans to implement any sync protocols in ALSA? This seems like a fairly significant omission. Best, Peter From pcoccoli at gmail.com Wed Dec 14 21:57:40 2005 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Dec 14 21:57:51 2005 Subject: [linux-audio-dev] playing ascii? In-Reply-To: <20051214233556.GB7606@actcom.net.il> References: <20051214114829.GQ7606@actcom.net.il> <8d27a0610512141418y6a2e0f2labdbdb107b631687@mail.gmail.com> <20051214233556.GB7606@actcom.net.il> Message-ID: <8d27a0610512141857n78a5d0a9y15c842df347d16bb@mail.gmail.com> On 12/14/05, Aaron wrote: > > > I would suggest looking into the Model-View-Controller (MVC) pattern. > > >From what you describe, you want multiple views of the same data, each > > updated in real time if you edit one of them. > > > > I doubt there are many existing tools that would be useful for this, > > but like someone else mentioned you could probably re-use and existing > > text editor widget for the text view. I don't know of any text > > editors that let you reposition the cursor from another process (like > > over a local socket or something), but it's possible some exist. > > Again I am getting the the idea for playback issues but what about > ascii to graphic updates so that a c''4 written in a text editor will > display as a third space quarter note on treble staff- and a third > space quarter note in denemo will appear in the text editor as c''4? > > > thanks > Aaron > Read my message again. Especially the first paragraph. From jwoithe at physics.adelaide.edu.au Wed Dec 14 22:47:22 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Wed Dec 14 22:45:24 2005 Subject: [linux-audio-dev] Jackd and cards with multiple PCM interfaces In-Reply-To: <1134583568.12086.25.camel@mindpipe> from "Lee Revell" at Dec 14, 2005 01:06:07 PM Message-ID: <200512150347.jBF3lMUE012605@auster.physics.adelaide.edu.au> Lee > > I am currently working on an ALSA driver enhancement for a card which > > actually contains two seemingly sample-locked ADCs. I'm making the second > > ADC accessable via a second PCM interface attached to the card. > > > > In general things work fine - under OSS emulaion I can open both (one as > > /dev/dsp, the other as /dev/adsp). However, jackd doesn't seem to know > > or care about the second pcm interface on the card and I can't find any > > obvious way to tell jack about it. It seems suitable entries in .asoundrc > > might help but it's not clear to me that this will work without xruns > > (see http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php). > > > > Can jackd work with multiple PCMs from the same card, and if so, what's the > > best way? > > Well, does the hardware have a mechanism to stop and start them in sync? I'll have to check this. The ADCs are independent in that they *can* be operated concurrently with different parameters. However, AFAIK they both operate off the same master clock signal and thus will sample simultaneously if both are sampling at the same nominal rate. As to whether they can both be *started* simultaneously in hardware I can't say at present. That may be a stumbling block. > If so you could modify the driver to expose all the channels as a big > multichannel PCM like I did with the emu10k1 driver. Thanks for the pointer - I'll check it out; I looked in a few other drivers for clues but obviously picked the wrong ones. Regards jonathan From pcoccoli at gmail.com Wed Dec 14 23:26:34 2005 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Dec 14 23:26:47 2005 Subject: [linux-audio-dev] "declicking" algorithm? Message-ID: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> Here's a poorly written description of my problem (the code in question is written from scratch in C++, BTW): I have a simple gain function that takes a number between 0 and 1 and multiplies each input sample by that number. If I use the output of an LFO to get that gain number, I gets clicks in my output (presumably on when the LFO output changes by and number close to 1, as it would with a pulse/square wave). How can I get rid of these clicks? Do I need to "smooth" the output of the LFO, or my processed output? If so, what is a good way to do that? On a semi-related note, can someone recommend any Free libraries in C or C++ that implement things like oscillators, filters, etc.? From letz at grame.fr Thu Dec 15 04:16:03 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Thu Dec 15 04:17:03 2005 Subject: [linux-audio-dev] "declicking" algorithm? In-Reply-To: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> References: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> Message-ID: Le 15 d?c. 05 ? 05:26, Paul Coccoli a ?crit : > Here's a poorly written description of my problem (the code in > question is written from scratch in C++, BTW): > > I have a simple gain function that takes a number between 0 and 1 and > multiplies each input sample by that number. If I use the output of > an LFO to get that gain number, I gets clicks in my output (presumably > on when the LFO output changes by and number close to 1, as it would > with a pulse/square wave). How can I get rid of these clicks? Do I > need to "smooth" the output of the LFO, or my processed output? If > so, what is a good way to do that? > > On a semi-related note, can someone recommend any Free libraries in C > or C++ that implement things like oscillators, filters, etc.? You may have a look at Faust, a dsp to C++ compiler : http:// faudiostream.sourceforge.net/ Regards Stephane Letz From indigo at bitglue.com Thu Dec 15 10:21:51 2005 From: indigo at bitglue.com (Phil Frost) Date: Thu Dec 15 10:22:02 2005 Subject: [linux-audio-dev] "declicking" algorithm? In-Reply-To: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> References: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> Message-ID: <20051215152151.GA2598@unununium.org> On Wed, Dec 14, 2005 at 11:26:34PM -0500, Paul Coccoli wrote: > Here's a poorly written description of my problem (the code in > question is written from scratch in C++, BTW): > > I have a simple gain function that takes a number between 0 and 1 and > multiplies each input sample by that number. If I use the output of > an LFO to get that gain number, I gets clicks in my output (presumably > on when the LFO output changes by and number close to 1, as it would > with a pulse/square wave). How can I get rid of these clicks? Do I > need to "smooth" the output of the LFO, or my processed output? If > so, what is a good way to do that? > > On a semi-related note, can someone recommend any Free libraries in C > or C++ that implement things like oscillators, filters, etc.? You could smooth either; it depends on what sound you want. If you want to change only the amplitude, but not the timbre of your output, your only option is to smooth the gain input. However, filters on the output could have a desirable musical effect, too. One way to "smooth" your gain input is to write an LFO that does not this: ___ __ | | | __| |___| but rather this: ___ __ / \ / __/ \___/ Another solution is to put either your gain input, or the final output through something like a lowpass filter. An easy and efficient way to implement one of these is called an "IIR" (Infinite Impulse Response) filter, which involves calculating the next output by multiplying some number of the previous inputs and outputs by some (usually constant) coeficients and summing them. A google search for various combinations of "IIR", "filter", and "DSP" should help you find some useful documentation. Remember, for any problem, there are many solutions. When dealing with music, (i'm assuming you are making music here) often trying your own solutions and algorithms will lead to interesting sounds you did not expect. Read about DSP and established algorithms, but never be afraid to try your own. From dlphillips at woh.rr.com Thu Dec 15 10:44:41 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu Dec 15 10:27:23 2005 Subject: [linux-audio-dev] Wine asking for feedback on Audio needs [redirected from LAU] In-Reply-To: <43A05CAA.7090705@tiscali.co.uk> References: <43A05CAA.7090705@tiscali.co.uk> Message-ID: <43A18F69.50200@woh.rr.com> This message appeared recently on the LAU list. On the chance that there may be developers here who have an interest : guy wrote: > According to wine weekly news (lhttp://www.winehq.com/?issue=301) the > wine project is asking for feedback on its handling of audio. If I > can quote: > > /Alexandre mentioned there were some new changes for better audio > driver management in winecfg. That work has been done by Robert Reif > and this week he asked if anyone could give him some feedback > regarding the lesser used (and more broken) audio drivers:/ > > /Is anyone using the arts, esound or jack sound drivers for non > trivial use? By non trivial, I mean more than one application or more > than a single device. If so, I am interested in getting information on > the software you are using and how it is using the drivers. / > > /Would redesigning these drivers to show up as a single device per > physical device which allowed being opened more than once be a problem?/ > > I am sure there are people on this list who know what they are > talking about ( & I exclude myself from that!) who could really speak > up for the requirements for serious audio work & wine. > > cheers > > Guy > > From asbjs at stud.ntnu.no Thu Dec 15 10:56:04 2005 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Thu Dec 15 10:56:15 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? Message-ID: <20051215155604.GA465@stud.ntnu.no> Some colleauges of mine do need a tool for coding and decoding of high-order Ambisonic for their research. They are aiming for seventh order, played back over sixteen loudspeakers. They are now planning to implement this, using either JACK or LADSPA. As I have some experience with linux audio, I got involved. So I am seeking some advice and answers here. The first thing I would like to know is: Does anything like this already exist? (I think there are some LDASPA plugins for Ambisonic, but I am not aware of how high order these are.) Secondly, what would be the better choice, JACK or LADSPA? We are probably going to need som GUI on it, to configure the thing. And we would like to have the flexibility to alter the coding/decoding coefficients, turn on/off some filtering and so on. With kind regards Asbj?rn From S.W.Harris at ecs.soton.ac.uk Thu Dec 15 11:09:04 2005 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Dec 15 11:09:18 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? In-Reply-To: <20051215155604.GA465@stud.ntnu.no> References: <20051215155604.GA465@stud.ntnu.no> Message-ID: <20051215160904.GL8448@login.ecs.soton.ac.uk> On Thu, Dec 15, 2005 at 04:56:04 +0100, Asbj?rn S?b? wrote: > Secondly, what would be the better choice, JACK or LADSPA? We are > probably going to need som GUI on it, to configure the thing. And we > would like to have the flexibility to alter the coding/decoding > coefficients, turn on/off some filtering and so on. A better choice would be DSSI or JACK, LADSPA doesnt really support GUIs. I wouldn't like to say which will be better, JACK is probably easier, but DSSI is more flexible (you can run the plugin as a standale jack app as well as a plugin). - Steve From dmills at spamblock.demon.co.uk Thu Dec 15 11:43:31 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Thu Dec 15 11:44:05 2005 Subject: [linux-audio-dev] "declicking" algorithm? In-Reply-To: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> References: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> Message-ID: <200512151643.31935.dmills@spamblock.demon.co.uk> On Thursday 15 December 2005 04:26, Paul Coccoli wrote: > Here's a poorly written description of my problem (the code in > question is written from scratch in C++, BTW): > > I have a simple gain function that takes a number between 0 and 1 and > multiplies each input sample by that number. If I use the output of > an LFO to get that gain number, I gets clicks in my output (presumably > on when the LFO output changes by and number close to 1, as it would > with a pulse/square wave). How can I get rid of these clicks? Do I > need to "smooth" the output of the LFO, or my processed output? If > so, what is a good way to do that? I assume that this happens with fast edges on the output of the LFO (like say square waves), if so it is aliasing due to the fact that the LFO contains components which when mixed with the audio fall outside the nyquest limit of bandwidth <0.5 * sample rate. You should use a band limited LFO or otherwise filter the control signal to keep the mixing products from the multiplier within the nyquest limit. Filtering can work, but it needs to be quite high order to get the highest frequency component down far enough, and that introduces problems of its own, mainly phase shifts and overshoot. I would note that rolling the audio off at say 15K or so gives you much more available control bandwidth then going over at 22K does (in a 44.1Khz system), as in general the sum of the highest audio frequency and the highest frequency on the control line must obey the nyquest limit. > On a semi-related note, can someone recommend any Free libraries in C > or C++ that implement things like oscillators, filters, etc.? LibDSP? Also some good stuff in gnuRadio. Regards, Dan. From paul at linuxaudiosystems.com Thu Dec 15 11:59:02 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Dec 15 11:57:02 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? In-Reply-To: <20051215160904.GL8448@login.ecs.soton.ac.uk> References: <20051215155604.GA465@stud.ntnu.no> <20051215160904.GL8448@login.ecs.soton.ac.uk> Message-ID: <1134665943.7539.33.camel@localhost.localdomain> On Thu, 2005-12-15 at 16:09 +0000, Steve Harris wrote: > On Thu, Dec 15, 2005 at 04:56:04 +0100, Asbj?rn S?b? wrote: > > Secondly, what would be the better choice, JACK or LADSPA? We are > > probably going to need som GUI on it, to configure the thing. And we > > would like to have the flexibility to alter the coding/decoding > > coefficients, turn on/off some filtering and so on. > > A better choice would be DSSI or JACK, LADSPA doesnt really support GUIs. > > I wouldn't like to say which will be better, JACK is probably easier, but > DSSI is more flexible (you can run the plugin as a standale jack app as > well as a plugin). plus it would really, really push the developers of ardour to finally support DSSI. :) --p From artemio at kdemail.net Thu Dec 15 12:31:50 2005 From: artemio at kdemail.net (Artemiy Pavlov) Date: Thu Dec 15 12:32:06 2005 Subject: [linux-audio-dev] "declicking" algorithm? In-Reply-To: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> References: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> Message-ID: <200512151931.50439.artemio@kdemail.net> Hello, when I made my very first saw and square LFOs I got the same problem as you - clicks caused by fast (single-sample) changes of LFO output value - these happen once in a saw cycle and twice for a square cycle. What I did is make the LFO forms smoother, to have a soft knee. Such a method for a saw wave, for example, means it grows from 0 to 1 in 1/20 of the perioud and then decays from 1 to 0 in the rest 19/20 of the period. I can send you the C code if you need, it implements basic LFO functions using very simple math. I hope this helps. Artemiy. From indigo at bitglue.com Thu Dec 15 13:06:58 2005 From: indigo at bitglue.com (Phil Frost) Date: Thu Dec 15 13:07:05 2005 Subject: [linux-audio-dev] "declicking" algorithm? In-Reply-To: <200512151643.31935.dmills@spamblock.demon.co.uk> References: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> <200512151643.31935.dmills@spamblock.demon.co.uk> Message-ID: <20051215180658.GA20461@unununium.org> On Thu, Dec 15, 2005 at 04:43:31PM +0000, Dan Mills wrote: > On Thursday 15 December 2005 04:26, Paul Coccoli wrote: > > Here's a poorly written description of my problem (the code in > > question is written from scratch in C++, BTW): > > > > I have a simple gain function that takes a number between 0 and 1 and > > multiplies each input sample by that number. If I use the output of > > an LFO to get that gain number, I gets clicks in my output (presumably > > on when the LFO output changes by and number close to 1, as it would > > with a pulse/square wave). How can I get rid of these clicks? Do I > > need to "smooth" the output of the LFO, or my processed output? If > > so, what is a good way to do that? > > > I assume that this happens with fast edges on the output of the LFO (like say > square waves), if so it is aliasing due to the fact that the LFO contains > components which when mixed with the audio fall outside the nyquest limit of > bandwidth <0.5 * sample rate. > > You should use a band limited LFO or otherwise filter the control signal to > keep the mixing products from the multiplier within the nyquest limit. > > Filtering can work, but it needs to be quite high order to get the highest > frequency component down far enough, and that introduces problems of its own, > mainly phase shifts and overshoot. > > I would note that rolling the audio off at say 15K or so gives you much more > available control bandwidth then going over at 22K does (in a 44.1Khz > system), as in general the sum of the highest audio frequency and the highest > frequency on the control line must obey the nyquest limit. > > [...] There is truth in what you say, but given the problem described, this is likely more confusing than helpful to someone new to signal processing. If the problem is that the input is a low frequency square wave, from a Low Frequency Oscilator, the popping has nothing to do with the "nyquest" limit. If the square wave were coming from an ideal source (which it isn't) then any higher frequency components likely would be so small as to be smaller than the quantization error. The problem is simply that it contains high frequency components (under the limit), or more intuitively, a sudden drop or rise. Drop or rise more slowly, and the pops go away. There is no need here for a high order filter here, and no risk of phase shifts or overshoot. A simple first order lowpass filter will be quite effective, as will any other simple techniques such as averaging or changing the LFO function to put more slope on the rising and falling edges. From rlrevell at joe-job.com Thu Dec 15 13:23:03 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 15 13:20:27 2005 Subject: [linux-audio-dev] Wine asking for feedback on Audio needs [redirected from LAU] In-Reply-To: <43A18F69.50200@woh.rr.com> References: <43A05CAA.7090705@tiscali.co.uk> <43A18F69.50200@woh.rr.com> Message-ID: <1134670984.12086.134.camel@mindpipe> On Thu, 2005-12-15 at 10:44 -0500, Dave Phillips wrote: > This message appeared recently on the LAU list. On the chance that there > may be developers here who have an interest : Um, Paul Davis and others already tried to help him, and his response was basically "I don't understand so I give up". Lee From dmills at spamblock.demon.co.uk Thu Dec 15 13:45:07 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Thu Dec 15 13:45:14 2005 Subject: [linux-audio-dev] "declicking" algorithm? In-Reply-To: <20051215180658.GA20461@unununium.org> References: <8d27a0610512142026i3086271t8381ebb98479c557@mail.gmail.com> <200512151643.31935.dmills@spamblock.demon.co.uk> <20051215180658.GA20461@unununium.org> Message-ID: <200512151845.07323.dmills@spamblock.demon.co.uk> On Thursday 15 December 2005 18:06, Phil Frost wrote: > There is truth in what you say, but given the problem described, this is > likely more confusing than helpful to someone new to signal processing. > > If the problem is that the input is a low frequency square wave, from a > Low Frequency Oscilator, the popping has nothing to do with the > "nyquest" limit. If the square wave were coming from an ideal source > (which it isn't) then any higher frequency components likely would be so > small as to be smaller than the quantization error. The thing is that a LFO implemented as part of a plugin is an ideal source for all practical purposes, it can and does do a step change in sample value (for the nieve squarewave case) which if the LFO is running at 20Hz gives the level of the 1001st harmonic as 1/1001 that of the fundamental, or some 60db down. Low but hardly buried in the nose, as the mixing products will not be harmonically related to either signal. > The problem is simply that it contains high frequency components (under > the limit), or more intuitively, a sudden drop or rise. Drop or rise > more slowly, and the pops go away. Does hooking the LFO output directly to a speaker click, if so this is the problem, but if it only acts up when multiplied with another signal then I still maintain that it is mixer products aliasing that is the problem. > There is no need here for a high order filter here, and no risk of phase > shifts or overshoot. A simple first order lowpass filter will be quite > effective, as will any other simple techniques such as averaging or > changing the LFO function to put more slope on the rising and falling > edges. Also the OP probably needs to make the rate of change continuous as that can also cause a click. Regards, Dan. From fons.adriaensen at skynet.be Thu Dec 15 14:33:34 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Thu Dec 15 14:28:03 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? In-Reply-To: <20051215155604.GA465@stud.ntnu.no> References: <20051215155604.GA465@stud.ntnu.no> Message-ID: <20051215193334.GA4739@linux-1> On Thu, Dec 15, 2005 at 04:56:04PM +0100, Asbj?rn S?b? wrote: > Some colleauges of mine do need a tool for coding and decoding of > high-order Ambisonic for their research. They are aiming for seventh > order, played back over sixteen loudspeakers. They are now planning to > implement this, using either JACK or LADSPA. > > As I have some experience with linux audio, I got involved. So I am > seeking some advice and answers here. The first thing I would like to > know is: Does anything like this already exist? No, and for some very good reasons. Regardless of the JACK / LADSPA question, seventh order Ambisonics using 16 speakers is just ridiculous. Either it's horizontal only, and in that case using 7th order is just a waste of resources and effort (3th order will do all you want), or it's 3-D, and it that case 7th order requires *much* more than 16 speakers. AFAIK, nobody ever even worked out the equations for 4th order or above. -- FA From georg.holzmann at student.kug.ac.at Thu Dec 15 15:04:28 2005 From: georg.holzmann at student.kug.ac.at (Georg Holzmann) Date: Thu Dec 15 15:02:44 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? In-Reply-To: <20051215193334.GA4739@linux-1> References: <20051215155604.GA465@stud.ntnu.no> <20051215193334.GA4739@linux-1> Message-ID: <43A1CC4C.8060509@student.kug.ac.at> Hallo! > Regardless of the JACK / LADSPA question, seventh order Ambisonics using > 16 speakers is just ridiculous. Either it's horizontal only, and in that > case using 7th order is just a waste of resources and effort (3th order > will do all you want), or it's 3-D, and it that case 7th order requires > *much* more than 16 speakers. yes, but you can use higher order ambisonics and virtual speakers ... > AFAIK, nobody ever even worked out the equations for 4th order or above. that's not true - at our university here is a 4th order ambisonic implementation ... LG Georg From fons.adriaensen at skynet.be Thu Dec 15 15:45:21 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Thu Dec 15 15:39:44 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? In-Reply-To: <43A1CC4C.8060509@student.kug.ac.at> References: <20051215155604.GA465@stud.ntnu.no> <20051215193334.GA4739@linux-1> <43A1CC4C.8060509@student.kug.ac.at> Message-ID: <20051215204521.GB4739@linux-1> On Thu, Dec 15, 2005 at 09:04:28PM +0100, Georg Holzmann wrote: > >Regardless of the JACK / LADSPA question, seventh order Ambisonics using > >16 speakers is just ridiculous. Either it's horizontal only, and in that > >case using 7th order is just a waste of resources and effort (3th order > >will do all you want), or it's 3-D, and it that case 7th order requires > >*much* more than 16 speakers. > > yes, but you can use higher order ambisonics and virtual speakers ... You can't squeeze N independent variables into M < N without losing some information. If information is lost in your process of using it, you could do as well without it. > >AFAIK, nobody ever even worked out the equations for 4th order or above. > that's not true - at our university here is a 4th order ambisonic > implementation ... Can you refer me to a paper or other publication about that ? -- FA From kjetil at ccrma.stanford.edu Thu Dec 15 19:46:45 2005 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Thu Dec 15 19:46:56 2005 Subject: [linux-audio-dev] Re: "declicking" algorithm? In-Reply-To: <200512151609.jBFG9t7l018391@roar.music.columbia.edu> References: <200512151609.jBFG9t7l018391@roar.music.columbia.edu> Message-ID: Paul Coccoli: > > On a semi-related note, can someone recommend any Free libraries in C > or C++ that implement things like oscillators, filters, etc.? > http://www.iua.upf.es/mtg/clam/ http://ccrma.stanford.edu/software/stk/ -- From cp_singh at faith.co.jp Thu Dec 15 22:15:20 2005 From: cp_singh at faith.co.jp (chandrasheakhar singh) Date: Thu Dec 15 22:15:38 2005 Subject: [linux-audio-dev] Implementing synthesizer???? References: <20051215155604.GA465@stud.ntnu.no> <20051215193334.GA4739@linux-1><43A1CC4C.8060509@student.kug.ac.at> <20051215204521.GB4739@linux-1> Message-ID: <017501c601ee$f37149d0$4b13a80a@cpsingh> Dear All, After successful implementation of player + synthesizer as a loadable kernel module in linux 2.6.11 for OMAP 2420. My next mission is to implement synth and sequencer seperately in linux kernel 2.6.11. I dont have much idea of VIRMIDI implementation and how i have to add my synth as default kernel synth, though GPL issue is still not very clear as we will open our source code for public or not. Can any one pass me some good link which describe how to implement synth as VIRMIDI and sequncer separately in linux 2.6.11. BR chandrasheakhar From paul at linuxaudiosystems.com Thu Dec 15 22:45:50 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Dec 15 22:43:13 2005 Subject: [linux-audio-dev] Implementing synthesizer???? In-Reply-To: <017501c601ee$f37149d0$4b13a80a@cpsingh> References: <20051215155604.GA465@stud.ntnu.no> <20051215193334.GA4739@linux-1><43A1CC4C.8060509@student.kug.ac.at> <20051215204521.GB4739@linux-1> <017501c601ee$f37149d0$4b13a80a@cpsingh> Message-ID: <1134704750.7539.66.camel@localhost.localdomain> On Fri, 2005-12-16 at 12:15 +0900, chandrasheakhar singh wrote: > Dear All, > > After successful implementation of player + synthesizer as a loadable kernel module in linux 2.6.11 > for OMAP > 2420. My next mission is to implement synth and sequencer seperately in linux kernel 2.6.11. > > I dont have much idea of VIRMIDI implementation and how i have to add my synth as default kernel > synth, though > GPL issue is still not very clear as we will open our source code for public or not. > > Can any one pass me some good link which describe how to implement synth as VIRMIDI and sequncer > separately in linux 2.6.11. are you out of your mind? partly kidding, partly serious. how many people do you think are going to be willing to install your module into their kernel? there are several excellent synthesizers and audio players implemented entirely in user space that have *zero* performance problems when run on an appropriate low latency kernel. there is really little reason for making the kernel less stable (and giving up all the benefits of inter-application audio routing via JACK) just to write a synthesizer. where did you get this idea? --p From khremeviuc at yahoo.com Fri Dec 16 01:10:12 2005 From: khremeviuc at yahoo.com (Kevin Hremeviuc) Date: Fri Dec 16 01:10:21 2005 Subject: [linux-audio-dev] Implementing synthesizer???? In-Reply-To: <017501c601ee$f37149d0$4b13a80a@cpsingh> Message-ID: <20051216061012.34566.qmail@web60720.mail.yahoo.com> Hi, I think you have several ways you can go with this but none of them involve making a kernel module. The ways to go are: 1. make your synthesizer a jack audio client and an alsa sequencer client 2. make your synthesizer a dssi plugin (sort of like VSTi in windows) My preferred option is dssi. If you go down this path you should look at perhaps the most comprehensive sequencer currently in linux called Rosegarden. There is another sequencer but it is in the process of adding dssi host functionality (Muse). If you want to please most people then do both 1 and 2 above. Web pages to look at include: http://www.ladspa.org/ http://dssi.sourceforge.net/ http://www.rosegardenmusic.com/ http://jackit.sourceforge.net/ http://www.alsa-project.org/ Jack is built on top of alsa's audio API and allows multiple audio programs to access a soundcard (merges the audio) and is designed for low latency. Ladspa is like VST effects in windows with plugin clients that run in a host. DSSI is built on top of ladspa and the open sound control APIs to provide something like VSTi instruments in windows. Rosegarden is a sequencer that uses jack for audio, alsa sequencer API for midi sequencing, ladspa effects and DSSI plugin instruments. Kev --- chandrasheakhar singh wrote: > Dear All, > > After successful implementation of player + > synthesizer as a loadable kernel module in linux > 2.6.11 > for OMAP > 2420. My next mission is to implement synth and > sequencer seperately in linux kernel 2.6.11. > > I dont have much idea of VIRMIDI implementation and > how i have to add my synth as default kernel > synth, though > GPL issue is still not very clear as we will open > our source code for public or not. > > Can any one pass me some good link which describe > how to implement synth as VIRMIDI and sequncer > separately in linux 2.6.11. > > BR > chandrasheakhar > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From kjetil at ccrma.stanford.edu Fri Dec 16 01:27:42 2005 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Fri Dec 16 01:27:46 2005 Subject: [linux-audio-dev] Implementing synthesizer???? In-Reply-To: <200512160613.jBG6DQ7l007804@roar.music.columbia.edu> References: <200512160613.jBG6DQ7l007804@roar.music.columbia.edu> Message-ID: Paul Davis: On Fri, 2005-12-16 at 12:15 +0900, chandrasheakhar singh wrote: >> Dear All, >> >> After successful implementation of player + synthesizer as a loadable >kernel module in linux 2.6.11 >> for OMAP >> 2420. My next mission is to implement synth and sequencer seperately >in linux kernel 2.6.11. >> >> I dont have much idea of VIRMIDI implementation and how i have to add >my synth as default kernel >> synth, though >> GPL issue is still not very clear as we will open our source code for >public or not. >> >> Can any one pass me some good link which describe how to implement >synth as VIRMIDI and sequncer >> separately in linux 2.6.11. > > are you out of your mind? partly kidding, partly serious. > He he. :-) I like that kind of thinking though. And what would be even cooler would be something like a graphical web-browser or an e-mail reader implemented as a kernel module. ;-) -- From georg.holzmann at student.kug.ac.at Fri Dec 16 02:55:44 2005 From: georg.holzmann at student.kug.ac.at (Georg Holzmann) Date: Fri Dec 16 02:53:55 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? In-Reply-To: <20051215204521.GB4739@linux-1> References: <20051215155604.GA465@stud.ntnu.no> <20051215193334.GA4739@linux-1> <43A1CC4C.8060509@student.kug.ac.at> <20051215204521.GB4739@linux-1> Message-ID: <43A27300.1060708@student.kug.ac.at> Hallo! >>yes, but you can use higher order ambisonics and virtual speakers ... > You can't squeeze N independent variables into M < N without losing some > information. If information is lost in your process of using it, you could > do as well without it. First I must say that I'm really no specialist at this topic ... ;) yes, I thought the same, but the one who build the ambisonic system here told me, that you can improve some things if you use something like that ... if you are interested I can ask him again about the details ... >>that's not true - at our university here is a 4th order ambisonic >>implementation ... > > > Can you refer me to a paper or other publication about that ? here is an old one: http://iem.at/~zmoelnig/publications/cube_en.pdf much more newer ones (but most of them in german) are here: http://www.iem.at LG Georg From richard.spindler at gmail.com Fri Dec 16 03:46:59 2005 From: richard.spindler at gmail.com (Richard Spindler) Date: Fri Dec 16 03:47:02 2005 Subject: [linux-audio-dev] Implementing synthesizer???? In-Reply-To: References: <200512160613.jBG6DQ7l007804@roar.music.columbia.edu> Message-ID: <4af8d6ff0512160046x458e6e84u@mail.gmail.com> 2005/12/16, Kjetil S. Matheussen : > > are you out of your mind? partly kidding, partly serious. > > > > He he. :-) > I like that kind of thinking though. And what would be even cooler > would be something like a graphical web-browser or an e-mail reader > implemented as a kernel module. ;-) Hi, I just googled for this "OMAP 2420" thingy, and it seems to be some kind of all in one embeddeded chip, so a different approach might be justified, although I have to agree that doing certian things in kernel space is just a no no. :) -Richard From asbjs at stud.ntnu.no Fri Dec 16 04:06:35 2005 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Fri Dec 16 04:06:41 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? In-Reply-To: <20051215193334.GA4739@linux-1> References: <20051215155604.GA465@stud.ntnu.no> <20051215193334.GA4739@linux-1> Message-ID: <20051216090635.GA11506@stud.ntnu.no> On Thu, Dec 15, 2005 at 08:33:34PM +0100, fons adriaensen wrote: > On Thu, Dec 15, 2005 at 04:56:04PM +0100, Asbj?rn S?b? wrote: > > > Some colleauges of mine do need a tool for coding and decoding of > > high-order Ambisonic for their research. They are aiming for seventh > > order, played back over sixteen loudspeakers. [...] > > The first thing I would like to > > know is: Does anything like this already exist? > > No, and for some very good reasons. Then we won't be reinventing the wheel, at least, which is good to know. > Regardless of the JACK / LADSPA question, seventh order Ambisonics using > 16 speakers is just ridiculous. Either it's horizontal only, and in that > case using 7th order is just a waste of resources and effort (3th order > will do all you want), or it's 3-D, and it that case 7th order requires > *much* more than 16 speakers. Well, I don't know much about Ambisonics, so I won't take this discussion much further. But I note that my colleauge working on this is very much in disagreement with you. According to him, you theoretically need order 36 to achieve perfect wave front reconstruction in a sphere the size of a listeners head. (For a listener in the sweet spot and for frequencies up to about 22kHz, that is.) Asbj?rn From asbjs at stud.ntnu.no Fri Dec 16 04:37:27 2005 From: asbjs at stud.ntnu.no (=?iso-8859-1?B?QXNiavhybiBT5mL4?=) Date: Fri Dec 16 04:37:31 2005 Subject: [linux-audio-dev] High-order Ambisonic coder/decoder in JACK/LDASPA? In-Reply-To: <20051215160904.GL8448@login.ecs.soton.ac.uk> References: <20051215155604.GA465@stud.ntnu.no> <20051215160904.GL8448@login.ecs.soton.ac.uk> Message-ID: <20051216093727.GB11506@stud.ntnu.no> On Thu, Dec 15, 2005 at 04:09:04PM +0000, Steve Harris wrote: > On Thu, Dec 15, 2005 at 04:56:04 +0100, Asbj?rn S?b? wrote: > > Secondly, what would be the better choice, JACK or LADSPA? We are > > probably going to need som GUI on it, to configure the thing. And we > > would like to have the flexibility to alter the coding/decoding > > coefficients, turn on/off some filtering and so on. > > A better choice would be DSSI or JACK, LADSPA doesnt really support GUIs. > > I wouldn't like to say which will be better, JACK is probably easier, but > DSSI is more flexible (you can run the plugin as a standale jack app as > well as a plugin). OK, thank for the tip. We will look into DSSI also. Asbj?rn From d.sbragion at infotecna.it Fri Dec 16 04:40:53 2005 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Fri Dec 16 04:41:02 2005 Subject: [linux-audio-dev] [ANN] DRC: Digital Room Correction 2.6.2 Message-ID: <5.1.0.14.1.20051216103928.01f99808@pop3.infotecna.lcl> Hello, DRC generates digital room correction FIR filters to be used within HiFi systems in conjunction with real time convolution engines like BruteFIR. Changes in version 2.6.2: A new command line parameters replacement functionality has been introduced. The dip and peak limiting procedures have been improved in order to avoid numerical instabilities. A new wavelet based analysis graph has been added to the sample results. Many performance improvements have been introduced. A new optional parameter used to define the base directory for all files has been added. Best of listening, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From d.sbragion at infotecna.it Fri Dec 16 04:47:11 2005 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Fri Dec 16 04:47:20 2005 Subject: [linux-audio-dev] [ANN] DRC: Digital Room Correction 2.6.2 In-Reply-To: <5.1.0.14.1.20051216103928.01f99808@pop3.infotecna.lcl> Message-ID: <5.1.0.14.1.20051216104638.01f9b798@pop3.infotecna.lcl> At 10.40 16/12/2005 +0100, you wrote: >Changes in version 2.6.2: sorry, I forgot to mention that the new version is available at the usual place: http://drc-fir.sourceforge.net/ Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From cp_singh at faith.co.jp Fri Dec 16 05:26:27 2005 From: cp_singh at faith.co.jp (chandrasheakhar singh) Date: Fri Dec 16 05:29:32 2005 Subject: [linux-audio-dev] configuring ALSA support in linux 2.6.11 References: <20051215155604.GA465@stud.ntnu.no><20051215160904.GL8448@login.ecs.soton.ac.uk> <20051216093727.GB11506@stud.ntnu.no> Message-ID: <01d201c6022b$93d1d750$4b13a80a@cpsingh> Dear All, I wanted to configure ALSA for omap 2420 (h4) in linux 2.6.11. I found that in omap_h4_2420_defconfig the macro related with ALSA is not there so i have added it as : -------------------------------------------------------------------- # # Sound # CONFIG_SOUND=y # # Advanced Linux Sound Architecture # CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_PCM=y CONFIG_SND_RAWMIDI=y CONFIG_SND_SEQUENCER=y # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set -------------------------------------------------------- and commented the following lines --------------------------------------------------- # # Open Sound System # # CONFIG_SOUND_PRIME is not set< ------------------------------------------------------ and left as it is following macro defined. CONFIG_SOUND_OMAP=y CONFIG_SOUND_TSC2101 =y After booting the kernel i can only see the following : dev/snd/mixer dev/snd/mixer dev/snd/control0 but where is snd/snd which will emulate oss dsp ????? Can you tell me where i am wrong ???? BR chandrashekhar From clemens at ladisch.de Fri Dec 16 06:57:57 2005 From: clemens at ladisch.de (Clemens Ladisch) Date: Fri Dec 16 06:58:49 2005 Subject: [linux-audio-dev] configuring ALSA support in linux 2.6.11 In-Reply-To: <01d201c6022b$93d1d750$4b13a80a@cpsingh> References: <20051215155604.GA465@stud.ntnu.no> <20051215160904.GL8448@login.ecs.soton.ac.uk> <20051216093727.GB11506@stud.ntnu.no> <01d201c6022b$93d1d750$4b13a80a@cpsingh> Message-ID: <1134734277.43a2abc564fb1@webmail.uni-halle.de> chandrasheakhar singh wrote: > I wanted to configure ALSA for omap 2420 (h4) in linux 2.6.11. > > CONFIG_SOUND=y > CONFIG_SND=y > CONFIG_SND_PCM=y > CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=y > CONFIG_SND_PCM_OSS=y > CONFIG_SOUND_OMAP=y > CONFIG_SOUND_TSC2101 =y > > After booting the kernel i can only see the following : > > dev/snd/mixer > dev/snd/mixer Are there really two files with the same name? > dev/snd/control0 This should be controlC0. What are the actual contents of /dev/snd/? > but where is snd/snd which will emulate oss dsp ????? OSS PCM emulation would be /dev/dsp, but only if the driver actually has a PCM device. Yours hasn't (there would be an ALSA device, /dev/snd/pcmC0D0p). > Can you tell me where i am wrong ???? Somewhere in the driver source code, which you didn't show. HTH Clemens From maxim.krikun at gmail.com Fri Dec 16 08:20:40 2005 From: maxim.krikun at gmail.com (Maxim Krikun) Date: Fri Dec 16 08:33:47 2005 Subject: [linux-audio-dev] Re: python and jack, performance report References: <1134315209.3234.5.camel@zeitgeist> Message-ID: Leonard "paniq" Ritter writes: > frustrated by the poor implementation of the jack bindings for python > (pyjack), i wrote my own in native python using ctypes. And what's wrong with pyjack? For me it works fine, apart from some minor bug > i believe that considering the overhead of the python implementation, > that result isn't too bad, and maybe allows for more than just > prototyping. What about the latency? Do you think sure it's safe to execute arbitrary pyhton code inside jack's thread? Your TestClient.mix method manipulates arrays, thus it may eventually call malloc, which is explicitly discouraged in jack api doculentation. -- Maxim From james at dis-dot-dat.net Fri Dec 16 08:40:53 2005 From: james at dis-dot-dat.net (james@dis-dot-dat.net) Date: Fri Dec 16 08:39:07 2005 Subject: [linux-audio-dev] Implementing synthesizer???? In-Reply-To: References: <200512160613.jBG6DQ7l007804@roar.music.columbia.edu> Message-ID: <20051216134052.GA5999@phlunky.Belkin> On Thu, 15 Dec, 2005 at 10:27PM -0800, Kjetil S. Matheussen spake thus: > > Paul Davis: > On Fri, 2005-12-16 at 12:15 +0900, chandrasheakhar singh wrote: > >>Dear All, > >> > >>After successful implementation of player + synthesizer as a loadable > >kernel module in linux 2.6.11 > >>for OMAP > >>2420. My next mission is to implement synth and sequencer seperately > >in linux kernel 2.6.11. > >> > >>I dont have much idea of VIRMIDI implementation and how i have to add > >my synth as default kernel > >>synth, though > >>GPL issue is still not very clear as we will open our source code for > >public or not. > >> > >>Can any one pass me some good link which describe how to implement > >synth as VIRMIDI and sequncer > >>separately in linux 2.6.11. > > > >are you out of your mind? partly kidding, partly serious. > > > > He he. :-) > I like that kind of thinking though. And what would be even cooler > would be something like a graphical web-browser or an e-mail reader > implemented as a kernel module. ;-) Great idea! And why don't we go for a sickening blue and green theme for the interface? And while we're at it, let's put a web *server* in the kernel. No, wait... -- "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) From ben at glw.com Fri Dec 16 10:53:11 2005 From: ben at glw.com (Ben Loftis) Date: Fri Dec 16 09:24:35 2005 Subject: [linux-audio-dev] [ANN] DRC: Digital Room Correction 2.6.2 In-Reply-To: <200512161339.jBGDdW7n017446@roar.music.columbia.edu> References: <200512161339.jBGDdW7n017446@roar.music.columbia.edu> Message-ID: <200512160953.11408.ben@glw.com> If you haven't tried out Denis' DRC program, you should. I have had great success with it. I am in the process of documenting my results ... watch this space. -Ben Loftis http://www.harrisonaudio.com http://www.studiooutfitters.com From torbenh at gmx.de Fri Dec 16 12:13:55 2005 From: torbenh at gmx.de (torbenh@gmx.de) Date: Fri Dec 16 11:53:50 2005 Subject: [linux-audio-dev] Implementing synthesizer???? In-Reply-To: References: <200512160613.jBG6DQ7l007804@roar.music.columbia.edu> Message-ID: <20051216171355.GB4891@mobilat> On Thu, Dec 15, 2005 at 10:27:42PM -0800, Kjetil S. Matheussen wrote: > > Paul Davis: > On Fri, 2005-12-16 at 12:15 +0900, chandrasheakhar singh wrote: > >>Dear All, > >> > >>After successful implementation of player + synthesizer as a loadable > >kernel module in linux 2.6.11 > >>for OMAP > >>2420. My next mission is to implement synth and sequencer seperately > >in linux kernel 2.6.11. > >> > >>I dont have much idea of VIRMIDI implementation and how i have to add > >my synth as default kernel > >>synth, though > >>GPL issue is still not very clear as we will open our source code for > >public or not. > >> > >>Can any one pass me some good link which describe how to implement > >synth as VIRMIDI and sequncer > >>separately in linux 2.6.11. > > > >are you out of your mind? partly kidding, partly serious. > > > > He he. :-) > I like that kind of thinking though. And what would be even cooler > would be something like a graphical web-browser or an e-mail reader > implemented as a kernel module. ;-) hmm... but implementing jack in kernel space would solve the cycle counter issue. /me runs. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From rlrevell at joe-job.com Fri Dec 16 14:16:03 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Dec 16 14:13:15 2005 Subject: [linux-audio-dev] Implementing synthesizer???? In-Reply-To: <4af8d6ff0512160046x458e6e84u@mail.gmail.com> References: <200512160613.jBG6DQ7l007804@roar.music.columbia.edu> <4af8d6ff0512160046x458e6e84u@mail.gmail.com> Message-ID: <1134760563.18119.4.camel@mindpipe> On Fri, 2005-12-16 at 09:46 +0100, Richard Spindler wrote: > 2005/12/16, Kjetil S. Matheussen : > > > are you out of your mind? partly kidding, partly serious. > > > > > > > He he. :-) > > I like that kind of thinking though. And what would be even cooler > > would be something like a graphical web-browser or an e-mail reader > > implemented as a kernel module. ;-) > > Hi, > > I just googled for this "OMAP 2420" thingy, and it seems to be some > kind of all in one embeddeded chip, so a different approach might be > justified, although I have to agree that doing certian things in > kernel space is just a no no. :) You do know that the module MUST be GPL otherwise the produce will be illegal to distribute right? Lee From cp_singh at faith.co.jp Sun Dec 18 20:09:00 2005 From: cp_singh at faith.co.jp (chandrasheakhar singh) Date: Sun Dec 18 20:09:31 2005 Subject: [linux-audio-dev] configuring ALSA support in linux 2.6.11 References: <20051215155604.GA465@stud.ntnu.no> <20051215160904.GL8448@login.ecs.soton.ac.uk> <20051216093727.GB11506@stud.ntnu.no> <01d201c6022b$93d1d750$4b13a80a@cpsingh> <1134734277.43a2abc564fb1@webmail.uni-halle.de> Message-ID: <00e701c60438$ce490750$4b13a80a@cpsingh> Hi, Thanks , i'm using linux kernel 2.6.11(for h4 from www.kernel.org). > This should be controlC0. Yes thats right. Do you suggest me anything to test or verify in driver as default config file for this target (omap_h4_2420_defconfig) does not have ALSA configuration macro to configure. BR chandrashekhar ----- Original Message ----- From: "Clemens Ladisch" To: "The Linux Audio Developers' Mailing List" Cc: "chandrasheakhar singh" Sent: Friday, December 16, 2005 8:57 PM Subject: Re: [linux-audio-dev] configuring ALSA support in linux 2.6.11 > chandrasheakhar singh wrote: >> I wanted to configure ALSA for omap 2420 (h4) in linux 2.6.11. >> >> CONFIG_SOUND=y >> CONFIG_SND=y >> CONFIG_SND_PCM=y >> CONFIG_SND_OSSEMUL=y >> CONFIG_SND_MIXER_OSS=y >> CONFIG_SND_PCM_OSS=y >> CONFIG_SOUND_OMAP=y >> CONFIG_SOUND_TSC2101 =y >> >> After booting the kernel i can only see the following : >> >> dev/snd/mixer >> dev/snd/mixer > > Are there really two files with the same name? > >> dev/snd/control0 > > This should be controlC0. > > What are the actual contents of /dev/snd/? > >> but where is snd/snd which will emulate oss dsp ????? > > OSS PCM emulation would be /dev/dsp, but only if the driver actually has > a PCM device. Yours hasn't (there would be an ALSA device, /dev/snd/pcmC0D0p). > >> Can you tell me where i am wrong ???? > > Somewhere in the driver source code, which you didn't show. > > > HTH > Clemens > From clemens at ladisch.de Mon Dec 19 03:46:37 2005 From: clemens at ladisch.de (Clemens Ladisch) Date: Mon Dec 19 03:47:54 2005 Subject: [linux-audio-dev] configuring ALSA support in linux 2.6.11 In-Reply-To: <00e701c60438$ce490750$4b13a80a@cpsingh> References: <20051215155604.GA465@stud.ntnu.no> <20051215160904.GL8448@login.ecs.soton.ac.uk> <20051216093727.GB11506@stud.ntnu.no> <01d201c6022b$93d1d750$4b13a80a@cpsingh> <1134734277.43a2abc564fb1@webmail.uni-halle.de> <00e701c60438$ce490750$4b13a80a@cpsingh> Message-ID: <20051219084637.GC8293@turing.informatik.uni-halle.de> chandrasheakhar singh wrote: > Do you suggest me anything to test or verify in driver as default > config file for this target (omap_h4_2420_defconfig) does not have > ALSA configuration macro to configure. > > >>CONFIG_SOUND_OMAP=y > >>CONFIG_SOUND_TSC2101 =y It looks as if these are OSS drivers. You cannot use those with ALSA unless you've ported them to use the ALSA API. HTH Clemens From cp_singh at faith.co.jp Mon Dec 19 03:58:15 2005 From: cp_singh at faith.co.jp (chandrasheakhar singh) Date: Mon Dec 19 03:58:36 2005 Subject: [linux-audio-dev] configuring ALSA support in linux 2.6.11 References: <20051215155604.GA465@stud.ntnu.no> <20051215160904.GL8448@login.ecs.soton.ac.uk> <20051216093727.GB11506@stud.ntnu.no> <01d201c6022b$93d1d750$4b13a80a@cpsingh> <1134734277.43a2abc564fb1@webmail.uni-halle.de> <00e701c60438$ce490750$4b13a80a@cpsingh> <20051219084637.GC8293@turing.informatik.uni-halle.de> Message-ID: <013201c6047a$5a5726a0$4b13a80a@cpsingh> Hi, I think we are right, but as far as ALSA is concerned if i'm correct, it does talk about lowest audio driver, it emulates oss to access lowest audio driver, if this is the case then ALSA should work with existing audio driver. If you have something to share about how to port ALSA for this target , please let me know. BR chandrashekhar ----- Original Message ----- From: "Clemens Ladisch" To: "chandrasheakhar singh" ; "The Linux Audio Developers' Mailing List" Sent: Monday, December 19, 2005 5:46 PM Subject: Re: [linux-audio-dev] configuring ALSA support in linux 2.6.11 > chandrasheakhar singh wrote: >> Do you suggest me anything to test or verify in driver as default >> config file for this target (omap_h4_2420_defconfig) does not have >> ALSA configuration macro to configure. >> >> >>CONFIG_SOUND_OMAP=y >> >>CONFIG_SOUND_TSC2101 =y > > It looks as if these are OSS drivers. You cannot use those with ALSA > unless you've ported them to use the ALSA API. > > > HTH > Clemens > From aamehl at actcom.net.il Mon Dec 19 07:21:38 2005 From: aamehl at actcom.net.il (Aaron) Date: Mon Dec 19 07:21:09 2005 Subject: [linux-audio-dev] Notation editors Message-ID: <20051219122138.GC5708@actcom.net.il> Hi all, I started out wondering who uses Denemo, for notation editing, but my idea quickly evolved to this. I would like to know who on the list uses graphical notation editors, which one?, what are in your eyes the advantage of your particular editor, the disadvantages? I realize that there may be people using Sibelius/Finale, which aren't linux programs, but I was running Finale for quite a while on wine/win4lin for quite a while because of legacy issues. Also how many people use non graphical music notation. Mup, LilyPond, Guido, abc, common music notation etc. Why? What is the advantage them, disadvantage. This will help Denemo see what linux musicians/developers use and hopefully help us see what we can do to make Denemo more useful. Thanks Aaron From clemens at ladisch.de Mon Dec 19 11:16:07 2005 From: clemens at ladisch.de (Clemens Ladisch) Date: Mon Dec 19 11:17:15 2005 Subject: [linux-audio-dev] configuring ALSA support in linux 2.6.11 In-Reply-To: <013201c6047a$5a5726a0$4b13a80a@cpsingh> References: <20051215155604.GA465@stud.ntnu.no> <20051215160904.GL8448@login.ecs.soton.ac.uk> <20051216093727.GB11506@stud.ntnu.no> <01d201c6022b$93d1d750$4b13a80a@cpsingh> <1134734277.43a2abc564fb1@webmail.uni-halle.de> <00e701c60438$ce490750$4b13a80a@cpsingh> <20051219084637.GC8293@turing.informatik.uni-halle.de> <013201c6047a$5a5726a0$4b13a80a@cpsingh> Message-ID: <1135008967.43a6dcc762e59@webmail.uni-halle.de> chandrasheakhar singh wrote: > I think we are right, but as far as ALSA is concerned if i'm correct, it > does talk about lowest audio > driver, it emulates oss to access lowest audio driver, if this is the case > then ALSA should work with existing audio driver. ALSA can emulate the OSS API for user-space applications, but all its drivers must use its own internal API. > If you have something to share about how to port ALSA for this target , > please let me know. Have a look at Documentation/sound/alsa/DocBook/writing-an-alsa-driver. HTH Clemens From jussi.laako at pp.inet.fi Mon Dec 19 13:55:02 2005 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Mon Dec 19 13:56:01 2005 Subject: [linux-audio-dev] configuring ALSA support in linux 2.6.11 In-Reply-To: <01d201c6022b$93d1d750$4b13a80a@cpsingh> References: <20051215155604.GA465@stud.ntnu.no> <20051215160904.GL8448@login.ecs.soton.ac.uk> <20051216093727.GB11506@stud.ntnu.no> <01d201c6022b$93d1d750$4b13a80a@cpsingh> Message-ID: <1135018502.8189.2.camel@vaarlahti.uworld> On Fri, 2005-12-16 at 19:26 +0900, chandrasheakhar singh wrote: > I wanted to configure ALSA for omap 2420 (h4) in linux 2.6.11. > I found that in omap_h4_2420_defconfig the macro I assume you are using ARM Linux kernel tree? What is H4, some TI's evaluation board? > related with ALSA is not there so i have added it as : Depending on how the TSC audio chip is connected, it might not be so straightforward to have ALSA... -- Jussi Laako From beachnase at web.de Wed Dec 21 19:14:39 2005 From: beachnase at web.de (Frank Neumann) Date: Wed Dec 21 19:13:55 2005 Subject: [linux-audio-dev] Reminder: LAC2006 Call For Papers/Music/Demos Message-ID: Hi list(s), just a short reminder: The Call for Papers, Call for Music etc. for the 4th International Linux Audio Conference (LAC2006) is still running until January 8th, 2006. That means for those of you who drive home for Christmas like me - use the time wisely :-). Write a paper, compose a piece, think of a software demo - and submit your entry in time. See all the details at: http://lac.zkm.de Hoping to hear from you (and then see you) soon, Goetz Dipper & Frank Neumann LAC2006 Organization From dak at gnu.org Thu Dec 22 19:58:03 2005 From: dak at gnu.org (David Kastrup) Date: Thu Dec 22 19:58:12 2005 Subject: [linux-audio-dev] Re: [SoX-users] Trimming silence In-Reply-To: <958b3a2e0512220912u402020c8p@mail.gmail.com> (tom christie's message of "Thu, 22 Dec 2005 17:12:53 +0000") References: <85mziu83rd.fsf@lola.goethe.zz> <958b3a2e0512220912u402020c8p@mail.gmail.com> Message-ID: <85k6dwsk84.fsf@lola.goethe.zz> tom christie writes: > I've written a little template program that just reads from one > audio file and writes to another, using the sox library stlib.a. > It's pretty simple to change it to do what you want. Thanks, I'll give it a whirl. I still think that the code of the sox executable should be able to trim just zeros at least at the start of the file, and that the docs are hard to understand and missing stuff, but there is nothing except list the complaints that I feel capable of doing. I strongly suspect that the code does something different from what it is supposed to do, but I find it impossible to figure out what it is supposed to do, either. So I might be wrong about that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From James at superbug.co.uk Thu Dec 22 20:37:31 2005 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Dec 22 20:37:35 2005 Subject: [linux-audio-dev] db gain controls. Message-ID: <43AB54DB.609@superbug.co.uk> Hi, I have a question for some audio professionals out there. What is the smallest sensible gain control step in dB. Is it 0.5dB ? I am asking, because if one is using a digital gain control in a 24bit fixed point DSP, once could use almost any step size, so I am looking for the smallest sensible size to use. Some people mentioned earlier on a previous thread that there was something called soft gain control, where the user moves the gain up a step, but the mixer gradually(fairly quickly) adjusts the volume to the new level, so no clicks are heard on the speakers. How does these soft gain controls prevent the clicking? Do they wait for the zero crossing point to adjust the gain? James From dak at gnu.org Thu Dec 22 21:00:25 2005 From: dak at gnu.org (David Kastrup) Date: Thu Dec 22 21:00:35 2005 Subject: [linux-audio-dev] db gain controls. In-Reply-To: <43AB54DB.609@superbug.co.uk> (James Courtier-Dutton's message of "Fri, 23 Dec 2005 01:37:31 +0000") References: <43AB54DB.609@superbug.co.uk> Message-ID: <85u0d0r2rq.fsf@lola.goethe.zz> James Courtier-Dutton writes: > Hi, > > I have a question for some audio professionals out there. > What is the smallest sensible gain control step in dB. > Is it 0.5dB ? > I am asking, because if one is using a digital gain control in a 24bit > fixed point DSP, once could use almost any step size, so I am looking > for the smallest sensible size to use. Well, the minimum possible difference for 24bit is between -2^23+1 and -2^23, and that would be about 0.000001dB. > Some people mentioned earlier on a previous thread that there was > something called soft gain control, where the user moves the gain up a > step, but the mixer gradually(fairly quickly) adjusts the volume to > the new level, so no clicks are heard on the speakers. How does these > soft gain controls prevent the clicking? Do they wait for the zero > crossing point to adjust the gain? No, why should they? You just ramp up the volume linearly. If you want to be even nicer, you use a shape that is even smoother. Basically, you put the step pulse from the jump gain through a low pass filter, preferably one that does not overswing. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From rlrevell at joe-job.com Thu Dec 22 21:32:27 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 22 21:28:20 2005 Subject: [linux-audio-dev] db gain controls. In-Reply-To: <85u0d0r2rq.fsf@lola.goethe.zz> References: <43AB54DB.609@superbug.co.uk> <85u0d0r2rq.fsf@lola.goethe.zz> Message-ID: <1135305147.13573.6.camel@mindpipe> On Fri, 2005-12-23 at 03:00 +0100, David Kastrup wrote: > James Courtier-Dutton writes: > > > Hi, > > > > I have a question for some audio professionals out there. > > What is the smallest sensible gain control step in dB. > > Is it 0.5dB ? > > I am asking, because if one is using a digital gain control in a 24bit > > fixed point DSP, once could use almost any step size, so I am looking > > for the smallest sensible size to use. > > Well, the minimum possible difference for 24bit is between -2^23+1 and > -2^23, and that would be about 0.000001dB. He said sensible not possible. Lee From dak at gnu.org Thu Dec 22 21:39:33 2005 From: dak at gnu.org (David Kastrup) Date: Thu Dec 22 21:39:36 2005 Subject: [linux-audio-dev] db gain controls. In-Reply-To: <1135305147.13573.6.camel@mindpipe> (Lee Revell's message of "Thu, 22 Dec 2005 21:32:27 -0500") References: <43AB54DB.609@superbug.co.uk> <85u0d0r2rq.fsf@lola.goethe.zz> <1135305147.13573.6.camel@mindpipe> Message-ID: <85d5jor0yi.fsf@lola.goethe.zz> Lee Revell writes: > On Fri, 2005-12-23 at 03:00 +0100, David Kastrup wrote: >> James Courtier-Dutton writes: >> >> > Hi, >> > >> > I have a question for some audio professionals out there. >> > What is the smallest sensible gain control step in dB. >> > Is it 0.5dB ? >> > I am asking, because if one is using a digital gain control in a 24bit >> > fixed point DSP, once could use almost any step size, so I am looking >> > for the smallest sensible size to use. >> >> Well, the minimum possible difference for 24bit is between -2^23+1 and >> -2^23, and that would be about 0.000001dB. > > He said sensible not possible. If you are using ramp gains, then you don't want to use courser steps than available because you are buying additional noise in that manner. If you wanted that noise, you'd not be using 24bit. So there is an application where this kind of step is "sensible". Since he does not tell what application he has in mind, one can't choose what would be sensible for that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From pw_lists at slinkp.com Thu Dec 22 22:22:35 2005 From: pw_lists at slinkp.com (Paul Winkler) Date: Thu Dec 22 22:22:56 2005 Subject: [linux-audio-dev] db gain controls. In-Reply-To: <85d5jor0yi.fsf@lola.goethe.zz> References: <43AB54DB.609@superbug.co.uk> <85u0d0r2rq.fsf@lola.goethe.zz> <1135305147.13573.6.camel@mindpipe> <85d5jor0yi.fsf@lola.goethe.zz> Message-ID: <20051223032235.GA15649@slinkp.com> On Fri, Dec 23, 2005 at 03:39:33AM +0100, David Kastrup wrote: > Lee Revell writes: > > He said sensible not possible. > > If you are using ramp gains, then you don't want to use courser steps > than available because you are buying additional noise in that > manner. My guess is that you don't actually disagree: the O.P. didn't say whether he meant "gain control" in the sense of user interface or in the sense of DSP. Lee seems to be assuming the former. David seems to be assuming the latter. -- Paul Winkler http://www.slinkp.com From rlrevell at joe-job.com Thu Dec 22 22:47:03 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Thu Dec 22 22:42:42 2005 Subject: [linux-audio-dev] db gain controls. In-Reply-To: <20051223032235.GA15649@slinkp.com> References: <43AB54DB.609@superbug.co.uk> <85u0d0r2rq.fsf@lola.goethe.zz> <1135305147.13573.6.camel@mindpipe> <85d5jor0yi.fsf@lola.goethe.zz> <20051223032235.GA15649@slinkp.com> Message-ID: <1135309623.4473.5.camel@mindpipe> On Thu, 2005-12-22 at 22:22 -0500, Paul Winkler wrote: > On Fri, Dec 23, 2005 at 03:39:33AM +0100, David Kastrup wrote: > > Lee Revell writes: > > > He said sensible not possible. > > > > If you are using ramp gains, then you don't want to use courser steps > > than available because you are buying additional noise in that > > manner. > > My guess is that you don't actually disagree: the O.P. didn't say > whether he meant "gain control" in the sense of user interface or in the > sense of DSP. Lee seems to be assuming the former. David seems to be > assuming the latter. > Yes we are talking about user interfaces (specifically adding db gain controls to the ALSA mixer). Lee From fons.adriaensen at skynet.be Fri Dec 23 01:29:51 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Fri Dec 23 01:24:11 2005 Subject: [linux-audio-dev] db gain controls. In-Reply-To: <43AB54DB.609@superbug.co.uk> References: <43AB54DB.609@superbug.co.uk> Message-ID: <20051223062951.GA4765@linux-1> On Fri, Dec 23, 2005 at 01:37:31AM +0000, James Courtier-Dutton wrote: > I have a question for some audio professionals out there. > What is the smallest sensible gain control step in dB. > Is it 0.5dB ? > I am asking, because if one is using a digital gain control in a 24bit > fixed point DSP, once could use almost any step size, so I am looking > for the smallest sensible size to use. > > Some people mentioned earlier on a previous thread that there was > something called soft gain control, where the user moves the gain up a > step, but the mixer gradually(fairly quickly) adjusts the volume to the > new level, so no clicks are heard on the speakers. How does these soft > gain controls prevent the clicking? Do they wait for the zero crossing > point to adjust the gain? Steps of 0.5 dB would be smalll enough from a operational POV (except mayby in equipment used to do A/B tests, where you'd want better than 0.1 dB). The simplest way to avoid clicks is to interpolate the change over one ore more periods (linear is OK if the step is small). This could still give perceptible 'zipper noise' on some signals, so one step further would be to lowpass the gain change at period rate, then interpolate linearly. -- FA From jens.andreasen at chello.se Fri Dec 23 04:24:16 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Dec 23 04:24:21 2005 Subject: [linux-audio-dev] db gain controls. In-Reply-To: <43AB54DB.609@superbug.co.uk> References: <43AB54DB.609@superbug.co.uk> Message-ID: <1135329856.9018.50.camel@c80-216-124-251.cm-upc.chello.se> On Fri, 2005-12-23 at 01:37 +0000, James Courtier-Dutton wrote: > Hi, > > I have a question for some audio professionals out there. > What is the smallest sensible gain control step in dB. > Is it 0.5dB ? > I am asking, because if one is using a digital gain control in a 24bit > fixed point DSP, once could use almost any step size, so I am looking > for the smallest sensible size to use. This would be the resolution of your fader. So next up: What is a sensible resolution for a fader? Expensive well renomated equipment appear to settle for 10bit (or approximately 0.1db if you prefer.) > > Some people mentioned earlier on a previous thread that there was > something called soft gain control, where the user moves the gain up a > step, but the mixer gradually(fairly quickly) adjusts the volume to the > new level, so no clicks are heard on the speakers. How does these soft > gain controls prevent the clicking? Do they wait for the zero crossing > point to adjust the gain? Assuming 48K samplerate and a fader value (at most) every second ms Left-shift your fader values as much as you can without loosing bits. Interpolate the fader values over 96 samples. Square them and average the most current 256 samples for smoothness Multiply your signal. > > James -- mvh // Jens M Andreasen From derek at x-i.net Sat Dec 24 06:08:09 2005 From: derek at x-i.net (derek holzer) Date: Sat Dec 24 06:08:18 2005 Subject: [linux-audio-dev] defining a platform Message-ID: <43AD2C19.7070302@x-i.net> Hi all, I hope this is a simple question. I'm trying to compile Rezound on OSX, and I'm getting this: ../../../config/platform/platform.h:10:3: warning: #warning no platform determined! Which leads to some other troubles later on. So I've created a config/platform/darwin.h file (based on the bsd.h file) which starts like this: #ifndef __rez_platform_darwin_H__ #define __rez_platform_darwin_H__ #if defined(__Darwin) #define rez_OS_DARWIN #endif And added OS_DARWIN to the platform.h file: #ifndef __platform_H__ #define __platform_H__ #include "linux.h" #include "solaris.h" #include "bsd.h" #include "darwin.h" #if !defined(rez_OS_DARWIN) && !defined(rez_OS_LINUX) && !defined(rez_OS_SOLARIS) && !defined(rez_OS_BSD) #warning no platform determined! #endif #endif But I still get the error. In the darwin.h file, I have tried various different syntax for defining Darwin: (__darwin), (darwin), __Darwin__), etc etc With no result. Can anybody shed some light on the right way to define the platform in this situation? thx + happy new year, derek -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 81: "Go to an extreme, move back to a more comfortable place" From musound at jps.net Sat Dec 24 10:17:58 2005 From: musound at jps.net (Sean Bolton) Date: Sat Dec 24 10:17:46 2005 Subject: [linux-audio-dev] defining a platform In-Reply-To: <43AD2C19.7070302@x-i.net> References: <43AD2C19.7070302@x-i.net> Message-ID: Hi Derek, On Dec 24, 2005, at 3:08 AM, derek holzer wrote: > I hope this is a simple question. I'm trying to compile Rezound on > OSX, and I'm getting this: > > ../../../config/platform/platform.h:10:3: warning: #warning no > platform determined! > #if defined(__Darwin) > #define rez_OS_DARWIN > #endif Instead, try: #if (defined(__MACH__) && defined(__APPLE__)) .... HTH, -Sean From d.sbragion at infotecna.it Tue Dec 27 03:41:46 2005 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Tue Dec 27 03:42:08 2005 Subject: [linux-audio-dev] [ANN] DRC: Digital Room Correction 2.6.2 In-Reply-To: <200512160953.11408.ben@glw.com> References: <200512161339.jBGDdW7n017446@roar.music.columbia.edu> <200512161339.jBGDdW7n017446@roar.music.columbia.edu> Message-ID: <5.1.0.14.1.20051227093950.02ef6018@pop3.infotecna.lcl> Hello Ben, At 09.53 16/12/2005 -0600, you wrote: >If you haven't tried out Denis' DRC program, you should. I have had great >success with it. I am in the process of documenting my results ... watch >this space. are you using it in a professional environment? So far it's been used only for home/hobbyist situations, and I would be really interested to hear about any use in a more professional situation. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From dlphillips at woh.rr.com Tue Dec 27 09:45:22 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue Dec 27 09:26:25 2005 Subject: [linux-audio-dev] VST + Linux tutorial final update Message-ID: <43B15382.7090203@woh.rr.com> Greetings: Last month I updated the VST/Linux tutorial at http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/. Due to circumstances, the updated page has only recently gone on-line, but no further material needed to be added. Please note that this update is the last that will be done for that tutorial. As you can read on the updated page, I now feel that the FST and DSSI projects are the currently preferred solutions for using VST/VSTi plugins under Linux. Both systems are easy to build and use, so I'll leave further explication to the developers of those projects. I suppose at some point someone should add some material regarding the use of VST plugins with Ardour, but it should really go on the Ardour wiki (or maybe it is already there?). Thanks to Patrick Shirkey for hosting this tutorial on his djcj site. Best regards, dp From astochlia at msn.com Wed Dec 28 16:22:28 2005 From: astochlia at msn.com (ARRON STOCHLIA) Date: Wed Dec 28 16:22:32 2005 Subject: [linux-audio-dev] non graphical vu meter In-Reply-To: <8a0c36780512090638h5dae5a2fw7eb57d3a70ce7dab@mail.gmail.com> Message-ID: Now I need to do the same thing using oss. Is there an easy way to do this, and what tools do I need... The machine I am working on has redhat 7.3. >From: Richard Smith >Reply-To: "The Linux Audio Developers' Mailing >List" >To: "The Linux Audio Developers' Mailing >List" >Subject: Re: [linux-audio-dev] non graphical vu meter >Date: Fri, 9 Dec 2005 08:38:26 -0600 > >On 12/8/05, ARRON STOCHLIA wrote:> I am trying to write >an application that will monitor volume level coming in> through the >line-in jack on my soundcard. Is this possible using alsa, and> if so, >does anyone know of any examples, or am I in the wrong place? >arecord -vv aready does this. >Note thats 2 'v's and not a 'w'. On my system the font makes themlook the >same. > >--Richard A. Smith _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From ben at glw.com Thu Dec 29 10:05:32 2005 From: ben at glw.com (Ben Loftis) Date: Thu Dec 29 09:59:00 2005 Subject: [linux-audio-dev] Re: [ANN] DRC: Digital Room Correction 2.6.2 In-Reply-To: <200512271705.jBRH5F7n005546@roar.music.columbia.edu> References: <200512271705.jBRH5F7n005546@roar.music.columbia.edu> Message-ID: <200512290905.32312.ben@glw.com> > are you using it in a professional environment? So far it's been used only > for home/hobbyist situations, and I would be really interested to hear > about any use in a more professional situation. Denis, My application is that of a "non-commercial" mastering studio. I do a bit of mastering for my friends in Nashville, but so far I've only worked with the rough mixes, nothing that's made it onto a record. The reason I'm so excited about DRC is that it transforms my not-mastering-quality Klipschorns into something that is very accurate, or at least measures so, and in my opinion is comparable to the high-end mastering and mixing studios I've visted. For those who don't know, Klipschorns use a folded horn to load a 15" woofer and convetional horn-loaded midrange and tweeter into a cabinet that fits tightly in the corner of the room. They have extremely high efficiency and low distortion, but abysmal phase and frequency response. Luckily, these are EXACTLY the things that DRC is designed to fix. Most speakers have 10% or so distortion at low frequencies and moderate listening levels. As far as I know, this can't be removed by any sort of electronic correction. With this setup and some modest room treatment, I've got very low distortion, AND flat frequency response. -Ben Loftis http://www.harrisonconsoles.com http://www.studiooutfitters.com From d.sbragion at infotecna.it Thu Dec 29 11:07:30 2005 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Thu Dec 29 11:07:34 2005 Subject: [linux-audio-dev] Re: [ANN] DRC: Digital Room Correction 2.6.2 In-Reply-To: <200512290905.32312.ben@glw.com> References: <200512271705.jBRH5F7n005546@roar.music.columbia.edu> <200512271705.jBRH5F7n005546@roar.music.columbia.edu> Message-ID: <5.1.0.14.1.20051229170119.01f917b0@pop3.infotecna.lcl> Hello Ben, At 09.05 29/12/2005 -0600, you wrote: >My application is that of a "non-commercial" mastering studio. I do a bit of >mastering for my friends in Nashville, but so far I've only worked with the >rough mixes, nothing that's made it onto a record. ... thanks for the details. Even thoug it can't be qualified as true professional use it is already closer to that than the most common home situation. For me it is already really interesting to ear about the results. ... >low distortion, but abysmal phase and frequency response. Luckily, these are >EXACTLY the things that DRC is designed to fix. Most speakers have 10% or so >distortion at low frequencies and moderate listening levels. As far as I >know, this can't be removed by any sort of electronic correction. With this >setup and some modest room treatment, I've got very low distortion, AND flat >frequency response. Indeed a KlipschHorn is a good candidate for DRC usage. BTW, just for your information, there exists methods, based on Volterra Kernels, to compensate also for non linear distortion of speakers. There's a Studer paper on Internet about it. The math behind Volterra Kernels is frightening difficult, at least to me, so I never went through it. Bye and thanks again, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From mista.tapas at gmx.net Thu Dec 29 18:47:46 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Thu Dec 29 18:47:52 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. Message-ID: <20051230004746.506816f5@mango.fruits.de> Hi, i was wondering: With the new shiny -rt kernels and realtime scheduling available to non root users via the usual mechanisms, there's the possibility of really finetuning an audio/midi system. The main issue i am interested in is the interplay between midi and audio in such a system. How to tune the audio side to get a very reliable system is pretty easy these days, thanks to the great jack audio connection kit, alsa and the new -rt kernels. But now i wonder how midi software fits into this. I'm here interested in the special case of a software sequencer (like i.e. Rosegarden) driving a softsynth (like i.e. om-synth or supercollider3) or whatever. Ok, on a normal audio tuned -rt equipped linux system the SCHED_FIFO priorities which are used for the different components look something like this: 99 - system timer 98 - RTC 81 - soundcard IRQ handler 80 - jack watchdog 70 - jack main loop 69 - jack clients' process loops 50 - the other IRQ handlers Now, i wonder how midi threads would fit in best into this scheme. Let's assume our midi sequencer uses either sleep() or RTC to get woken up at regular intervals, and let's further assume that it properly deals with these timing sources to get relatively jitter free midi output given that it get's woken up often enough by the scheduler. I further assume that the alsa seq event system is used and midi events are not queued for future delivery but always delivered immediately. All this implies that for midi delivery timing to not be influenced by audio processing on the system (which gets a problem especially at large buffer size, where quite a bit of work is done at a time), all the stuff that handles midi should run with realtime priorities above the jack stuff (i.e. around 90). I wonder whether it also needs to have a higher priority than the soundcard irq handler, too. Does the jackd main loop "inherit" the priority of the soundcard irq handler? Anyways, one more thing to note is for this to work nicely, the softsynth needs to have an extra midi handling thread that is also running with a priority in the 90s range, so it can timestamp the event properly when it arrives. So i wonder now: Assuming our system is setup as described above and all midi handling is done from threads with sufficiently high pririties not to get disturbed by audio stuff, will the alsa event system play nice? I ask this, because i have setup a system as above with a simple midi generator (see code below) and some different softsynths (one of which i have written which does have its midi thread at an appropriate priority. you can get a tarball here. http://affenbande.org/~tapas/ughsynth-0.0.3.tgz Beware it eats unbelievable amounts of cpu and is in no way considered being finished. it just lay around handy for this test ;)). But i still get some regular jitter in my sound. Here's recorded example output (running jackd at a periodsize of 1024 and the test notes are produced at a frequency of 8hz). First with ughsynth then with jack-dssi-host hexter.so. The effect is less prominent with hexter, i suppose because the jack load with it is only at 2 or 3% as opposed to ughsynth that uses 50% here on my athlon 1.2 ghz box. In case you don't hear what i mean: The timing of every ca. 7th or 8th note is a little bit off. http://affenbande.org/~tapas/midi_timing.ogg So i wonder: what's going wrong? Is the priorities setup described above not correct? Is alsa seq handling somehow not done with RT priority? What else could be wrong? Please enlighten me :) And yeah, i do _not_ want to hear about jack midi. It's a good thing, and i'm all for it as it will make at least some scenarios work great (sequencer and softsynth both being jack midi clients), but not all. Thanks in advance, Flo midi_timer.cc: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define RTC_FREQ 2048.0 #define NOTE_FREQ 8.0 #define RT_PRIO 85 int main() { int fd; fd = open("/dev/rtc", O_RDONLY); if (fd == -1) { perror("/dev/rtc"); exit(errno); } int retval = ioctl(fd, RTC_IRQP_SET, (int)RTC_FREQ); if (retval == -1) { perror("ioctl"); exit(errno); } std::cout << "locking memory" << std::endl; mlockall(MCL_CURRENT); // std::cout << "sleeping 1 sec" << std::endl; // sleep(1); snd_seq_t *seq_handle; int err, port_no; err = snd_seq_open(&seq_handle, "default", SND_SEQ_OPEN_OUTPUT, 0); if (err < 0) { std::cout << "error" << std::endl; exit(0); } std::string port_name = "midi_timer"; // set the name to something reasonable.. err = snd_seq_set_client_name(seq_handle, port_name.c_str()); if (err < 0) { std::cout << "error" << std::endl; exit(0); } // this is the port others can connect to. we don't do autoconnect ourself err = snd_seq_create_simple_port(seq_handle, "midi_timer:output", SND_SEQ_PORT_CAP_READ|SND_SEQ_PORT_CAP_SUBS_READ, SND_SEQ_PORT_TYPE_MIDI_GENERIC); if (err < 0) { std::cout << "error" << std::endl; exit(0); } // on success we know our port no port_no = err; struct sched_param param; int policy; pthread_getschedparam(pthread_self(), &policy, ¶m); param.sched_priority = RT_PRIO; policy = SCHED_FIFO; pthread_setschedparam(pthread_self(), policy, ¶m); std::cout << "turning irq on" << std::endl; retval = ioctl(fd, RTC_PIE_ON, 0); if (retval == -1) { perror("ioctl"); exit(errno); } snd_seq_event_t ev; unsigned long data; int ticks_passed = 0; while(1) { // then we read it retval = read(fd, &data, sizeof(unsigned long)); if (retval == -1) { perror("read"); exit(errno); } if ((float)ticks_passed >= (RTC_FREQ/NOTE_FREQ)) { // std::cout << "play note" << std::endl; ticks_passed -= (long int)(RTC_FREQ/NOTE_FREQ); // play note snd_seq_ev_clear(&ev); snd_seq_ev_set_direct(&ev); snd_seq_ev_set_subs(&ev); snd_seq_ev_set_source(&ev, port_no); ev.type = SND_SEQ_EVENT_NOTEON; ev.data.note.note = 53; ev.data.note.velocity = 100; snd_seq_event_output_direct(seq_handle, &ev); snd_seq_drain_output(seq_handle); } data = (data >> 8); // std::cout << data << std::endl; ticks_passed += data; } return 0; } -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Thu Dec 29 19:52:10 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Thu Dec 29 19:52:14 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051230004746.506816f5@mango.fruits.de> References: <20051230004746.506816f5@mango.fruits.de> Message-ID: <20051230015210.253a6ecc@mango.fruits.de> On Fri, 30 Dec 2005 00:47:46 +0100 Florian Schmidt wrote: [snip] Hmm, forget this post :) I need to do some more testing first.. Flo -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Fri Dec 30 08:48:50 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 08:48:55 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051230015210.253a6ecc@mango.fruits.de> References: <20051230004746.506816f5@mango.fruits.de> <20051230015210.253a6ecc@mango.fruits.de> Message-ID: <20051230144850.29f1b792@mango.fruits.de> On Fri, 30 Dec 2005 01:52:10 +0100 Florian Schmidt wrote: > On Fri, 30 Dec 2005 00:47:46 +0100 > Florian Schmidt wrote: > > [snip] > > Hmm, > > forget this post :) I need to do some more testing first.. Ok, my synth was buggy (damn copy and paste). Now it works like a charm with a setup as described in my original post. To illustrate the difference a proper priority setup can make, here's debug output of my ughsynth driven by the RTC based midi_timer note generator (links for both programs at bottom of the mail): note on, frame_time: 56249918 next event: 574 diff: 6071 note on, frame_time: 56255989 next event: 501 diff: 6144 note on, frame_time: 56262133 next event: 501 diff: 6144 note on, frame_time: 56268277 next event: 501 diff: 6143 note on, frame_time: 56274420 next event: 500 diff: 5500 note on, frame_time: 56279920 next event: 880 diff: 6000 note on, frame_time: 56285920 next event: 736 diff: 6000 note on, frame_time: 56291920 next event: 592 diff: 6054 note on, frame_time: 56297974 next event: 502 diff: 6145 note on, frame_time: 56304119 next event: 503 diff: 6142 note on, frame_time: 56310261 next event: 501 diff: 6144 note on, frame_time: 56316405 next event: 501 diff: 5517 note on, frame_time: 56321922 next event: 898 diff: 6001 note on, frame_time: 56327923 next event: 755 diff: 6000 note on, frame_time: 56333923 next event: 611 diff: 6035 note on, frame_time: 56339958 next event: 502 diff: 6144 note on, frame_time: 56346102 next event: 502 diff: 6143 note on, frame_time: 56352245 next event: 501 diff: 6144 The interesting number is the "diff" output as it tells us the difference of the previous midi event timestamp to the current one.The "next" field is the offset into the currently to-be-processed period. In above output the midi handling thread of ughsynth ran with a priority of 59, which is below the jackd stuff in my system (-P 70). Here's output with the midi handling in ughsynth running at a priority of 95: note on, frame_time: 71319937 next event: 385 diff: 6000 note on, frame_time: 71325937 next event: 241 diff: 6000 note on, frame_time: 71331937 next event: 97 diff: 6002 note on, frame_time: 71337939 next event: 979 diff: 6000 note on, frame_time: 71343939 next event: 835 diff: 6000 note on, frame_time: 71349939 next event: 691 diff: 6000 note on, frame_time: 71355939 next event: 547 diff: 6000 note on, frame_time: 71361939 next event: 403 diff: 6001 note on, frame_time: 71367940 next event: 260 diff: 6000 note on, frame_time: 71373940 next event: 116 diff: 6001 note on, frame_time: 71379941 next event: 997 diff: 6000 note on, frame_time: 71385941 next event: 853 diff: 6001 note on, frame_time: 71391942 next event: 710 diff: 6000 note on, frame_time: 71397942 next event: 566 diff: 6000 note on, frame_time: 71403942 next event: 422 diff: 6000 note on, frame_time: 71409942 next event: 278 diff: 6001 note on, frame_time: 71415943 next event: 135 diff: 6000 note on, frame_time: 71421943 next event: 1015 The difference is either 5999, 6000 or 6001 frames, which at a framerate of 48000hz is tightly around 1/(6000/48000) = 8 hz which is exactly what the midi note generator is setup to do. The variance is several orders of magnitude lower than in the previous example output above with midi handling prio of 59, which does make an audible difference: http://affenbande.org/~tapas/stable_timing.ogg as opposed to: http://affenbande.org/~tapas/unstable_timing.ogg To summarize here's how a well tuned -rt system for combined midi/audio usage should look like (prioritywise): 99 System timer IRQ (you cannot change this anyways) 98 RTC IRQ 95 . . Midi handling threads of softsynths/midi sequencers (preferably . 85 82 Soundcard IRQ 80 Jackd watchdog thread 70 Jackd main loop 69 Jackd client (softsynths/midi sequencers) audio process callbacks 60 . . Other IRQ handlers (disk, network, USB, GFX) . 40 0 (SCHED_OTHER) All other software in the system Sadly not many app authors are aware of this (as my unsuccessful quest to get stable midi timing with available linux software showed), so i hope this post does raise the awareness on the issue. It would be ideal, if app authors allowed the user to finetune the realtime priorities of each component of their software (well, especially the midi handling part, as the audio processing priorities are determined by what priority jack is given). Here's the software i used for the test http://affenbande.org/~tapas/midi_timer.tgz http://affenbande.org/~tapas/ughsynth-0.0.3.tgz Regards, Flo P.S.: i also summarized the results a little bit on this page: http://tapas.affenbande.org/?page_id=40 Please let me know if there's any big errors on that page. P.P.S.: Additionally to RTC or sleep() based mechanism (which relies right now on the system timer frequency (which is a mere 250hz in default kernels (easy to change to 1000hz though with a recompile))) the future will also bring us POSIX high resolution timers. I don't know yet how these will fit in exactly. -- Palimm Palimm! http://tapas.affenbande.org From jens.andreasen at chello.se Fri Dec 30 10:03:44 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Dec 30 10:03:51 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051230144850.29f1b792@mango.fruits.de> References: <20051230004746.506816f5@mango.fruits.de> <20051230015210.253a6ecc@mango.fruits.de> <20051230144850.29f1b792@mango.fruits.de> Message-ID: <1135955025.10147.61.camel@c80-216-124-251.cm-upc.chello.se> Flo! Is it important for the midi thread priority to be above the soundcard IRQ, or is it enough to be above jackd? How will having several sound/midi cards fit into this scheme? (I have a builtin VIA chipset sound, a better quality Aureal PCI card and, for good measure, a USB control surface.) /jens PS: Letting BIOS set up the IRQs (instead of Linux plug&pray) solved some USB related underruns for me. From chris.cannam at ferventsoftware.com Fri Dec 30 10:17:04 2005 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Fri Dec 30 10:19:38 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. Message-ID: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> Florian Schmidt writes: > I further assume that the alsa seq event system > is used This is true of Rosegarden, > and midi events are not queued > for future delivery but always delivered immediately. but this isn't -- Rosegarden always queues events from a non-RT thread and lets the ALSA sequencer kernel layer deliver them. (Thru events are delivered directly, with potential additional latency because of the lower priority used for the MIDI thread.) In principle this should mean that only the priority of the receiving synth's MIDI thread is significant for the timing of sequenced events. We also have a mechanism to compensate for gradual drift between the MIDI timing source (kernel timers or RTC) and soundcard clock, when synchronising to audio, by adjusting the sequencer skew factor. (This happens to be similar to the mechanism for slaving to MTC, which is handy.) In my experience this is all a long way from foolproof. The most common problems for users seem to be: - ALSA sequencer uses kernel timers by default and of course they only run at 100 or 250Hz in many kernels. - ALSA sequencer can sync to RTC, but the associated module (snd-rtctimer) appears to hang some kernels solid when loaded or used. I don't have much information about that, but I can probably find out some more. - ALSA sequencer can sync to a soundcard clock, but this induces jitter when used with JACK and has caused confusion for users who find themselves inadvertently sync'd to an unused soundcard (the classic "first note plays, then nothing" symptom). The biggest advantage of course is not having to run an RT MIDI timing thread. My impression is that this aspect of MusE (which does that, I think) causes as many configuration problems for its users as using ALSA sequencer queue timers does for Rosegarden's. Any more thoughts on this? Chris From mista.tapas at gmx.net Fri Dec 30 10:34:30 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 10:34:33 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1135955025.10147.61.camel@c80-216-124-251.cm-upc.chello.se> References: <20051230004746.506816f5@mango.fruits.de> <20051230015210.253a6ecc@mango.fruits.de> <20051230144850.29f1b792@mango.fruits.de> <1135955025.10147.61.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20051230163430.2b032c1d@mango.fruits.de> On Fri, 30 Dec 2005 16:03:44 +0100 Jens M Andreasen wrote: > Flo! > > Is it important for the midi thread priority to be above the soundcard > IRQ, or is it enough to be above jackd? This is not 100% clear to me. I'd figure it should be above soundcard irq, too, just to be safe. I don't know enough about the internals of how and if priority is inherited by threads waiting for IRQ's. The previous posts were also all about midi routing from different apps on the same machine. I do not know how sending/receiving MIDI to physical ports is handled. Maybe the soundcard IRQ does play a role here. But a higher prio thread waiting for a lower prio IRQ will not really cause any troubles from my understanding (it will just work). > How will having several sound/midi cards fit into this scheme? Well, to get several audio cards working you will need to get them to work in a single jack server first, so the part about the jack priority setup still holds. Then again just put all midi stuff again at the higher prios. I don't see much changing here. Flo -- Palimm Palimm! http://tapas.affenbande.org From paul at linuxaudiosystems.com Fri Dec 30 10:41:46 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Dec 30 10:39:10 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> Message-ID: <1135957306.4661.50.camel@localhost.localdomain> > The biggest advantage of course is not having to run > an RT MIDI timing thread. My impression is that this > aspect of MusE (which does that, I think) causes > as many configuration problems for its users as using > ALSA sequencer queue timers does for Rosegarden's. > > Any more thoughts on this? several people have wanted JACK to export a thread create call that would take care of the RT-ness. that way, if you can run JACK with RT scheduling, you can run a MIDI thread too, with no extra steps. it would also be useful for people doing FFT in JACK clients using a separate thread. i don't agree with florian that the MIDI thread should run with higher priority than the JACK watchdog, btw. i think the watchdog should be higher than anything else until such a time as the kernel guarantees "watchdog" functionality itself. --p From mista.tapas at gmx.net Fri Dec 30 11:04:24 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 11:04:38 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> Message-ID: <20051230170424.7179897f@mango.fruits.de> On Fri, 30 Dec 2005 15:17:04 +0000 GMT "Chris Cannam" wrote: Hi Chris, > > and midi events are not queued > > for future delivery but always delivered immediately. > > but this isn't -- Rosegarden always queues events > from a non-RT thread and lets the ALSA sequencer > kernel layer deliver them. (Thru events are delivered > directly, with potential additional latency because of > the lower priority used for the MIDI thread.) In > principle this should mean that only the priority of > the receiving synth's MIDI thread is significant for > the timing of sequenced events. Hi, i tested Rosegarden running with the system timer as timing source (RTC is a bit broken atm on -rt kernels for me), and i do not get satisfactory results. I used my ughsynth again (which is heavy on the cpu which makes the problems just clearer) with its midi thread at priority 95. Here's example output with rosegarden producing a supposedly steady stream of 16th notes at 120 bpm: note on, frame_time: 205200106 next event: 744 next event: 746 diff: 5998 note on, frame_time: 205206104 next event: 599 next event: 600 diff: 6042 note on, frame_time: 205212146 next event: 497 next event: 498 diff: 6157 note on, frame_time: 205218303 next event: 510 next event: 511 diff: 6140 note on, frame_time: 205224443 next event: 506 next event: 507 diff: 6145 note on, frame_time: 205230588 next event: 507 next event: 508 diff: 5511 note on, frame_time: 205236099 next event: 898 next event: 899 diff: 6000 note on, frame_time: 205242099 next event: 754 next event: 755 diff: 5998 note on, frame_time: 205248097 next event: 608 next event: 609 diff: 6034 note on, frame_time: 205254131 next event: 498 next event: 499 diff: 6153 note on, frame_time: 205260284 next event: 507 next event: 508 diff: 6141 note on, frame_time: 205266425 next event: 504 next event: 505 diff: 6148 note on, frame_time: 205272573 next event: 507 next event: 509 diff: 5521 note on, frame_time: 205278094 next event: 908 next event: 910 next event: 510 which is again in the range as with my test program and ughsynth having a low midi thread prio. This is clearly audible, too: http://affenbande.org/~tapas/rosegarden_ughsynth.ogg this is the rosegardenfile used for this: http://affenbande.org/~tapas/test16th.rg This would imply to me, that either the way the events are scheduled in rosegarden is buggy (unlikely as it works fine when there's less audio load on the system) or that the event queue delivery by ALSA is somehow happening with only SCHED_OTHER priority as well. I have not yet found an option for ALSA to configure this. > - ALSA sequencer uses kernel timers by default and > of course they only run at 100 or 250Hz in many > kernels. In my case i have compiled the kernel to use a system timer frequency of 1000hz. It would be interesting to know though what priority the ALSA event queue handling gets. I also stumbled across some problems with sleep() and especially waking up when the sleep time has expired in the course of writing my rt_watchdog program. Sometimes the high prio SCHED_FIFO thread wasn't woken up as long as a lower SCHED_FIFO prio thread hugged the cpu even when the sleep time of the high prio thread was long expired.. Ingo told me back then that there's extra kernel threads for the timing subsystem which need to be setup to high prios too for this to work correctly. Haven't really investigated further into this. I need to write another small test app that uses sleep based timing and a high prio, too, to drive ughsynth. Will report what results i get. > - ALSA sequencer can sync to RTC, but the > associated module (snd-rtctimer) appears to hang > some kernels solid when loaded or used. I don't have > much information about that, but I can probably find > out some more. I have never bothered to try this either. > - ALSA sequencer can sync to a soundcard clock, > but this induces jitter when used with JACK and has > caused confusion for users who find themselves > inadvertently sync'd to an unused soundcard (the > classic "first note plays, then nothing" symptom). > The biggest advantage of course is not having to run > an RT MIDI timing thread. My impression is that this > aspect of MusE (which does that, I think) causes > as many configuration problems for its users as using > ALSA sequencer queue timers does for Rosegarden's. > > Any more thoughts on this? >From my point of view just setting up a RT midi thread driven by RTC and with a sufficiently high prio for dispatching midi events immediately is the best way. As it seems to work well, at least for my small test case. Further testing needs to be done though. I will report back. I haven't really tried muse. Will do so if i find the time though.. Flo -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Fri Dec 30 11:17:10 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 11:17:15 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1135957306.4661.50.camel@localhost.localdomain> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <1135957306.4661.50.camel@localhost.localdomain> Message-ID: <20051230171710.099dcbdf@mango.fruits.de> On Fri, 30 Dec 2005 10:41:46 -0500 Paul Davis wrote: > several people have wanted JACK to export a thread create call that > would take care of the RT-ness. that way, if you can run JACK with RT > scheduling, you can run a MIDI thread too, with no extra steps. it would > also be useful for people doing FFT in JACK clients using a separate > thread. actually, with realtime-lsm, there's really no need for this, except for some convenience. Every app can create its own RT threads these days. The 2.4.x capabilities days are (thank gawd) over :) > i don't agree with florian that the MIDI thread should run with higher > priority than the JACK watchdog, btw. i think the watchdog should be > higher than anything else until such a time as the kernel guarantees > "watchdog" functionality itself. Agreed. why not make it prio 98 by default then? (system timer should still be higher i suppose). With a difference of only 10 between main jack loop and the watchdog, it might get a little crowded :) Flo -- Palimm Palimm! http://tapas.affenbande.org From ws at seh.de Fri Dec 30 11:37:13 2005 From: ws at seh.de (Werner Schweer) Date: Fri Dec 30 11:36:27 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> Message-ID: <200512301737.13502.ws@seh.de> On Friday 30 December 2005 16:17, Chris Cannam wrote: > Florian Schmidt writes: > > I further assume that the alsa seq event system > > is used > > This is true of Rosegarden, > > > and midi events are not queued > > for future delivery but always delivered immediately. > > but this isn't -- Rosegarden always queues events > from a non-RT thread and lets the ALSA sequencer > kernel layer deliver them. (Thru events are delivered > directly, with potential additional latency because of > the lower priority used for the MIDI thread.) In > principle this should mean that only the priority of > the receiving synth's MIDI thread is significant for > the timing of sequenced events. We also have a > mechanism to compensate for gradual drift between > the MIDI timing source (kernel timers or RTC) and > soundcard clock, when synchronising to audio, by > adjusting the sequencer skew factor. (This happens > to be similar to the mechanism for slaving to MTC, > which is handy.) > > In my experience this is all a long way from > foolproof. The most common problems for users > seem to be: > > - ALSA sequencer uses kernel timers by default and > of course they only run at 100 or 250Hz in many > kernels. > > - ALSA sequencer can sync to RTC, but the > associated module (snd-rtctimer) appears to hang > some kernels solid when loaded or used. I don't have > much information about that, but I can probably find > out some more. > > - ALSA sequencer can sync to a soundcard clock, > but this induces jitter when used with JACK and has > caused confusion for users who find themselves > inadvertently sync'd to an unused soundcard (the > classic "first note plays, then nothing" symptom). > > The biggest advantage of course is not having to run > an RT MIDI timing thread. My impression is that this > aspect of MusE (which does that, I think) causes > as many configuration problems for its users as using > ALSA sequencer queue timers does for Rosegarden's. > > Any more thoughts on this? its right that MusE uses a RT midi thread to schedule midi events. ALSA is used only to deliver (route) midi events. I think this is the easiest possible solution and gives the app the best control over timing. Using the ALSA seq api means that ALSA has to operate the RT thread which only moves the problems to ALSA. The ALSA seq api is from ancient time were no realtime threads were available in linux. Only a kernel driver could provide usable midi timing. But with the introduction of RT threads the ALSA seq api is obsolete IMHO. Midi is synced to audio in MusE by using JACK frame timing to schedule midi events which is also easy and straightforward. There is nothing for a user to configure except he changes the priority of the JACK RT thread. The priority of the MusE midi RT thread has to be at least one above the JACK RT priority. The point is that this allows the midi thread to interrupt the JACK audio process thread which is necessary to provide acceptable midi timing. Last note about RT-linux kernels: its not _that_ important. Its only a micro optimization. A normal recent kernel works pretty well. If your normal kernel does not operate with sufficient low latencies, the RT-kernel will most likely also not work. /Werner From paul at linuxaudiosystems.com Fri Dec 30 11:54:56 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Dec 30 11:52:10 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051230171710.099dcbdf@mango.fruits.de> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <1135957306.4661.50.camel@localhost.localdomain> <20051230171710.099dcbdf@mango.fruits.de> Message-ID: <1135961696.4661.56.camel@localhost.localdomain> On Fri, 2005-12-30 at 17:17 +0100, Florian Schmidt wrote: > On Fri, 30 Dec 2005 10:41:46 -0500 > Paul Davis wrote: > > > several people have wanted JACK to export a thread create call that > > would take care of the RT-ness. that way, if you can run JACK with RT > > scheduling, you can run a MIDI thread too, with no extra steps. it would > > also be useful for people doing FFT in JACK clients using a separate > > thread. > > actually, with realtime-lsm, there's really no need for this, except for > some convenience. Every app can create its own RT threads these days. > The 2.4.x capabilities days are (thank gawd) over :) you don't know the correct priority to use. i imagine an api along the lines of: jack_create_thread (pthread_t*, void* (thread_function)(void*), void* arg, int relative_to_jack); the last argument would specify that the thread should run at, above or below the jack RT thread(s) by a given amount. typical values would be +1, 0, -1 etc. > > i don't agree with florian that the MIDI thread should run with higher > > priority than the JACK watchdog, btw. i think the watchdog should be > > higher than anything else until such a time as the kernel guarantees > > "watchdog" functionality itself. > > Agreed. why not make it prio 98 by default then? (system timer should > still be higher i suppose). With a difference of only 10 between main > jack loop and the watchdog, it might get a little crowded :) good point. From mista.tapas at gmx.net Fri Dec 30 12:06:32 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 12:06:35 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <200512301737.13502.ws@seh.de> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <200512301737.13502.ws@seh.de> Message-ID: <20051230180632.413acbe5@mango.fruits.de> On Fri, 30 Dec 2005 17:37:13 +0100 Werner Schweer wrote: > its right that MusE uses a RT midi thread to schedule midi > events. ALSA is used only to deliver (route) midi events. > I think this is the easiest possible solution and gives the app > the best control over timing. > Using the ALSA seq api means that ALSA has to operate the RT thread which > only moves the problems to ALSA. This is my understanding also. > The ALSA seq api is from ancient time were no realtime threads were > available in linux. Only a kernel driver could provide usable > midi timing. But with the introduction of RT threads the > ALSA seq api is obsolete IMHO. I wouldn't say obsolete, but IMHO RT thread based midi dispatching is more easy to get right. > Midi is synced to audio in MusE by using JACK frame timing to > schedule midi events which is also easy and straightforward. > There is nothing for a user to configure except he changes the > priority of the JACK RT thread. > The priority of the MusE midi RT thread has to be at least one above the > JACK RT priority. The point is that this allows the midi thread > to interrupt the JACK audio process thread which is necessary > to provide acceptable midi timing. Yep. I agree. Is this "one above the JACK RT priority" automated in muse? Your first sentence seems to imply otherwise. It's probably a reasonable approach to do it this way. Although manual user overide would be nice, too. > Last note about RT-linux kernels: its not _that_ important. Its > only a micro optimization. A normal recent kernel works pretty well. > If your normal kernel does not operate with sufficient low latencies, > the RT-kernel will most likely also not work. I do not agree. While this is true for an otherwise unloaded system, it is rather easy (on a vanilla kernel) to produce xruns by putting other load on the system. The IRQ priorization provided by -rt kernels is extremely useful to avoid these. It is _vital_ to run jackd with a priority higher than those IRQ handlers not doing audio/midi stuff (network, disk, etc). The soundcard IRQ handler must run with a high prio for this to work, too. I'm not all too sure about whether it matters which of the two (jack or soundcard irq) is higher though, as long as both are higher than other irq handlers. It is very useful to be able to do other stuff while audio/midi is working uninterrupted. I got used to be able to compile a kernel alongside running jackd with a periodsize of 32 or 16 frames :) which means, i can play o.e. guitar while waiting for the damn compile to finish. Flo P.S.: softsynths need to have their midi thread higher prio than jackd, too, for the flawless midi timing to work. So i suppose it's time for some bug reports to softsynth authors :) -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Fri Dec 30 12:11:55 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 12:12:00 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1135961696.4661.56.camel@localhost.localdomain> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <1135957306.4661.50.camel@localhost.localdomain> <20051230171710.099dcbdf@mango.fruits.de> <1135961696.4661.56.camel@localhost.localdomain> Message-ID: <20051230181155.65f482f0@mango.fruits.de> On Fri, 30 Dec 2005 11:54:56 -0500 Paul Davis wrote: > you don't know the correct priority to use. i imagine an api along the > lines of: true. > > jack_create_thread (pthread_t*, void* (thread_function)(void*), > void* arg, int relative_to_jack); > > the last argument would specify that the thread should run at, above or > below the jack RT thread(s) by a given amount. typical values would be > +1, 0, -1 etc. Why not simply /* * returns the priority (1-99) of the jack main loop (which is already one * above the clients' process() threads or 0 if not realtime. Clients having * a midi handling thread should create it with a priority at least one * above the return value of this function. */ int jack_get_rt_priority(); Then the app can decide itself about how to create the thread. > > Agreed. why not make it prio 98 by default then? (system timer should > > still be higher i suppose). With a difference of only 10 between main > > jack loop and the watchdog, it might get a little crowded :) > > good point. OTOH, i'm not really sure if 9 priority levels isn't enough. It seems one above jacks main thread should be good enough for most midi purposes. Flo -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Fri Dec 30 12:25:17 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 12:25:26 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> Message-ID: <20051230182517.6d9eb24d@mango.fruits.de> On Fri, 30 Dec 2005 15:17:04 +0000 GMT "Chris Cannam" wrote: > - ALSA sequencer can sync to RTC, but the > associated module (snd-rtctimer) appears to hang > some kernels solid when loaded or used. I don't have > much information about that, but I can probably find > out some more. Yeah, i got a nice and juicy BUG in it (see below). So this is what kills rosegarden regularly here when run with RTC timing source. I'm not sure this is ALSA's fault, though, might be the -rt kernel, too. But nonetheless after this happens rosegarden is hung and syslog tells me "rtc: lost some interrupts at 1024hz" over and over until infinity (or reboot): Dec 30 17:30:27 mango kernel: BUG at include/linux/timer.h:83! Dec 30 17:30:27 mango kernel: ------------[ cut here ]------------ Dec 30 17:30:27 mango kernel: kernel BUG at include/linux/timer.h:83! Dec 30 17:30:27 mango kernel: invalid operand: 0000 [#1] Dec 30 17:30:27 mango kernel: PREEMPT Dec 30 17:30:27 mango kernel: Modules linked in: snd_rtctimer snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq realtime iptable_nat ipt_addrtype ipt_state iptable_filter agpgart snd_intel8x0 usb_storage scsi_mod ohci_hcd usbcore ipt_MASQUERADE ip_nat ip_tables ip_conntrack snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_cs8427 snd_i2c snd_mpu401_uart bsd_comp ppp_deflate zlib_deflate ppp_async ppp_generic slhc crc_ccitt sis900 mii crc32 snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc Dec 30 17:30:27 mango kernel: CPU: 0 Dec 30 17:30:27 mango kernel: EIP: 0060:[] Not tainted VLI Dec 30 17:30:27 mango kernel: EFLAGS: 00210296 (2.6.15-rc7-rt1) Dec 30 17:30:27 mango kernel: EIP is at rtc_do_ioctl+0x9c1/0xa00 Dec 30 17:30:27 mango kernel: eax: 00000024 ebx: 00000001 ecx: 00200246 edx: 00000001 Dec 30 17:30:27 mango kernel: esi: 00200202 edi: 00821192 ebp: d680ea40 esp: e45e1d94 Dec 30 17:30:27 mango kernel: ds: 007b es: 007b ss: 0068 preempt: 00000001 Dec 30 17:30:27 mango kernel: Process rosegardenseque (pid: 6134, threadinfo=e45e0000 task=dcad58c0 stack_left=7520 worst_left=-1) Dec 30 17:30:27 mango kernel: Stack: c02e8de1 c02ed6bf 00000053 22222222 22222222 22222222 22222222 22222222 Dec 30 17:30:27 mango kernel: 22222222 22222222 c0331b20 e45e0000 e45e0000 c013953a e45e0000 00000001 Dec 30 17:30:27 mango kernel: 00200246 00200246 00000000 d680ea40 c02dda53 c0331b20 00007005 f09f7e44 Dec 30 17:30:27 mango kernel: Call Trace: Dec 30 17:30:27 mango kernel: [] sub_preempt_count+0x1a/0x20 (56) Dec 30 17:30:27 mango kernel: [] _spin_lock_irqsave+0x23/0x60 (28) Dec 30 17:30:27 mango kernel: [] rtctimer_start+0x43/0x70 [snd_rtctimer] (40) Dec 30 17:30:27 mango kernel: [] snd_timer_start1+0x89/0xa0 [snd_timer] (20) Dec 30 17:30:27 mango kernel: [] snd_timer_start+0xaf/0xe0 [snd_timer] (16) Dec 30 17:30:27 mango kernel: [] snd_seq_timer_continue+0x41/0x70 [snd_seq] (36) Dec 30 17:30:27 mango kernel: [] snd_seq_queue_process_event+0x144/0x160 [snd_seq] (16) Dec 30 17:30:27 mango kernel: [] snd_seq_control_queue+0x57/0xb0 [snd_seq] (32) Dec 30 17:30:27 mango kernel: [] snd_seq_deliver_single_event+0x181/0x190 [snd_seq] (28) Dec 30 17:30:27 mango kernel: [] snd_seq_deliver_event+0x42/0xa0 [snd_seq] (52) Dec 30 17:30:27 mango kernel: [] snd_seq_client_enqueue_event+0x91/0x160 [snd_seq] (28) Dec 30 17:30:27 mango kernel: [] snd_seq_write+0x16b/0x200 [snd_seq] (44) Dec 30 17:30:27 mango kernel: [] vfs_write+0xd5/0x1b0 (80) Dec 30 17:30:27 mango kernel: [] sys_write+0x4b/0x80 (36) Dec 30 17:30:27 mango kernel: [] syscall_call+0x7/0xb (40) Dec 30 17:30:27 mango kernel: --------------------------- Dec 30 17:30:27 mango kernel: | preempt count: 00000001 ] Dec 30 17:30:27 mango kernel: | 1-level deep critical section nesting: Dec 30 17:30:27 mango kernel: ---------------------------------------- Dec 30 17:30:27 mango kernel: .. [] .... add_preempt_count+0x1a/0x20 Dec 30 17:30:27 mango kernel: .....[<00000000>] .. ( <= _stext+0x3feffde0/0x60) Dec 30 17:30:27 mango kernel: Dec 30 17:30:27 mango kernel: ------------------------------ Dec 30 17:30:27 mango kernel: | showing all locks held by: | (rosegardenseque/6134 [dcad58c0, 1]): Dec 30 17:30:27 mango kernel: ------------------------------ Dec 30 17:30:27 mango kernel: Dec 30 17:30:27 mango kernel: #001: [e1d2d4e8] {&timer->lock} Dec 30 17:30:27 mango kernel: ... acquired at: snd_timer_start+0x8e/0xe0 [snd_timer] Dec 30 17:30:27 mango kernel: -- Palimm Palimm! http://tapas.affenbande.org From fons.adriaensen at skynet.be Fri Dec 30 12:32:45 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Fri Dec 30 12:26:54 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1135961696.4661.56.camel@localhost.localdomain> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <1135957306.4661.50.camel@localhost.localdomain> <20051230171710.099dcbdf@mango.fruits.de> <1135961696.4661.56.camel@localhost.localdomain> Message-ID: <20051230173245.GB4958@linux-1> On Fri, Dec 30, 2005 at 11:54:56AM -0500, Paul Davis wrote: > you don't know the correct priority to use. i imagine an api along the > lines of: > > jack_create_thread (pthread_t*, void* (thread_function)(void*), > void* arg, int relative_to_jack); > > the last argument would specify that the thread should run at, above or > below the jack RT thread(s) by a given amount. typical values would be > +1, 0, -1 etc. - It's fairly easy to find out a JACK client's thread priority - some of my apps, e.g. Aeolus do this to set their thread priorities relative to it. - It could be wise to express *all* (including JACK's) priorities relative to the maximum. That way things will still work when the kernel developers decide to revise their numbering scheme. - Some apps may want to run as well without linking to libjack, so I'm not so sure that this is the right place for a RT-thread creation routine. Anyway, unless you want to use capabilities or work around completely broken things such as NPTL 0.60, creating a RT thread *is* quite simple. If you are using an application framework or toolkit, and it provides safe communication between RT and e.g. GUI threads, then it probably will have a call to do it anyway. Best wishes to all ! -- FA From chris.cannam at ferventsoftware.com Fri Dec 30 12:25:44 2005 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Fri Dec 30 12:28:04 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. Message-ID: <760293967-1135963678-cardhu_blackberry.rim.net-25857-@engine22.bwc.produk.on.blackberry> Florian Schmidt writes: > Here's example output with rosegarden producing a > supposedly steady stream of 16th notes at 120 bpm: > [...] Those results certainly are pretty poor. We do have a very similar test in the Rosegarden tree (the complainer test) but it doesn't stress the system quite the way it seems your program does. I'll have to review the sequencer API and look at adding a separate RT MIDI thread as an alternative (which should be straightforward enough). The rationale for using queued events is simple -- ALSA provides the service, why duplicate it? -- but it's probably true that we've already spent far more time working around problems with it than we saved by not duplicating it. (Does anyone else use queued sequencer events in earnest?) Chris From chris.cannam at ferventsoftware.com Fri Dec 30 12:28:58 2005 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Fri Dec 30 12:31:20 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. Message-ID: <596651883-1135963872-cardhu_blackberry.rim.net-15688-@engine22.bwc.produk.on.blackberry> Florian Schmidt: > Yeah, i got a nice and juicy BUG in it (see below). So > this is what kills rosegarden regularly here when > run with RTC timing source. That'll be the chap. Mind you, I never saw the RTC- based timer measure significantly better than the system timer at 1000Hz. Although your measurements may vary, and it seems, probably would. Chris From ws at seh.de Fri Dec 30 13:01:46 2005 From: ws at seh.de (Werner Schweer) Date: Fri Dec 30 13:00:58 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051230180632.413acbe5@mango.fruits.de> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <200512301737.13502.ws@seh.de> <20051230180632.413acbe5@mango.fruits.de> Message-ID: <200512301901.46692.ws@seh.de> On Friday 30 December 2005 18:06, Florian Schmidt wrote: > On Fri, 30 Dec 2005 17:37:13 +0100 > > Werner Schweer wrote: ... > > > Last note about RT-linux kernels: its not _that_ important. Its > > only a micro optimization. A normal recent kernel works pretty well. > > If your normal kernel does not operate with sufficient low latencies, > > the RT-kernel will most likely also not work. > > I do not agree. While this is true for an otherwise unloaded system, it > is rather easy (on a vanilla kernel) to produce xruns by putting other > load on the system. > > The IRQ priorization provided by -rt kernels is extremely useful to > avoid these. It is _vital_ to run jackd with a priority higher than > those IRQ handlers not doing audio/midi stuff (network, disk, etc). The > soundcard IRQ handler must run with a high prio for this to work, too. > I'm not all too sure about whether it matters which of the two (jack or > soundcard irq) is higher though, as long as both are higher than other > irq handlers. higher priority thread can interrupt lower priority threads. What do you gain if the soundcard can interrupt the jack thread? I believe it does not matter. Interrupt routines on a well behaved system are using only some microseconds so it should not matter at all for audio purposes. Or do i miss something here? > > It is very useful to be able to do other stuff while audio/midi is > working uninterrupted. I got used to be able to compile a kernel > alongside running jackd with a periodsize of 32 or 16 frames :) which > means, i can play o.e. guitar while waiting for the damn compile to > finish. 32 or 16 frames is IMHO insanely low. Lets assume your keyboard is only 3.5m away from the drummer, you are about 10msec out of sync, which translates to about 256 frames. This works reliable on a vanilla kernel whatever you are doing in the background. An interesting question is what max. latencies are accepted for real live situations? I can comfortably play keyboard at 20msec latency. Something really bad is a timing _jitter_ of midi events. For some drumloops you can hear a jitter of 2ms or lower. Latencies are not so important for me but low jitter is. > > Flo > > P.S.: softsynths need to have their midi thread higher prio than jackd, > too, for the flawless midi timing to work. So i suppose it's time for > some bug reports to softsynth authors :) From rlrevell at joe-job.com Fri Dec 30 13:28:33 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Dec 30 13:28:46 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051230182517.6d9eb24d@mango.fruits.de> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <20051230182517.6d9eb24d@mango.fruits.de> Message-ID: <1135967314.31111.3.camel@mindpipe> On Fri, 2005-12-30 at 18:25 +0100, Florian Schmidt wrote: > On Fri, 30 Dec 2005 15:17:04 +0000 GMT > "Chris Cannam" wrote: > > > - ALSA sequencer can sync to RTC, but the > > associated module (snd-rtctimer) appears to hang > > some kernels solid when loaded or used. I don't have > > much information about that, but I can probably find > > out some more. > > Yeah, i got a nice and juicy BUG in it (see below). You had better report this to LKML like yesterday so 2.6.15 does not get released with this bug! Lee From rlrevell at joe-job.com Fri Dec 30 13:30:59 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Dec 30 13:31:04 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <200512301901.46692.ws@seh.de> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <200512301737.13502.ws@seh.de> <20051230180632.413acbe5@mango.fruits.de> <200512301901.46692.ws@seh.de> Message-ID: <1135967460.31111.6.camel@mindpipe> On Fri, 2005-12-30 at 19:01 +0100, Werner Schweer wrote: > higher priority thread can interrupt lower priority threads. What do > you gain if the soundcard can interrupt the jack thread? I believe > it does not matter. > Interrupt routines on a well behaved system are using only some > microseconds so it should not matter at all for audio purposes. > Or do i miss something here? I think you are right. It's not the relative priority of IRQ threads that matter (most IRQs run for far less than 1ms anyway and the soundcard IRQ thread and JACK should never contend) but the preemptibility of softirqs (and a few rude hardirqs like IDE) that makes the biggest difference. Long running softirqs can delay preemption by ~10ms with 2.6.14 OOTB. Lee From rlrevell at joe-job.com Fri Dec 30 13:32:38 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Dec 30 13:32:41 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> Message-ID: <1135967558.31111.9.camel@mindpipe> On Fri, 2005-12-30 at 15:17 +0000, Chris Cannam wrote: > - ALSA sequencer uses kernel timers by default and > of course they only run at 100 or 250Hz in many > kernels. > Not anymore, since 2.6.14 when the kernel developers decided to roll back HZ to 250 it uses the RTC by default. > - ALSA sequencer can sync to RTC, but the > associated module (snd-rtctimer) appears to hang > some kernels solid when loaded or used. I don't have > much information about that, but I can probably find > out some more. > Some bugs in the RTC driver were fixed in the 2.6.13.x series, make sure these users try a newer kernel. Lee From strombrg at dcs.nac.uci.edu Fri Dec 30 13:56:34 2005 From: strombrg at dcs.nac.uci.edu (Dan Stromberg) Date: Fri Dec 30 13:56:57 2005 Subject: [linux-audio-dev] Olypus voice recorder - codec? Message-ID: <1135968994.9164.103.camel@seki.nac.uci.edu> Hi folks. This message does get into driver specifics to an extent, but I'm mostly coming to list for advice on how to find what "mystery codec" is being used. I've been putting some of the tiny bit of actual freetime I get during this winter holiday :), into trying to get a libusb-based driver going for my little Olympus VN480PC. It's a digital voice recorder that comes with a USB cable for transferring voice recordings to a computer, and the accompanying software is windows only. I'd very much like to be able to do this transfer using linux instead of needing windows though. I think I -might- have the protocol mostly figured using a USB sniffer on the windows side, but that may prove to be the easy part of this project. :-S What I'm faced with now, is I have 10K of data which I'm assuming just about has to be the voice data in some format or other - but it isn't clear what format it's in. Toward trying to figure out the format, I've: 1) Computed the difference in the lengths of the apparently-voice data transferred via USB, and the "data" section of the resulting .wav file. They do not differ by a constant - so it's not just a matter of tacking on a header. 2) Computed the quotient of the lengths of the apparently-voice data transferred via USB, and the "data" section of the resulting .wav file. They do not differ by a constant factor - so it's not just a matter of converting, for example, shorts to reals again and again, for example, in which case the lengths, I would think, should differ by a constant factor of 2. 3) Symlinked a file containing the data transferred via USB, to all of the file extensions known to sox, and attempted to use sox to convert those files to .wav. None of the conversions succeeded. 4) Wrote a small python program to treat the data transferred via USB as data to be stuffed into the "data" section of a .wav file, and created a series of .wav files with all format types from 0 to 999. sndfile-info did not give errors for 9 of these, but none of them look or sound right in gnusound. 5) Googled about olympus and voice/audio codecs, to see if there is a proprietary one they favor. It appears they were involved in the design of the "DSS" format. 6) Downloaded "DSS Player Lite" from Olympus' web site, and copied the data transferred via USB to "hi.dss". However, DSS Player Lite did not recognize the file format. Does anyone have any thoughts about what else I might try to see what format this data is in, and/or convert it to a known format? I've got detailed documentation of most of what I've done so far on this project at http://dcs.nac.uci.edu/~strombrg/VN480PC/ The page includes some .wav's, a binary file I'm assuming is voice data in a mystery codec, full USB sniffer logs, and so on. Does anyone have any suggestions - especially toward how to convert that "likely voice data" in the USB Sniff to some sort of known and supported-on-linux codec? Thanks! From chris.cannam at ferventsoftware.com Fri Dec 30 14:06:29 2005 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Fri Dec 30 14:08:54 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. Message-ID: <1667907545-1135969723-cardhu_blackberry.rim.net-3243-@engine07.bwc.produk.on.blackberry> Me: > I'll have to review the sequencer API and look at > adding a separate RT MIDI thread as an alternative Actually no, hang on a minute. First I want to know more about why the ALSA sequencer queue doesn't work better here. It's all very well saying it's irrelevant now that it's so easy to create RT threads, but I think that's bogus. Probably a substantial majority of Rosegarden users doing MIDI only are using systems on which it isn't possible for a random user to create RT threads at all. For these users, the ALSA sequencer ought to be able to do a lot better than an ordinary unprivileged thread can. I'd like to know why it might not. I'm not at a proper computer just now, to delve through code - anyone have any more idea about this? Chris From musical_snake at gmx.de Fri Dec 30 14:54:53 2005 From: musical_snake at gmx.de (Ralf Beck) Date: Fri Dec 30 14:56:11 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry><200512301737.13502.ws@seh.de><20051230180632.413acbe5@mango.fruits.de> <200512301901.46692.ws@seh.de> Message-ID: <004801c60d7a$eca69870$0100a8c0@NOTEBOOK1> > higher priority thread can interrupt lower priority threads. What do > you gain if the soundcard can interrupt the jack thread? I believe > it does not matter. For proper midi handling, all threads, irq and user, related to midi should have a higher priority than that of the jack thread(s). Suppose a jack thread is running and your midiin device irq comes in but not through, because the device's irq thread has lower priority and does not get scheduled! Ralf From pedro.lopez.cabanillas at gmail.com Fri Dec 30 16:27:56 2005 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Fri Dec 30 16:28:01 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <200512301701.jBUH197n032711@roar.music.columbia.edu> References: <200512301701.jBUH197n032711@roar.music.columbia.edu> Message-ID: <200512302227.56472.pedro.lopez.cabanillas@gmail.com> On Friday 30 December 2005 17:37, Werner Schweer wrote: > The ALSA seq api is from ancient time were no realtime threads were > available in linux. Only a kernel driver could provide usable > midi timing. But with the introduction of RT threads the > ALSA seq api is obsolete IMHO. I don't agree with this statement. IMHO, a design based on raw MIDI ports used like simple Unix file descriptors, and every user application implementing its own event schedule mechanism is the ancient and traditional way, and it should be considered obsolete now in Linux since we have the advanced queueing capabilities provided by the ALSA sequencer. You guys are talking here about MIDI timing, considering only the event scheduling point of view, as if Rosegarden or MusE were simple MIDI players. Of course, playing beats on time is a required feature. But my bigger concern about MIDI timing issues is when you are *recording* events. Here is where ALSA queues, providing accurate timestamps for incoming events, are so good. It could be the absolute winner if problems like the audio synchronization and slave MTC synchronization were solved likewise. Regards, Pedro From paul at linuxaudiosystems.com Fri Dec 30 17:10:44 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Fri Dec 30 17:08:15 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <200512302227.56472.pedro.lopez.cabanillas@gmail.com> References: <200512301701.jBUH197n032711@roar.music.columbia.edu> <200512302227.56472.pedro.lopez.cabanillas@gmail.com> Message-ID: <1135980644.4661.62.camel@localhost.localdomain> On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote: > On Friday 30 December 2005 17:37, Werner Schweer wrote: > > > The ALSA seq api is from ancient time were no realtime threads were > > available in linux. Only a kernel driver could provide usable > > midi timing. But with the introduction of RT threads the > > ALSA seq api is obsolete IMHO. > > I don't agree with this statement. IMHO, a design based on raw MIDI ports used > like simple Unix file descriptors, and every user application implementing > its own event schedule mechanism is the ancient and traditional way, and it > should be considered obsolete now in Linux since we have the advanced > queueing capabilities provided by the ALSA sequencer. low latency apps don't want queuing they just want routing. this is why the ALSA sequencer is obsolete for such apps. frank (v.d.p) had the right idea back when he started this, but i agree with werner's perspective that the queuing facilities are no longer relevant, at least not for "music" or "pro-audio" applications. > You guys are talking here about MIDI timing, considering only the event > scheduling point of view, as if Rosegarden or MusE were simple MIDI players. > Of course, playing beats on time is a required feature. But my bigger concern > about MIDI timing issues is when you are *recording* events. Here is where > ALSA queues, providing accurate timestamps for incoming events, are so good. better than an RT user space thread? sure. by a few microseconds. > It could be the absolute winner if problems like the audio synchronization > and slave MTC synchronization were solved likewise. what problems? JACK demonstrates perfect audio sync in the only sensible way there is (the same way every other system does it); several JACK clients have MTC slave capabilities, including ardour, and it has nothing whatsoever to do with the ALSA sequencer. From fons.adriaensen at skynet.be Fri Dec 30 18:04:26 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Fri Dec 30 17:58:34 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1135980644.4661.62.camel@localhost.localdomain> References: <200512301701.jBUH197n032711@roar.music.columbia.edu> <200512302227.56472.pedro.lopez.cabanillas@gmail.com> <1135980644.4661.62.camel@localhost.localdomain> Message-ID: <20051230230426.GC4958@linux-1> On Fri, Dec 30, 2005 at 05:10:44PM -0500, Paul Davis wrote: > On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote: > > On Friday 30 December 2005 17:37, Werner Schweer wrote: > > > > > The ALSA seq api is from ancient time were no realtime threads were > > > available in linux. Only a kernel driver could provide usable > > > midi timing. But with the introduction of RT threads the > > > ALSA seq api is obsolete IMHO. > > > > I don't agree with this statement. IMHO, a design based on raw MIDI ports used > > like simple Unix file descriptors, and every user application implementing > > its own event schedule mechanism is the ancient and traditional way, and it > > should be considered obsolete now in Linux since we have the advanced > > queueing capabilities provided by the ALSA sequencer. > > low latency apps don't want queuing they just want routing. this is why > the ALSA sequencer is obsolete for such apps. frank (v.d.p) had the > right idea back when he started this, but i agree with werner's > perspective that the queuing facilities are no longer relevant, at least > not for "music" or "pro-audio" applications. I'd agree with Pedro on this. 1. If things have to be timed accurately, it seem logical to concentrate this activity at one point. At least then the timing will be consistent, you can impose priority rules in case of conflict, etc. 2. Translating from data having an implicit or explicit timestamp associated with it, to a physical signal having a real physical time is something that belongs at the system or even hardware level, just as it does for audio. When you are dealing with midi in software, it should just be timetagged data, just as audio samples are. The only place where the timing matters is when midi is output on a real electrical midi port. Trying to deliver e.g. note-on events from a software sequencer to a soft synth exactly 'on time' is a waste of effort - what the synth needs to know is not 'when' on some physical time scale the note starts, but at which sample it should start. In other words, the note-on event needs a timestamp that can be converted easily to a frame time. -- FA From mista.tapas at gmx.net Fri Dec 30 18:31:09 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 18:31:16 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <004801c60d7a$eca69870$0100a8c0@NOTEBOOK1> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <200512301737.13502.ws@seh.de> <20051230180632.413acbe5@mango.fruits.de> <200512301901.46692.ws@seh.de> <004801c60d7a$eca69870$0100a8c0@NOTEBOOK1> Message-ID: <20051231003109.3dd068ad@mango.fruits.de> On Fri, 30 Dec 2005 20:54:53 +0100 "Ralf Beck" wrote: > Suppose a jack thread is running and your midiin device irq comes in but not > through, > because the device's irq thread has lower priority and does not get > scheduled! This is an interesting question: How is midi activity on physical ports handled? Is it polled? Or is the soundcard IRQ used for this, too? In the latter case the soundcard IRQ should definetly have a higher prio than all jack stuff. Flo -- Palimm Palimm! http://tapas.affenbande.org From rlrevell at joe-job.com Fri Dec 30 18:40:20 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Dec 30 18:40:25 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051231003109.3dd068ad@mango.fruits.de> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <200512301737.13502.ws@seh.de> <20051230180632.413acbe5@mango.fruits.de> <200512301901.46692.ws@seh.de> <004801c60d7a$eca69870$0100a8c0@NOTEBOOK1> <20051231003109.3dd068ad@mango.fruits.de> Message-ID: <1135986021.31111.42.camel@mindpipe> On Sat, 2005-12-31 at 00:31 +0100, Florian Schmidt wrote: > On Fri, 30 Dec 2005 20:54:53 +0100 > "Ralf Beck" wrote: > > > Suppose a jack thread is running and your midiin device irq comes in but not > > through, > > because the device's irq thread has lower priority and does not get > > scheduled! > > This is an interesting question: How is midi activity on physical ports > handled? Is it polled? Or is the soundcard IRQ used for this, too? In > the latter case the soundcard IRQ should definetly have a higher prio > than all jack stuff. The relative priorities of the JACK and soundcard IRQs really don't matter because they never contend - one is woken up by the other. Lee From mista.tapas at gmx.net Fri Dec 30 18:52:41 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Dec 30 18:52:46 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1135986021.31111.42.camel@mindpipe> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <200512301737.13502.ws@seh.de> <20051230180632.413acbe5@mango.fruits.de> <200512301901.46692.ws@seh.de> <004801c60d7a$eca69870$0100a8c0@NOTEBOOK1> <20051231003109.3dd068ad@mango.fruits.de> <1135986021.31111.42.camel@mindpipe> Message-ID: <20051231005241.2fafcc14@mango.fruits.de> On Fri, 30 Dec 2005 18:40:20 -0500 Lee Revell wrote: > The relative priorities of the JACK and soundcard IRQs really don't > matter because they never contend - one is woken up by the other. This is true for the audio only case. Imagine for now, that MIDI activity i shandled by IRQ's, too. Let's further assume jackd's prio is higher than the soundcard IRQ (which is there for both audio and midi in this scenario). Ok, some audio irq has happened and jackd is doing its thing. Now a soundcard IRQ is generated for an incoming midi event. As the soundcard handler thread prio is lower than jackd's it will not get to run until jackd's process loop is finished. All of this depends on whether physical port midi activity is really handled by IRQ's too. Anyone know more? Flo -- Palimm Palimm! http://tapas.affenbande.org From chris.cannam at ferventsoftware.com Fri Dec 30 19:00:15 2005 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Fri Dec 30 19:02:54 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. Message-ID: <1201192609-1135987349-cardhu_blackberry.rim.net-15454-@engine22.bwc.produk.on.blackberry> Paul Davis: > frank (v.d.p) had the right idea back when he > started this Huh? Started what? Chris From paul at linuxaudiosystems.com Sat Dec 31 07:59:40 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat Dec 31 07:57:20 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1201192609-1135987349-cardhu_blackberry.rim.net-15454-@engine22.bwc.produk.on.blackberry> References: <1201192609-1135987349-cardhu_blackberry.rim.net-15454-@engine22.bwc.produk.on.blackberry> Message-ID: <1136033980.4661.70.camel@localhost.localdomain> On Sat, 2005-12-31 at 00:00 +0000, Chris Cannam wrote: > Paul Davis: > > frank (v.d.p) had the right idea back when he > > started this > > Huh? Started what? the ALSA sequencer. From paul at linuxaudiosystems.com Sat Dec 31 08:03:06 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat Dec 31 08:02:21 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <20051230230426.GC4958@linux-1> References: <200512301701.jBUH197n032711@roar.music.columbia.edu> <200512302227.56472.pedro.lopez.cabanillas@gmail.com> <1135980644.4661.62.camel@localhost.localdomain> <20051230230426.GC4958@linux-1> Message-ID: <1136034186.4661.75.camel@localhost.localdomain> On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen wrote: > On Fri, Dec 30, 2005 at 05:10:44PM -0500, Paul Davis wrote: > > On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote: > > > On Friday 30 December 2005 17:37, Werner Schweer wrote: > > > > > > > The ALSA seq api is from ancient time were no realtime threads were > > > > available in linux. Only a kernel driver could provide usable > > > > midi timing. But with the introduction of RT threads the > > > > ALSA seq api is obsolete IMHO. > > > > > > I don't agree with this statement. IMHO, a design based on raw MIDI ports used > > > like simple Unix file descriptors, and every user application implementing > > > its own event schedule mechanism is the ancient and traditional way, and it > > > should be considered obsolete now in Linux since we have the advanced > > > queueing capabilities provided by the ALSA sequencer. > > > > low latency apps don't want queuing they just want routing. this is why > > the ALSA sequencer is obsolete for such apps. frank (v.d.p) had the > > right idea back when he started this, but i agree with werner's > > perspective that the queuing facilities are no longer relevant, at least > > not for "music" or "pro-audio" applications. > > I'd agree with Pedro on this. > > 1. If things have to be timed accurately, it seem logical to concentrate > this activity at one point. At least then the timing will be consistent, > you can impose priority rules in case of conflict, etc. in a low latency *live* system, "timing" doesn't really exist outside of the current period. there is no concept of "when" that exists beyond the end of the current period. > 2. Translating from data having an implicit or explicit timestamp > associated with it, to a physical signal having a real physical time is > something that belongs at the system or even hardware level, just as it > does for audio. > When you are dealing with midi in software, it should just be timetagged > data, just as audio samples are. The only place where the timing matters > is when midi is output on a real electrical midi port. > Trying to deliver e.g. note-on events from a software sequencer to a soft > synth exactly 'on time' is a waste of effort - what the synth needs to know > is not 'when' on some physical time scale the note starts, but at which > sample it should start. In other words, the note-on event needs a timestamp > that can be converted easily to a frame time. well, clearly, yes. but the point of the ALSA sequencer's queuing abilities (as distinct from its routing abilities) is really to schedule stuff "far off" in the future. my claim is that live applications never need scheduling beyond the of the end of the current period. as a result, for this class of applications, most of the ALSA sequencer's capabilities are redundant, which is compounded because it currently has no way of providing sufficiently accurate scheduling (to be fair, at the moment neither does user space). From mista.tapas at gmx.net Sat Dec 31 08:15:32 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sat Dec 31 08:15:38 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <200512301901.46692.ws@seh.de> References: <153469421-1135955959-cardhu_blackberry.rim.net-8858-@engine07.bwc.produk.on.blackberry> <200512301737.13502.ws@seh.de> <20051230180632.413acbe5@mango.fruits.de> <200512301901.46692.ws@seh.de> Message-ID: <20051231141532.503be25c@mango.fruits.de> On Fri, 30 Dec 2005 19:01:46 +0100 Werner Schweer wrote: > higher priority thread can interrupt lower priority threads. What do > you gain if the soundcard can interrupt the jack thread? I believe > it does not matter. Midi input is generating IRQ's, too (at least it appears so by watching /proc/interrupts with midi activity only (i.e. hook up your midi in to a midi monitor, as it seems withouth connections ALSA doesn't bother about the MIDI at all)). So having the soundcard IRQ handler thread prio higher than jackd makes sense to get stable midi input timing. > Interrupt routines on a well behaved system are using only some > microseconds so it should not matter at all for audio purposes. > Or do i miss something here? I'm not sure. But experience shows (to me at least) that a -rt kernel, where i can make i.e. the hard disk controller IRQ's lower prio than jackd and the soundcard irq, is handling additional load on the system better than a non -rt kernel without this tuning. > > It is very useful to be able to do other stuff while audio/midi is > > working uninterrupted. I got used to be able to compile a kernel > > alongside running jackd with a periodsize of 32 or 16 frames :) which > > means, i can play o.e. guitar while waiting for the damn compile to > > finish. > > 32 or 16 frames is IMHO insanely low. Lets assume your keyboard is > only 3.5m away from the drummer, you are about 10msec out of sync, which > translates to about 256 frames. This works reliable on a vanilla kernel > whatever you are doing in the background. It didn't for me. Vanilla generally is a bit more prone to xruns than -rt is, even at large periodsizes (> 64 frames). But if its good enough for you.. ;) I suppose it also depends on what exact hw you use. > An interesting question is what max. latencies are accepted for real live > situations? Well, we had this discussion earlier :) Always keep in mind that latencies are accumulative and people are different. I like to use 32 frames when playing my guitar through the computer, although 64 frames is good enough, too. 128 or 256 frames definitely start to feel weird, especially when effects add additional latency. Keep in mind that i additionally run around in my room :) So the distance from the speakers produces additional latency. > I can comfortably play keyboard at 20msec latency. > Something really bad is a timing _jitter_ of midi events. For > some drumloops you can hear a jitter of 2ms or lower. Latencies are > not so important for me but low jitter is. 20ms would be way too much for me. I agree though that midi jitter is also bad :) Flo -- Palimm Palimm! http://tapas.affenbande.org From chris.cannam at ferventsoftware.com Sat Dec 31 09:58:24 2005 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Sat Dec 31 10:01:15 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. Message-ID: <2102001516-1136041249-cardhu_blackberry.rim.net-24871-@engine12.bwc.produk.on.blackberry> Paul Davis: > most of the ALSA sequencer's > capabilities are redundant, which is compounded > because it currently has > no way of providing sufficiently accurate scheduling You say this as if it were self-evident, when it's been the subject of much of this thread. _Does_ it have no way of providing sufficiently accurate scheduling? If not, why not? This would imply that there is in fact no way for a userspace application on a normal Linux distribution to provide MIDI timing accurate enough to be perceived as correct in all circumstances. Chris From paul at linuxaudiosystems.com Sat Dec 31 10:12:57 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sat Dec 31 10:10:28 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <2102001516-1136041249-cardhu_blackberry.rim.net-24871-@engine12.bwc.produk.on.blackberry> References: <2102001516-1136041249-cardhu_blackberry.rim.net-24871-@engine12.bwc.produk.on.blackberry> Message-ID: <1136041977.4661.80.camel@localhost.localdomain> On Sat, 2005-12-31 at 14:58 +0000, Chris Cannam wrote: > Paul Davis: > > most of the ALSA sequencer's > > capabilities are redundant, which is compounded > > because it currently has > > no way of providing sufficiently accurate scheduling > > You say this as if it were self-evident, when it's been > the subject of much of this thread. _Does_ it have > no way of providing sufficiently accurate scheduling? > If not, why not? i guess it all depends on one's definition of "sufficient". my take is that there are several MIDI h/w boxes that guarantee MIDI delivery to a resolution that matches the wire protocol (1/3msec). until we have scheduling capabilities that match this (or better), i don't feel comfortable calling them "sufficient". From fons.adriaensen at skynet.be Sat Dec 31 11:01:06 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Dec 31 10:55:18 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <1136034186.4661.75.camel@localhost.localdomain> References: <200512301701.jBUH197n032711@roar.music.columbia.edu> <200512302227.56472.pedro.lopez.cabanillas@gmail.com> <1135980644.4661.62.camel@localhost.localdomain> <20051230230426.GC4958@linux-1> <1136034186.4661.75.camel@localhost.localdomain> Message-ID: <20051231160106.GA5044@linux-1> On Sat, Dec 31, 2005 at 08:03:06AM -0500, Paul Davis wrote: > On Sat, 2005-12-31 at 00:04 +0100, fons adriaensen wrote: > > 1. If things have to be timed accurately, it seem logical to concentrate > > this activity at one point. At least then the timing will be consistent, > > you can impose priority rules in case of conflict, etc. > > in a low latency *live* system, "timing" doesn't really exist outside of > the current period. there is no concept of "when" that exists beyond the > end of the current period. In a live situation, yes. In that case there is no point at all to try and deliver events with sub-cycle accuracy, except to a physical port. For a soft-synth you don't even know _when_ in the cycle its audio code will be called. So all events should be available at the start of the cycle, and if you need sub-cycle precision or minimal jitter, be timetagged. > well, clearly, yes. but the point of the ALSA sequencer's queuing > abilities (as distinct from its routing abilities) is really to schedule > stuff "far off" in the future. my claim is that live applications never > need scheduling beyond the of the end of the current period. as a > result, for this class of applications, most of the ALSA sequencer's > capabilities are redundant, which is compounded because it currently has > no way of providing sufficiently accurate scheduling (to be fair, at the > moment neither does user space). Whatever system becomes available to user space can be used by ALSA as well, so ALSA will never be in a worse situation than any app. Even in a live context you may want to schedule e.g. MTC events in the near (but more than 1 cycle ahead) future. Having a central scheduler you could arrange for them to have priority over anything else. This would be quite difficult to do when for example one app is scheduling its MTC events and anothor produces a stream of control events going to the same port. -- FA From pedro.lopez.cabanillas at gmail.com Sat Dec 31 11:14:14 2005 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Sat Dec 31 11:14:32 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <200512302354.jBUNrv7n011781@roar.music.columbia.edu> References: <200512302354.jBUNrv7n011781@roar.music.columbia.edu> Message-ID: <200512311714.14953.pedro.lopez.cabanillas@gmail.com> On Saturday 31 December 2005 00:52, Florian Schmidt wrote: > All of this depends on whether physical port midi activity is really > handled by IRQ's too. Anyone know more? I don't know every MIDI interface details, but there are many different variations. Please, somebody with better knowledge could provide additional info and correct my very probable mistakes. USB MIDI interfaces don't generate interrupts. Instead, this is done by the USB host controller (EHCI/OHCI/UHCI). The driver for these devices provide an interrupt handler not directly, but indirectly (the in/out URB completion handlers). So yes, this device type may be considered interrupt-driven. The oldest MIDI interface for PCs was the Roland MPU-401. It had two operational modes: Intelligent and UART mode. Intelligent mode was necessary because the low power of early personal computers CPUs. This intelligent mode required IRQ handlers for both MIDI input and output operations, and to control the internal timer used for hardware scheduling and event timestamping, and also for external MTC/SMPTE synchronization. It was a rather sofisticated piece of hardware, but there is not an ALSA driver for these devices (and I don't know a single manufacturer selling it nowadays). The MPU-401 UART mode doesn't provide an interrupt signal to finish the output completion, so you must use polling for output (it provides an interrupt only for incoming events). There is an ALSA driver for this mode, that is used also by many consumer sound cards emulating the MPU-401. I wouldn't recommend to use these MIDI interfaces. Other chips, as the Ensoniq 1370/1371 used in some cheap SoundBlaster products, included a better UART mode, providing interrupts for both reception and transmission. There is also an ALSA driver for the 16550 UART, that can be used with a few external devices like the Roland Canvas and the Midiator devices. Regards, Pedro From chris.cannam at ferventsoftware.com Sat Dec 31 11:49:20 2005 From: chris.cannam at ferventsoftware.com (Chris Cannam) Date: Sat Dec 31 11:52:07 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. Message-ID: <20875293-1136047895-cardhu_blackberry.rim.net-29535-@engine10.bwc.produk.on.blackberry> Paul Davis: > i guess it all depends on one's definition of > "sufficient". my take is that there are several MIDI > h/w boxes that guarantee MIDI delivery to a > resolution that matches the wire protocol > (1/3msec). until we have scheduling capabilities that > match this (or better), i don't feel comfortable > calling them "sufficient". Ah, I see. I've no argument with that, but it isn't quite what I thought you were referring to. Chris From pedro.lopez.cabanillas at gmail.com Sat Dec 31 13:58:38 2005 From: pedro.lopez.cabanillas at gmail.com (Pedro Lopez-Cabanillas) Date: Sat Dec 31 13:58:44 2005 Subject: [linux-audio-dev] Audio/Midi system - RT prios.. In-Reply-To: <200512302354.jBUNrv7n011781@roar.music.columbia.edu> References: <200512302354.jBUNrv7n011781@roar.music.columbia.edu> Message-ID: <200512311958.38659.pedro.lopez.cabanillas@gmail.com> On Saturday 31 December 2005 17:10, Paul Davis wrote: > On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote: > > On Friday 30 December 2005 17:37, Werner Schweer wrote: > > > The ALSA seq api is from ancient time were no realtime threads were > > > available in linux. Only a kernel driver could provide usable > > > midi timing. But with the introduction of RT threads the > > > ALSA seq api is obsolete IMHO. > > > > I don't agree with this statement. IMHO, a design based on raw MIDI ports > > used ? like simple Unix file descriptors, and every user application > > implementing its own event schedule mechanism is the ancient and > > traditional way, and it should be considered obsolete now in Linux since > > we have the advanced queueing capabilities provided by the ALSA > > sequencer. > > low latency apps don't want queuing they just want routing. this is why > the ALSA sequencer is obsolete for such apps. frank (v.d.p) had the > right idea back when he started this, but i agree with werner's > perspective that the queuing facilities are no longer relevant, at least > not for "music" or "pro-audio" applications. Many professional musicians want MIDI capabilities on their PCs because they already own (or want to have) electronic musical instruments communicating via MIDI. This means that the computer is another piece of musical equipment in the musician's studio/network. The kind of scenario you are painting about low latency applications seems limited to soft synths listening to sequencing applications. Using MIDI to this kind of communication between two processes running in the same machine looks a bit overkill to me. MusE has synth plugins, and Rosegarden has DSSI synth plugins, without ALSA sequencer being involved here. > > It could be the absolute winner if problems like the audio > > synchronization ? and slave MTC synchronization were solved likewise. > > what problems? JACK demonstrates perfect audio sync in the only sensible > way there is (the same way every other system does it); several JACK > clients have MTC slave capabilities, including ardour, and it has > nothing whatsoever to do with the ALSA sequencer. Exactly. Please, excuse me my poor English. I mean functionality instead of problem. Let me reword the sentence: ALSA could be even better if there were another universal mechanism available for every ALSA application, providing an easy and consistent way to synchronize a queue with an external MTC master, without needing to recode the whole process for each application. I know that Ardour provides slave MTC synchronization, and also does Rosegarden. Each one uses a different approach, and in the future there will be many more better or worse implementations. I like the way Rosegarden solves it, using the ALSA sequencer queue skew parameter. I guess that we can build another ALSA sequencer client, either a kernel module or a userspace one, accepting MTC input and translating the MTC sysex messages received to skew in some queues used also by any other ALSA clients. Comments? Regards, Pedro