Linux-audio-dev April 2010

linux-audio-dev@lists.linuxaudio.org

65 participants
45 discussions

Start a nNew thread

Kernel Opinions: .31-rt or .33-rt?

by Gabriel M. Beddingfield

Does anyone out there have an opinion on linux kernel 2.6.31-rt vs. 2.6.33-rt for audio? Thanks, Gabriel

13 years, 11 months

EURASIP JASP CfP

by Victor Lazzarini

Hi everyone, I think this CfP might interest some of the people on this list: http://www.hindawi.com/journals/asp/si/mart.html We welcome contributions from various related audio development areas, as you will be able to see from the call, there is a wide scope in it. all the best Victor

13 years, 11 months

JACK Graph Internal Latency? (was Re: A small article ...)

by michael noble

hi all, On Thu, Apr 29, 2010 at 7:05 AM, Tim E. Real <termtech(a)rogers.com> wrote: > > > Just a request: Would be awesome as a DSSI plugin so that we > don't have to use rakarrack in a 'send and return' loop within our apps, > which causes latency due to the round trip... > Tim. > > This raises a question that I've had for a while regarding latency in the JACK graph. I may have even asked it in the past, but if I did I either wasn't satisfied with the answer or have forgotten it completely. Either way, I'm unable to find it in the archives. My understanding is that connections between applications in the JACK graph should add absolutely no additional latency to the signal path. Latency is of course introduced at the A/D and D/A conversion stage of the graph, which is to be expected. This is the latency figure that jack reports - the latency introduced at every A/D or D/A stage. The only additional latency introduced is by processing internal to any applications, for example by the use of sample blocks as in the case of convolution. Am I correct in this? If so, then I don't understand Tim's statement above, as there should be no difference, in terms of latency, between using Rakarrack as a plugin (if it were possible) within an application, or placing it in an external send/return loop in the JACK graph. If my assumption is not correct, then I'm actually highly confused as to what the value of JACK is at all. If latency were introduced at every additional JACK signal routing, then even a simple routing like the following: A/D -> Rakarrack -> Jackrack -> Ardour -> D/A would have no less than four multiples of the internal JACK latency. This would quickly become unworkable in more complex JACK graphs (for example asymmetrical graphs would have signal chains running with different internal latencies). This would make having application interconnects a pointless exercise in frustration for the most part. And actually, from experience, this is not what seems to happen at all. Feel free to correct my admittedly limited technical understand of how latency is handled internally to the JACK graph... -michael

13 years, 11 months

Ladspa run lengths and control latency

by Tim E. Real

I wrote: >> Maybe I made a mistake there, confusing a plugin chain with analog >> latencies. Ah but then, isn't a plugin chain like a 'bucket brigade'? >> Each stage can't know what the previous stage does to the signal until >> that previous stage has processed a whole buffer. >> ("He said, waiting to be clobbered by the responses.") >Oops, yeah that happens, but all within one process cycle. >Each plugin in the chain is run in succession on the data, right? >My mistake. Must be tired, the ol' brain wanders... I have a question, sort of related to that latency discussion: Plugin 'run' length need not be related to audio buffer size, right? I'm thinking of breaking up my 'single-run-per-process' into multiple 'run-lengths-between-control-or-program-changes-or-midi-events', per process. I know dssi docs mention doing this in regards to program changes 'between notes', but don't specifically mention handling control changes or midi events that way, but it seems reasonable. So not only will I get more or less 'sample accurate' control and program changes and midi events, but processing each control's successive changes won't take so long from waiting for the next process cycle in order to set each change (I found when processing a string of dssi-vst osc control change notifications for one control, the vst expects *all* of the changes to be sent back to it via the ladspa control port, so the quicker the port value can be changed, the better, that's why I want to break up the runs). Is this a good method? I'm also asking because... If I carry this logic to an extreme, what might be wrong with using say 128 'single sample' runs, for an audio buffer size of 128? Can plugins handle 'single sample' (or even dynamically varying runs)? My proposed method implies this would actually happen, if control or program changes or midi events needed to occur very close together. Thanks. Tim.

13 years, 11 months

[ANN] Qsynth 0.3.5 - Spring Cleaning Pt.2

by Rui Nuno Capela

Hello, Ashes to ashes, dust to dust, funk to funky. Yawn. Cut the non-sense, there's no burial service nor Bowie's song here. Just blowing some aging stuff, maybe giving the patine that it deserves ;) Almost one long year has gone by and sadly enough, there's no big new and flashy features to show off. But, nevertheless, Qsynth 0.3.5 is out from the closet! Hope you enjoy the (not so big) news :) Have fun. Description: Qsynth is a FluidSynth GUI front-end application written in C++ around the Qt4 toolkit using Qt Designer. FluidSynth is an excellent command line software synthsizer based on the Soundfont specification. Website: http://qsynth.sourceforge.net Project page: http://sourceforge.net/projects/qsynth Downloads: - source tarball: http://downloads.sourceforge.net/qsynth/qsynth-0.3.5.tar.gz - source package (openSUSE 11.2): http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.src.rpm - binary packages (openSUSE 11.2): http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.i586.r… http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.x86_64… - binary packages (Ubuntu 9.10): http://downloads.sourceforge.net/qsynth/qsynth_0.3.5-2.rncbc.ubuntu910_i386… http://downloads.sourceforge.net/qsynth/qsynth_0.3.5-2.rncbc.ubuntu910_amd6… Change-log: - Initial widget geometry and visibility persistence logic has been slightly revised as much to avoid crash failures due to wrong main widget hidden state. - General source tree layout and build configuration change. - Most modal message dialog boxes (eg. critical errors) are now replaced by system tray icon bubble messages where available. - Reverb and Chorus parameter ranges have been revised to match and comply with fluidsynth back-end (libfluidsynth). - Fluidsynth channel info and unset program interfaces are now in use where available (libfluidsynth >= 1.1.1, EXPERIMENTAL). - Global configuration state is now explicitly saved/committed to disk when Options dialog changes are accepted and applied. - Output peak level meters get their long deserved gradient look. - Automatic crash-dump reports, debugger stack-traces (gdb), back-traces, whatever, are being introduced as a brand new configure option (--enable-stacktrace) and default enabled on debug build targets (--enable-debug). - Added Czech (cs) translation, contributed by Pavel Fric. - The channel preset selector (Channels/Edit...) has been seriously crippled for ages, only showing the presets of the last loaded soundfont, now fixed. - Minimum number of MIDI channels allowed on engine setup has been dropped from the old value 16 to as low as 1 (one), not that it makes a difference, as (lib)fluidsynth internals just rounds it to the nearest multiple of 16 anyway. - Cleanup to knobs source, simplified from redundant stuff. Weblog (upstream support, yours truly): http://www.rncbc.org License: Qsynth is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Cheers && Enjoy. -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

13 years, 12 months

Re: [LAD] [LAU] Hello World: linuxaudio.org on a new Machine

by Robin Gareus

Mark Knecht wrote: > On Thu, Apr 22, 2010 at 1:17 PM, Robin Gareus <robin(a)gareus.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi again, >> >> Since 6pm UTC today linuxaudio.org is hosted on a new server (actually a >> VM). >> >> Due to slowly failing hardware on the old machine were urged to perform >> the migration ahead of schedule and were unable to send out a >> notification about it beforehand. >> >> The hosting is (still) provided by by the Virginia Tech, Department of >> Music and Digital Interactive Sound & Intermedia Studio. Many thanks to >> Ico Bukvic. Daniel James takes care of DNS. and a big thanks to >> Marc-Olivier Barre who manages the email services. >> >> All systems go. >> robin root >> > > Aren't VM's cool?! They certainly are cooler that calling Ico on a Sunday morning and asking him to drive to campus and press the reset-button or sth. :) but actually optimizing a virtual machine's I/O for >1 TB/month traffic and sending ~1Million of [valid] emails per month is much harder than on bare metal. > The site works but not at the link above. That says under > construction. Adding the www in front brings the main page right up. > The links on the left work but none of the announcement links in the > middle of the page are working for me at this time. Thanks for reporting this. It's good to know there are people who keep an eye open. I hazard a guess that this occured because you did not flush your browsers' DNS cache and/or you were unlucky to just try that while I was tweaking some apache preferences. Anyway, there may still be a few minor glitches as we continue to tweak the system during the next days. - but don't hesitate to contact us should you experience some unexpected behaviour with the site. Cheers! robin

13 years, 12 months

Hello World: linuxaudio.org on a new Machine

by Robin Gareus

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, Since 6pm UTC today linuxaudio.org is hosted on a new server (actually a VM). Due to slowly failing hardware on the old machine were urged to perform the migration ahead of schedule and were unable to send out a notification about it beforehand. The hosting is (still) provided by by the Virginia Tech, Department of Music and Digital Interactive Sound & Intermedia Studio. Many thanks to Ico Bukvic. Daniel James takes care of DNS. and a big thanks to Marc-Olivier Barre who manages the email services. All systems go. robin root -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvQrr4ACgkQeVUk8U+VK0KmlQCfbNOpDl+xBSngTnxcd6ax/NDI M3UAn3VWgwVKp6O57XnMLCDuCwo+QRgB =lkZU -----END PGP SIGNATURE-----

14 years

We're back online !

by Marc-Olivier Barre

Dear mailing list users, The list migration to the brand new virtual is complete and all the problems seems to be fixed. As Robin told me when we were in the middle of this panicky evening: "when we find what the problem is, we will all laugh about it". Well, let me share the laughing with you: It was just a typo ! Funny how trouble in the computer world eventually always turn out to be an invisible typo in a configuration file :) Enjoy your new server and post away ! Cheers, -- Marc-Olivier Barre XMPP ID : marco(a)marcochapeau.org www.MarcOChapeau.org

14 years

linuxaudio.org email downtime.

by robin＠linuxaudio.org

Hi there, I'm sorry to inform you that our email services are currently disrupted. Due to increasing hardware problems with the linuxaudio.org server in previous weeks we're already prepared a new machine. Another major outage of linuxaudio.org this morning (UTC) forced us to switch to the new host a bit early... All services but for mailman (email-lists) are online and functional. We're working on resolving the problem and will inform you about our progress. robin & marc-olivier

14 years

[ANN] Drumstick libraries 0.3.1 released

by Pedro Lopez-Cabanillas

Drumstick is a C++ wrapper around the ALSA library sequencer interface using Qt4 objects, idioms and style. ALSA sequencer provides software support for MIDI technology on Linux. Complementary classes for SMF and WRK file processing are also included. It is used in KMetronome, KMidimon and KMid2, and was formerly known as "aseqmm". Since the release 0.3.0 there are two libs: drumstick-alsa and drumstick-file. Changes: * Allow to build drumstick-file library under Windows. * New method MidiClient::parseAddress() replacing the ALSA function snd_seq_parse_address() in MidiPort::subscribeTo() and similar methods. * Fixed MidiClient::getAvailableInputs() and getAvailableOutputs() forcing to always retrieve the updated clients list from ALSA. Copyright (C) 2009-2010, Pedro Lopez-Cabanillas License: GPL v2 or later Project web site http://sf.net/projects/drumstick Online documentation http://drumstick.sourceforge.net/docs/ Downloads http://sourceforge.net/projects/drumstick/files/0.3.1/ openSUSE Build Service - RPM packages http://software.opensuse.org/search?baseproject=ALL&p=1&q=drumstick Regards, Pedro

14 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev April 2010