Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

[linux-audio-dev] realtime-lsm in the kernel

by Lee Revell

Hey, Now that the final touches are being put on the 2.6 low latency patches, a massive migration of linux audio users to 2.6 is imminent. Since this means every single linux audio user will need the realtime-lsm module, I think we should push to get it in the kernel, the sooner the better. Why make every user go through the extra step of downloading and installing it? It's only a few hundred lines of code, and while I don't consider myself a kernel expert I can grok it easily. I can't imagine there would be much resistance, especially considering how much easier this would make life for every audio-oriented distro. This fits the new kernel development model very well, one of its stated goals is to get the features that vendors and users need and that they currently have to patch the kernel to get, into the mainstream kernel. Anyway if the author does not object, I would be willing to spearhead a drive to get this into the kernel. I am sure they will approve as soon as 100s linux audio users voice their approval... Lee

21 years, 3 months

Re: [linux-audio-dev] a question re: the MIDI spec

by Pedro Lopez-Cabanillas

On Friday 10 September 2004 Martijn Sipkema wrote: > The problem here is that class compliant devices suffer bad timing > because they use bulk transfers for MIDI data. The standard for > MIDI over FireWire is much better. I don't agree on the subject that USB bulk transfers cause bad MIDI timing. Of course, you can't use the same USB host controller at a time with a MIDI interface and some other device like a CD writer and expect both good MIDI timing and fast CD burning. If you can reserve a host controller exclusively for your USB MIDI device, you will get pretty good results, most of the time. There are four USB data flow types, Control transfers and: - Bulk transfers are used to request or send reliable data packets up to the full bus bandwidth. Devices like scanners or scsi adapters use this transfer type. - Interrupt transfers are similar to bulk transfers which are polled periodically. If an interrupt transfer was submitted the host controller driver will automatically repeat this request in a specified interval (1ms - 255ms). - Isochronous transfers send or receive data streams in realtime with guaranteed bus bandwidth but without any reliability. In general these transfer types are used for audio and video devices. (quoted from http://wwwbode.cs.tum.edu/Par/arch/usb/usbdoc/node8.html) MIDI streams need to be reliable (a single byte lost isn't acceptable), so Isochronous is not an option. Interrupt or Bulk transfers are very similar: they use only the available bandwidth at each moment, so there can be unwanted delays and timing problems. Some manufacturers' proprietary protocols include a timestamp with each USB MIDI packet to enhance the time accuracy, but this can be done either in bulk or interrupt transfers. Regards, Pedro

21 years, 3 months

[linux-audio-dev] [ANN] tuneit 0.2 -- ALSA and JACK instrument tuner

by Mario Lang

Hi. Here is it, the first public release of tuneit, a command line instrument tuner for ALSA and JACK. tuneit was written as a command line alternative to the two existing guitar tuner programs for GUIs (gtkguitune and qjacktuner). It offers two different fundamental frequency detection algorithms. The default (Schmitt Trigger) algorithm is very light on CPU usage. Alternatively there is also a FFT based algorithm which is much more CPU intensive but a little more acurate and/or stable. Thanks go out to Karsten Wiese and Florian Berger, the authors of qjacktuner and gtkguitune respectively, whoes work has served as inspiration for tuneit. "Screen shots": Tuning my guitar via ALSA hw:0 with the simple Schmitt Trigger algo: lexx:/# tuneit Note A ( 110.000Hz): -8 cents ( 109.506Hz) Or via JACK: lexx:/# tuneit -j Note A ( 110.000Hz): -5 cents ( 109.714Hz) Or with the FFT algo via JACK: lexx:/# tuneit -j -f Note A ( 110.000Hz): -7 cents ( 109.565Hz) Show the available JACK ports: lexx:/# tuneit -j -i alsa_pcm:capture_1 alsa_pcm:capture_2 Capture from right channel via JACK using a FFT window size of samplerate/5: lexx:/# tuneit -f -l 5 -j alsa_pcm:capture_2 Note A ( 110.000Hz): -5 cents ( 109.656Hz) Download: The canonical homepage for tuneit is http://delysid.org/tuneit.html Version 0.2 can be downloaded from http://delysid.org/tuneit-0.2.tar.gz Comments, as always, are very welcome. -- CYa, Mario

21 years, 3 months

Re: [linux-audio-dev] a question re: the MIDI spec

by Pedro Lopez-Cabanillas

On Friday 10 September 2004 Eric Dantan Rzewnicki wrote: > On Thu, Sep 09, 2004 at 07:18:57PM +0200, Pedro Lopez-Cabanillas wrote: > > And now Avid (the company owning Digidesign) bought M-Audio. [...] > Really!?! when did that happen? http://www.avid.com/company/releases/2004/040820_acquisition.html http://www.m-audio.com/index.php?do=media.new&ID=503e85ec37f1003524a4455fcf… http://www.m-audio.com/images/en/press_releases/Avid-M-Audio_PR.doc Regards, Pedro

21 years, 3 months

[linux-audio-dev] [ANN] qjackctl 0.2.11 released!

by Rui Nuno Capela

Hi, Just less than a week after some user complaints about that glossy-glass light effect featured on the front panel display, here comes a couple of fixes that were made into this rather minor dot release. Now's the perfect time for a recommended upgrade: qjackctl 0.2.11 is here, grab it from: http://qjackctl.sourceforge.net http://sourceforge.net/projects/qjackctl Simply as is, as taken from the changelog: * Fixed Input/Output channels settings, being now either enabled when the ALSA driver is selected for Capture/Playback only. * Shiny display effect: after some conservative user complaints this pure cosmetic feature is now made optional ;) Enjoy. -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

21 years, 3 months

[linux-audio-dev] Re: [Jackit-devel] Maybe I'm going at this wrong...?

by Eric Dantan Rzewnicki

Lee Revell wrote: > On Wed, 2004-09-08 at 17:38, Lee Revell wrote: >>If you want to try the new 2.6 low latency kernel, here is a QuickStart: >>Start with: >> http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2 >>Then apply these patches in this order: >> http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc1.bz2 >> http://redhat.com/~mingo/voluntary-preempt/patch-2.6.9-rc1-bk12.bz2 >> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk12… >>This will give you the irq threading settings in /proc that other posters referred to. >>Please keep in mind that this is not completely stable yet, I would not >>recommend it for production use, but it works very well for many >>people. You are likely to have better results on a regular 32 bit >>single processor (that means no hyperthreading) x86 desktop system, >>because this has been well tested. > Ugh, typo, the last patch should be 'R6' and not 'R9'. Well, actually there is an R9 out today ... I have it patched, compiled and installed. audiobox:~# uname -r 2.6.9-rc1-bk12-vp-r9 (had to lowercase the extraversion stuff to comply with debian policy when making .deb with make-kpkg) I've set all the /proc and /sys stuff I could find in the wiki (console output below). Still, I get xruns reported by my ecasound 8 analogueOsc thingy. Interestingly, though, they now only happen when I start the second ecasound process to record from the jack outputs of the first. I'll double check that with previous kernel versions when I get a chance, but I'm fairly sure this is new and an improvement. Subjectively, the sound of the analogueOscs is smoother and the zipper noise from controller movements seems much less, but still the first ecasound reports xruns when it exits. As I said earlier today, I'm not complaining. I'm just trying to help out by reporting. I'm eager and willing to help with debugging. Is there anything I may have missed? What other info should I provide? Thanks, Eric Rz. audiobox:~# cat /proc/sys/kernel/*_preemption 1 1 1 1 audiobox:~# grep . /proc/irq/*/*/threaded /proc/irq/1/i8042/threaded:1 /proc/irq/11/YMFPCI/threaded:1 /proc/irq/12/i8042/threaded:1 /proc/irq/14/ide0/threaded:1 /proc/irq/15/ide1/threaded:1 /proc/irq/4/eth0/threaded:1 /proc/irq/8/rtc/threaded:1 /proc/irq/9/ICE1712/threaded:1 audiobox:~# echo 0 > /proc/irq/9/ICE1712/threaded audiobox:~# echo 0 > /proc/irq/8/rtc/threaded audiobox:~# echo 0 > /proc/irq/11/YMFPCI/threaded audiobox:~# grep . /proc/irq/*/*/threaded /proc/irq/1/i8042/threaded:1 /proc/irq/11/YMFPCI/threaded:0 /proc/irq/12/i8042/threaded:1 /proc/irq/14/ide0/threaded:1 /proc/irq/15/ide1/threaded:1 /proc/irq/4/eth0/threaded:1 /proc/irq/8/rtc/threaded:0 /proc/irq/9/ICE1712/threaded:0 audiobox:~# grep . /sys/block/*/queue/max_sectors_kb /sys/block/hda/queue/max_sectors_kb:1024 /sys/block/hdc/queue/max_sectors_kb:1024 audiobox:~# echo 16 > /sys/block/hda/queue/max_sectors_kb audiobox:~# echo 16 > /sys/block/hdc/queue/max_sectors_kb audiobox:~# grep . /sys/block/*/queue/max_sectors_kb /sys/block/hda/queue/max_sectors_kb:16 /sys/block/hdc/queue/max_sectors_kb:16

21 years, 3 months

[linux-audio-dev] Re: a flex/bison question

by vanDongen/Gilcher

On Thursday 09 September 2004 16:01, > From: Dave Phillips <dlphilp(a)bright.net> > Greetings: > > I'm trying to debug a problem that occurs at the link stage in > compiling CVS sources for Denemo. Here's the moment in question: > Any suggestions for fixing ? > > Flex 2.5.4, bison 1.35, gcc 3.2.2. > Upgrade flex. 2.5.4 has known bugs for generating incorrect C++ code that gcc 3.2 and later have problems with. f.i. from the lilypond documentation <quote> WARNING: plain Flex 2.5.4(a) generates invalid C++ code. GCC 3.x chokes on this. If you wish to use GCC 3.x, make sure that your distribution supports g++ 3.x and flex. For workarounds, see lexer-gcc-3.1.sh in the source directory. </quote> So I guess you could look at the lilypond sources for workarounds as well. Alternatively get flex at http://lex.sourceforge.net/ There are however also bugs with the most recent version(2.5.31), so the linuxfromscratch folks recommend the patches from debian: you can get the patch from: http://www.linuxfromscratch.org/patches/lfs/cvs/unstable/flex-2.5.31-debian… Hope this helps Gerard -- electronic & acoustic musics-- http://www.xs4all.nl/~gml

21 years, 3 months

Re: [linux-audio-dev] a question re: the MIDI spec

by Pedro Lopez-Cabanillas

On Thursday 09 September 2004, Clemens Ladisch wrote: > M-Audio started following suit only after they hung their engineers > with a USB cable and bought Evolution who had always made > class-compliant devices. And now Avid (the company owning Digidesign) bought M-Audio. I hope to see the engineers that made the MBox hanging in the end of an USB cable. Regards, Pedro

21 years, 3 months

[linux-audio-dev] Re: OSC vs MIDI

by Andrew Burgess

>On Sat, 2004-09-04 at 06:55, Steve Harris wrote: >> On Fri, Sep 03, 2004 at 05:40:12 -0700, Andrew Burgess wrote: >> > >Service discovery just covers being able to locate liblo servers >> > >> > I wonder if it's possible to use portmap for service discovery? >> >> I dont know, but I think you shouldn't :) >> >Seconded. There is a good reason that portmap has been around for 20 >years or so and only NFS uses it. Please tell us what that reason is... Thanks in advance

21 years, 3 months

[linux-audio-dev] Announcing the Polypaudio sound server

by Lennart Poettering

Hi! I am pleased to announce version 0.4 of the Polypaudio sound server. See http://0pointer.de/lennart/projects/polypaudio/ for more information. I will try to push Polypaudio into both Gnome and KDE as replacement for esound resp. aRts. I am interested in your comments on Polypaudio. Please comment especially on the client APIs available on http://0pointer.de/lennart/projects/polypaudio/doxygen/ For a quick comparison with aRts/Esound see the FAQ: http://0pointer.de/lennart/projects/polypaudio/FAQ.html I am always interested in new devlopers: if you are interested feel free to contact me! polypaudio is not a sound server for professional audio, it is a sound server for desktop environments. Please keep that in mind when grumbling about this software. Thanks for your time, Lennart -- name { Lennart Poettering } loc { Hamburg - Germany } mail { mzft (at) 0pointer (dot) de } gpg { 1A015CC4 } www { http://0pointer.de/lennart/ } icq# { 11060553 }

21 years, 3 months

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