Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] sfront 0.85 10/13/02 released

by John Lazzaro

Pick up sfront 0.85 -- 10/13/02 at: http://www.cs.berkeley.edu/~lazzaro/sa/index.html [1] Mac OS X support for real-time MIDI control, using the -cin coremidi control driver. Up to four external MIDI sources are recognized. Virtual sources are ignored; expect virtual source support in a future release. [2] Mac OS X memory locking now works in normal user processes, and is no longer limited to root. ----- All the changes in 0.85 are OS X specific, but thought I'd post this here in case people are curious about OS X porting ... With this release, all of the real-time examples in the sfront distribution run under Mac OS X. Specifically, its now it's possible to use OS X as a Structured Audio softsynth -- I've been running my PowerBook this way with 2ms CoreAudio buffers, with MIDI input from my controller via an Edirol UM-1S USB MIDI interface, and audio output via the headphone jack on the Powerbook, and things work glitch-free. Also, because audio and MIDI are both virtualized under OS X, its possible to run multiple ./sa softsynths in parallel (i.e. from different Terminal windows) and get useable layering ... although in most cases, you'd be better off doing your layering inside a single SA engine. To see the -cin coremidi control driver in action, run the sfront/examples/rtime/linbuzz softsynth, it will find external MIDI sources (up to 4, no virtual source support ...) and use them to drive the SA program in real-time. In the linbuzz example, the pitch wheel (set up to do vibrato) mod wheel (spectral envelope) and channel volume controllers are all active -- you can look at the linbuzz.saol SAOL program to see how they are used. The actual CoreMIDI code is in: sfront/src/lib/csys/coremidi.c The most interesting aspect of this code is that a single AF_UNIX SOCK_DGRAM socketpair pipe (named csysi_readproc_pipepair) is used for communication between an arbitrary number of CoreMIDI readprocs (one for each active source) and the SA sound engine (which runs inside the CoreAudio callback -- the actual main thread sleeps and does nothing). Writing the pipe is blocking (but should rarely block, and never for significant time), but reading the pipe is non-blocking. The semantics of the AF_UNIX SOCK_DGRAM (AF_UNIX is reliable, SOCK_DGRAM guarantees the messages from the CoreMIDI readprocs don't mix) makes it a good choice for doing the multi-source MIDI merge. The actual messages sent in the pipe consists of a preamble to identify the readproc, and the (error-checked for SA semantics) MIDI commands in each MIDIPacket. At this point, the Linux and OS X real-time implementations support all of the same features (audio input, audio output, MIDI In, RTP networking) ... I'm not sure if AudioUnits support makes sense for sfront, I'll probably take a closer look at the issue soon ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

23 years, 1 month

[linux-audio-dev] latency performance of 2.4 and 2.5...

by Joern Nettingsmeier

hi andrew, hi everyone ! as per your request, i fearlessly built and booted 2.5.41 with preemption enabled. although it was my first take at the dev kernel, it went very smoothly :-D anyway, it seems to perform worse than 2.4.20-pre1-lowlatency. it feels very snappy on startup, but under load it is a lot less responsive to user interaction. i have run benno senoner's latencytest on both kernels. you can see the results at http://spunk.dnsalias.org/latencytest . for me, the biggest problem seems to be soft-raid. i have my /var partition striped over 2 scsi disks, and accessing them causes huge latency peaks. is there any chance to get this under control ? i don't have a spare disk around, so i can't easily compare to non-raid, but i'm quite sure it's the source of the problem, because people with similar hardware are doing fine. other than that, there were a few peaks under /proc stress, but they are not easily reproducible. i have not yet tested your mm-patches due to a compile failure (log is attached below). i used http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.41/2.5.41-mm3/2.5.41-mm3.…. if there's any patches to try or more benchmarks to run, let me know. best, jörn *** Hardware: Dual-P3 @ 600Mhz, 512MB PC100 SDRAM, ASUS P2B-DS one 4G IBM DCAS SCSI disk (/), 2 9G COMPAQ SCSI disks (/var, soft-RAID 0), SCSI CDROM and CDR, no IDE devices. Soundcards: SB Live (used during the tests) and Ensoniq 1371 (idle) The audio file that was played back during the tests came over NFS. *** make -f init/Makefile Generating include/linux/compile.h (updated) gcc -Wp,-MD,init/.version.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic -fomit-frame-pointer -nostdinc -iwithprefix include -DKBUILD_BASENAME=version -c -o init/version.o init/version.c ld -m elf_i386 -r -o init/built-in.o init/main.o init/version.o init/do_mounts.o ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o --start-group arch/i386/kernel/built-in.o arch/i386/mm/built-in.o arch/i386/mach-generic/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o lib/lib.a arch/i386/lib/lib.a drivers/built-in.o sound/built-in.o arch/i386/pci/built-in.o net/built-in.o --end-group -o .tmp_vmlinux1 fs/built-in.o: In function `isofs_put_super': fs/built-in.o(.text+0x390e5): undefined reference to `unload_nls' fs/built-in.o: In function `isofs_fill_super': fs/built-in.o(.text+0x39f0b): undefined reference to `load_nls' fs/built-in.o(.text+0x39f25): undefined reference to `load_nls_default' fs/built-in.o(.text+0x3a0c6): undefined reference to `unload_nls' fs/built-in.o: In function `wcsntombs_be': fs/built-in.o(.text+0x3c60b): undefined reference to `utf8_wctomb' make: *** [.tmp_vmlinux1] Error 1 -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)

23 years, 1 month

[linux-audio-dev] Tapiir

by Miha Tomsic

Hello Maarten and other LAD(y)s! I am having some problems with tapiir 0.6. It seem's I can't get it to run with SCHED_RR. I can run it with suid or as root and still I am getting: josef:/usr/src/tapiir-0.6/src# ./tapiir !!!Scheduler set to Round Robin with priority 99 FAILED!!! Make sure you are root, or that tapiir has the suid flag set ( chmod 4755 ) Any idea why this is happening? Thanks and take care, Miha...

23 years, 1 month

[linux-audio-dev] Tk Ecasound 0.8.1 Released!

by Luis Pablo Gasparotto

Download it from: http://www.sourceforge.net/projects/tkeca Changes: - Bug fixed in Close/Ok button in Recording/Mixdown Properties Windows Regards, Luis Pablo Ahora pod�s usar Yahoo! Messenger desde tu celular. Aprend� c�mo hacerlo en Yahoo! M�vil: http://ar.mobile.yahoo.com/sms.html

23 years, 1 month

[linux-audio-dev] Tk Ecasound 0.8.0 Released!

by Luis Pablo Gasparotto

Download it from: http://www.sourceforge.net/projects/tkeca Changes: - Recording / Mixdown properties windows Regards, Luis Pablo Ahora pod�s usar Yahoo! Messenger desde tu celular. Aprend� c�mo hacerlo en Yahoo! M�vil: http://ar.mobile.yahoo.com/sms.html

23 years, 1 month

Re: [linux-audio-dev] latency performance of 2.4 and 2.5...

by Joern Nettingsmeier

Peter L Jones wrote: > > On Friday 11 Oct 2002 13:48, Joern Nettingsmeier wrote: > [snip] > > i have run benno senoner's latencytest on both kernels. you can see the > > results at > > > > http://spunk.dnsalias.org/latencytest . > > > > Jörn, could you post the latencytest URL, please. > > Thanks, > > -- Peter http://www.gardena.net/benno/linux/latencytest-0.42-png.tar.gz -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)

23 years, 1 month

[linux-audio-dev] Meterbridge 0.0.5

by Steve Harris

http://plugin.org.uk/meterbridge/ New features: Jellyfish meter (aka. stereo phase meter) Can choose number of columns Signal freezes if you click left mouse button on the window Some segfaults fixed Outstanding problems: Uses contraversial rewiring connection to inputs Needle graphics still a bit crap Inefficient - Steve

23 years, 1 month

RE: [linux-audio-dev] Needing advice on implementing MIDI in my app (RTMix)

by John Lazzaro

> 2) Can I use DMIDI in combination with TCP/IP (I saw you mentioned UDP > on your site)? If you're sending over IP, you should also look at MWPP, an RTP packetization for MIDI under development in the IETF. See: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

23 years, 1 month

RE: [linux-audio-dev] Needing advice on implementing MIDI in my app (RTMix)

by Ivica Bukvic

Thanks for a quick reply. One more question: 1) Is there good documentation to be found, or even better, source code? 2) Can I use DMIDI in combination with TCP/IP (I saw you mentioned UDP on your site)? 3) Does application have to be DMIDI-aware in order to be able to send/receive MIDI via DMIDI server or does DMIDI server simply act transparently between sender and receiver (if they are presumably on the same machine)? Again, thanks for your help! Sincerely, Ivica Ico Bukvic > -----Original Message----- > From: Phil Kerr [mailto:philkerr@elec.gla.ac.uk] > Sent: Thursday, October 10, 2002 9:49 PM > To: Ivica Bukvic > Subject: Re: [linux-audio-dev] Needing advice on implementing MIDI in my > app (RTMix) > > Hi Ivica, > > DMIDI may be of some use to you. You can have one DMIDI server and your > MIDI > applications can broadcast DMIDI data. You use the server to isolate you > from > hardware and MIDI API's > > http://www.dmidi.org > > Cheers > > Phil >

23 years, 1 month

[linux-audio-dev] go try 2.5 - it's not that bad...

by Joern Nettingsmeier

hi guys ! i have just built and booted into 2.5.41, and it turned out to be easier than i thought. everything works as before, and the kernel has now been running stable for over a day. i would encourage other audio users to give it a try as well, it's painless. using a current distro (suse80), i didn't even have to update userspace tools (at least nothing has bitten me yet). be sure to have a backup, of course. i have only scsi disks, so i can't say how the IDE stuff turned out, but i hear it is sane again. best, jörn benchmarks coming.... -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)

23 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev