Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

by Stefan Kost

hi, The buzztard team has release version 0.2 "sunrise" of its buzz-alike music composer. This version has lots of UI usability improvements, bug fixes, more instant apply settings and introduces some interactivity features (interaction controller and upnp playback controller). The gstreamer extension modules got two new interfaces for presets and help. A Fluidsynth generator plugin has been started. project-page: http://www.buzztard.org screenshots: http://www.buzztard.org/index.php/Screenshots downloads : http://sourceforge.net/project/showfiles.php?group_id=55124 buzztard core developer team -- http://www.buzztard.org

18 years, 4 months

Libraries for simple audio programming, libao, other options?

by Stephen Cameron

Hi, About a week ago, out of boredom, I started working on little retro-styled '80s kind of video game, written in a pretty simple-minded way with gnome, and the graphics done just by using line drawing primitives. It was just something to do, I didn't imagine it would amount to anything. Well, it's turning out surprisingly well (not great, but better than I was expecting.) So now I'm thinking to add sound, but apart from some MIDI programming, I really haven't done any audio programming before (unless you count some Extended BASIC code on a ti99/4a back in the '80s -- and nobody would count that.) So, I found libao ( http://xiph.org/ao/doc/ ) which looks nice and simple, and the sample program I tried ( http://xiph.org/ao/doc/ao_example.c ) worked right off the bat, and the idea of synthesizing my own sounds by constructing waveforms using sine waves is appealing for a retro styled app like mine (though I have no experience doing that and only a vague memory of trigonometry), but I wonder about how to mix sound (add the waveforms, I guess) and construct them on the fly (or trigger pre-computed chunks of audio). In the example code, it plays a one second chunk of audio with one library call initiating the playback. So, I imagine that for a game, in order to satisfy the real-time-ish requirements, I'd instead construct maybe 1/10th or 1/20th second chunks, which would be queued up in my program for playback, and whenever some event happens which demands some sound be produced _right now_ (like the user presses the "fire" button, and so needs some bleeping laser gun sounds to be produced) I would then start adding (arithmetic addition) laser-gun-waveform-data into whatever chunks were already in the queue, and so out would come the sound... Does that seem like a reasonable approach? By chopping the sound up into 1/10t or 1/20th second chunks, am I apt to cause distortion of some kind? Is there some other library I might be better off with? (I looked at SDL, but it seems heavily tilted towards graphics, and I already have the graphics stuff going alright under just regular old gnome.) I might also want to playback some ogg encoded files for maybe prerecorded sound effects and music to be mixed in with the synthesized sound effects. libao won't do that by itself, but I think there are some other libs on xiph.org that do that, but I'm not sure how well they'd accomodate mixing random bits of sound in with them. Saw this: http://www.underbit.com/products/mad/ fixed point mpeg decoder library... Not sure how easy it'd be to mix in other sounds with its output. Maybe just decode into memory buffer. Anyway, just looking for suggestions, esp. if what I've described so far seems wrong. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

18 years, 4 months

KeyboardMag

by Jens M Andreasen

Keyboard Magazine carries an article this month about Linux Audio: http://www.keyboardmag.com/story.asp?sectioncode=29&storycode=17973 -8<-------------------------------- You might think there’s no way a free operating system written by volunteers could compete when it comes to music production. But in the past couple of years, all the tools you need to make music have arrived on Linux. [...]

18 years, 4 months

discussing HZ (kernel timer frequency) and midi timing

by Mulyadi Santosa

hello everyone One thing that draws my attention is MIDI playing. So far, by using Timidity and ALSA, I tried to play several MIDI files and it is hard for me to notice any lag. I only noticed delayed notes when system is under busy load (I run CPU bound program with nice level above -9). Things I'd like to discuss are (I am sorry if they sound dumps because I still study all these stuffs): 1. Is it me just who is not professional enough to notice any difference when using various kernel HZ setting (smooth playing on HZ=x, not so smooth when HZ=y and so on)? Or, does the delay fall in non-human-perceptible range thus normal human being can not see the difference? 2. Is it correct that recent ALSA sequencer use RTC as source timer thus kernel HZ is no longer relevant in the sequencer's point of view? 3. Related to the system load I mentioned above, I think I was seeing scheduling latency and not really a timing latency. If that's correct, could you kindly suggest what I must do to show that MIDI timing does have any relation with HZ? 4. I am also thinking about MIDI recording as a way to show HZ effect. Since I don't have any MIDI devices (but I plan to buy one if it's really neccessary), I'd like to explore the correctness of this idea first. Do you think it is really a proper experiment in HZ test context? Thank you in advance for your help and attention and I am looking forward to read your feedback. Sorry if it has been discussed before, but I fail to completely research it until today. regards, Mulyadi

18 years, 4 months

PHASEX-0.10.1

by William Weston

PHASEX-0.10.1 is a buildfix and bugfix release, highly recommended for anyone who currently has 0.10.0. Here's the changelog: * Fixed delay buffer size crash bug. * Rebuilt config.h from configure.ac (fixes undefined PHASEX_DIR). * Added engine thread cancellation point. * Changed order of setting up JACK callbacks (might help jackdmp?) * Moved main sample rate init code from samplerate callback to jack thread. * Fixed oversampling mode. * Fixed typo on bank.c. * Disabled debug output in help.c. * Added --enable-debug= option to configure. * Fixed volume of bassy-plucked-lead and zeroed input boost on all patches. I'm still looking into issues with older versions of GTK-2.x. It looks like the current minimum GTK version is somewhere around 2.6 or 2.8. Most of the non-FC6 build issues appear to be related to this. Reports for SMP, non-FC6, and jackdmp systems would be very helpful, as these are the things I can't test right now. Thank you all for the valuable feedback! I'm already getting a good sense of what's needed most and where things should go in the project roadmap. Based on responses so far, the roadmap up to 0.20.0 should look something like this: 0.11.0 Bugfixes, buildfixes, code cleanups, GUI aesthetic issues. 0.12.0 Rework patch bank system to support alternate patch dirs and include a patch chooser. 0.13.0 LASH support. 0.14.0 Fine-tune threads (remove locks), optimize dsp code more. 0.15.0 New small features and simple GUI enhancements. 0.16.0 Implement LFO clock-sync for MIDI clock and JACK transport. 0.17.0 JACK MIDI support. 0.18.0 Multitimbral or multiple instance support. 0.19.0 Overhaul parameters to add generic ctlr-float conversions and add mod-matrix (w/ velocity and aftertouch handling). 0.20.0 OSC and DSSI support. Cheers, --ww -- /* William Weston <weston(a)sysex.net> */

18 years, 4 months

Re: [LAD] Re: [LAU] ANNOUNCE: PHASEX v0.10.0

by Nedko Arnaudov

William Weston <weston(a)lysdexia.org> writes: >> (gdb) bt >> #0 0xb7f39410 in __kernel_vsyscall () >> #1 0xb7e3acf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 >> #2 0x080518cc in engine_thread (arg=0x0) at engine.c:1125 >> #3 0xb7e383dd in start_thread (arg=0xb4df9bb0) at pthread_create.c:261 >> #4 0xb774bc8e in clone () from /lib/libc.so.6 >> (gdb) The program is running. Exit anyway? (y or n) y > > Hmmm... I can't seem to duplicate this one. Are you running SMP, by > chance? I've added a thread cancellation point in 0.10.1 to see if that > helps. Actually yes, a SMP system. I'll try on uniprocessor system too (hope this evening). >> Have you considered using widgets from PHAT? I beleive there is no >> difference between knobs you use and phatknobs. If there are >> improvements chances are they shoud got in PHAT version too. > > I've looked at PHAT, but decided to start off with the basic gtkknob code > that everyone's been passing around so I could hack on it for a while. I > have added one modification that's not in the PHAT version: middle click > centers a knob. I recently added middle click to PHAT fanslider because I needed "reset to default" too, so I'd be glad if we have this for phatknob too. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

18 years, 4 months

Re: [LAD] ANNOUNCE: PHASEX v0.10.0

by Lars Luthman

On Thu, 2007-05-03 at 19:52 -0700, William Weston wrote: > On Thu, 3 May 2007, Lars Luthman wrote: > > > Very nice sounds. Since you asked for feedback, here is some: > > > > * the whole program crashes for me when I pull down the File or Patch > > menus or try to close the window, with lots of Gtk error messages > > about invalid style objects. If I change line 241 in gtkknob.c from > > > > widget->style = gtk_style_attach(widget->parent->style, widget->window); > > > > to > > > > widget->style = gtk_style_attach(widget->style, widget->window); > > > > it doesn't crash any more. Other behaviour seems to be identical. > > Wow... thanks! This change will be put in 0.10.1. > BTW, what GTK version are you running? 2.8.20 on Debian Lenny. --ll

18 years, 4 months

Re: [LAD] Libraries for simple audio programming, libao, other options?

by Stephen Cameron

--- Stephen Sinclair <radarsat1(a)gmail.com> wrote: > > Anyway, just looking for suggestions, esp. if what > > I've described so far seems wrong. > > Hi! > If you're dead set on including audio in your program, and you are > writing in C++, No, just C, but thanks anyhow, I'll keep it in mind in case I ever convert over to C++. C is more fun for me though, and this is just for fun. [...] > > An even easier way (imho) is to use Chuck, which is an audio language > built for realtime audio. You can write all your audio routines in > it, and send messages to your Chuck program telling it when to fire > events, using an OSC library such as LibLo. It'll make your audio > programming that much easier, the only difficulty is that you have to > deal with controlling a separate process. Anyways, I recommend it. > > http://ccrma.stanford.edu/software/stk/ > http://chuck.cs.princeton.edu/ > http://liblo.sourceforge.net/ (for talking to chuck from C) That sounds interesting. I messed with chuck for an hour or two, maybe a year ago, just played with the examples that came with it. It struck me at the time as being one of those things that looks deceptively simple, but that, given enough effort, could be pushed pretty far out. > > I've personally been through the exercise of writing my own audio > engine from scratch, and finally I'm convinced that using something > like STK or Chuck makes things much easier and in the end more stable > as well, so I just thought I'd share that with you. Hmm. I might be one of those people that has to learn the hard way, just for my own satisfaction of knowing how things work. In any case, I have the (probably rather naive) beginnings of a 16 track mixer engine working based on one of the portaudio test programs which I hacked up here: http://www.geocities.com/smcameron/sound_trial.c The scaling is a bit odd, I noticed... divides the sums by the number of things summed, which, as that changes as sound clips enter and leave the mix, tends to make it sound like somebody is violently twisting the knobs on a compressor. Seems to use about 1% of the CPU, so that's cool. -- steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

18 years, 4 months

ANNOUNCE: PHASEX v0.10.0

by William Weston

Announcing the latest release of the Phase Harmonic Advanced Synthesis EXperiment (first release featuring a GUI), available for download (source tarball and FC6 RPMs) at: http://sysex.net/phasex/ PHASEX is an experimental softsynth for Linux/ALSA/JACK systems with a good mix of standard and experimental features. Here's a quick overview of what PHASEX offers: * GTK GUI: Every paramater is available through the GUI, with parameter names right-clickable for on-the-fly MIDI controller mapping and middle-clickable for parameter help. * 4 Osc / 4 LFO: Oscs and LFOs support multiple sources: MIDI key, tempo, envelopes, and inputs, all with selectable unipolar/bipolar scaling. Wavetable includes the basic wave shapes, both bandlimited and non-bandlimited. Per-osc and per-LFO transpose, pitchbend, and init phase. * Modulations: Full AM, FM, and PM (in this case, modulation of phase offset between left and right channels) routing with per-osc controls. Each osc can be modulated by any osc or LFO for AM, FM, of PM. Wave select modulation by LFO modulators is alsa available. * Filter: Modified Chamberlin filter with LP, HP, BP, BS, LP+BP, HP+BP, LP+HP, and BS+BP modes, distortion and retro (clean) types, keyfollow modes, ADSR envelope, and LFO cutoff modulation. * ADSR Envelope: Standard ADSR envelopes for amplifier and filter. * Chorus: Stereo crossover chorus with builtin phaser. * Delay: Stereo crossover delay with LFO modulation capability. * Key Modes: Mono smooth, mono retrigger, mono multikey (round-robin mapping of MIDI keys to individual oscs), and full poly modes are available. * Input Processing: Inputs may be routed to any combination of oscs and LFOs. Input boost allows weaker sources to be brought up to level of oscs. Envelope follower applies input envelope to output. * Sampling Modes: Supports undersampling and oversampling, giving control over the ever present quality vs. CPU tradeoff. Since this is the first public release of PHASEX with a GUI, feedback is highly encouraged. The project goal is to provide a synthesizer to experimental and professional musicians alike that is as easy and enjoyable to use as it is powerful. The next batch of new parameters and features will be a result of feedback from the community, so please, don't be shy. Cheers! --ww -- /* William Weston <weston(a)sysex.net> */

18 years, 4 months

[ANN] pyliblo 0.5

by Dominic Sacré

pyliblo is a Python wrapper for the liblo OSC library. It does not yet wrap all of liblo's functionality, but includes everything you need to send and receive almost any kind of OSC message, using a nice and simple Python API. OSC can hardly get any easier :) Also included are two scripts, send_osc and dump_osc, which are similar to the well known sendOSC/dumpOSC programs, but much simpler and less cumbersome to install. Get pyliblo 0.5 here: http://das.nasophon.de/pyliblo/ Cheers, Dominic

18 years, 4 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