Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

by Louis Gorenfeld

For some reason, gmail has stopped delivering my LAD messages, so apologies if this reply isn't working correctly... I'm attempting to run, in general, a 128 sample buffer (frames per fragment). There is a lower latency mode though which is 64 samples. I have two fragments. Maybe if I want to do this I should be using three at least or make 128 the minimum. But I'm a little confused at the lack of ins and outs being linked. For a full duplex loop, I'd have to have the input before I can process output for example, so I don't see how that works unless I just ignore input requests from ALSA if I am not yet ready to receive. I'm defining "ready to receive input" as the time after I run my processing loop and then get a POLLOUT request. However, when I ignore POLLINs like this, it seems like ALSA immediately POLLINs again and I wind up with something like 50,000 polling requests handled in a second, which drives the CPU usage through the roof. >the in & out are not linked in any way as far as ALSA is concerned >(even though they may be at the h/w level). >a 64 sample buffer (not period) is very, very small. you need very >tight code and a well configured machine to operate like this. what >period size and/or number of periods are you attempting to use? >> Hey, I've been having a lot of trouble with ALSA and processing input >> in a full duplex loop, and I was wondering if anyone here had any >> insight. I'm using the ALSA poll file descriptor method with the mmap >> routines. Typically, my processing loop is blowing past the poll >> statement with input requests (POLLIN), causing the CPU usage to go >> off the charts as it's basically looping as fast as it can go. >> >> Now, I'm handling the inputs in a way that might not be correct. >> Often, ALSA is saying that the available frames is 1.5 times my buffer >> size (e.g., I set a 64 sample buffer and ALSA offers me 96 samples). >> I only get (begin/commit) input when the buffer size matches or >> exceeds the buffer length I send out to the card (the set buffer >> size), and if it exceeds that, I only pick up (commit) one buffer's >> length of frames. Is this wrong? If there is more input waiting, >> does ALSA immediately go and POLLIN again, or should I expect it to >> not bug me again until I've processed a POLLOUT event (the in and out >> are linked)? I'm not really sure how to handle this..

14 years, 7 months

[ANN] csound 5.13 release

by Victor Lazzarini

Basically a bug fixing release but with a number of new opcodes etc http://souceforge.net/projects/csound ==John ffitch Notes for 5.13 ============== New Opcodes: farey sequence opcodes median opcode filevalid opcode Real random number generators using /dev/random (Linux only) pvstanal opcode -- phase vocoder analysis by reading function tables mincer opcode -- Phase-locked vocoder processing temposcal opcode -- Phase-locked vocoder processing with onset detection/processing pvswarp opcode -- Warp the spectral envelope of a PVS signal pvslock opcode -- Frequency lock an input fsig New Gen and Macros: INF macro added to orchestras; z read as infinity in scores GEN for support of farey sequences Modified Opcodes and Gens: init changed to allow multiple inits in on statement maxalloc, cpuperc, instcount now accept named instruments If normalisation in pow opcodes is zero treat as 1 inch can take upto 20 inputs and outputs pvscale and pvsmix now have very good spectral envelope preservation modes (1 = filtered cepstrum, 2 = true envelope). oscil1 could be static if the duration was long; now there is a positive minimum increment. GEN49 now uses search paths pvsvoc enhanced with new spectral envelope preservation code. Bugs fixed: Count of lines fixed in orchestras, and \ inside strings Fast tab opcodes made safe from crashes % in formated printing could crash Double free in fgen fixed sndwarp quietened (gave too many messages) gen41 deals with positive probabilities adsynt reworked removing many bugs adsynt2 phase error fixed atonex/tonex did wrong operation Bug in max number of gens fixed mp3in could repeat sound at end of file Better checking in grain4 modulus was wrong in new parser Better checking in adsyn changed opcode initialised to zero Serious bug in tabmorphia fixed GEN49 has serious bug removed, so no longer incorrect silences. Partikkel opcode: fixed bug in sub-sample grain placement when using grain rate FM nchnls_i working correctly System Changes: In the new parser only there are operator @ and @@ to round up the next integer to a power of 2 or powerof2+1 Score sorting made much faster lineto improved Named gens allowed Various printing include instrument name if available Command option to omit loading a library Number of out channels no longer constrained to be number of in Many fixes to new parser More use of Warnings than Messages (allows for them to be switched off) API: csoundSetMessageCallback reset if callback set to null Internal: usual collection of gratuitous minor changes, layout and comments

14 years, 7 months

ALSA POLLIN event problems

by Louis Gorenfeld

Hey, I've been having a lot of trouble with ALSA and processing input in a full duplex loop, and I was wondering if anyone here had any insight. I'm using the ALSA poll file descriptor method with the mmap routines. Typically, my processing loop is blowing past the poll statement with input requests (POLLIN), causing the CPU usage to go off the charts as it's basically looping as fast as it can go. Now, I'm handling the inputs in a way that might not be correct. Often, ALSA is saying that the available frames is 1.5 times my buffer size (e.g., I set a 64 sample buffer and ALSA offers me 96 samples). I only get (begin/commit) input when the buffer size matches or exceeds the buffer length I send out to the card (the set buffer size), and if it exceeds that, I only pick up (commit) one buffer's length of frames. Is this wrong? If there is more input waiting, does ALSA immediately go and POLLIN again, or should I expect it to not bug me again until I've processed a POLLOUT event (the in and out are linked)? I'm not really sure how to handle this.. Cheers, Louis

14 years, 7 months

plugins update

by Dave Phillips

Greetings, I've kept the Audio Plugins page alive at linux-sound.org. It aims to be a complete list of Linux audio/MIDI plugins, and I've updated it again recently. Please advise if there are any bad links or other errors. Also, please advise if there are other plugins that should be on the list. I *think* I know where to find them all, but you never know who has an unknown project going on somewhere. http://linux-sound.org/plugins.html Best, dp

14 years, 7 months

[OT] 3ghz coax and soldering...

by Jörn Nettingsmeier

hi everybody! forgive the ot post, but i hope there are some brains to pick here. i'm planning a studio, and to make it future-proof, there is coax in every room. currently it's going to be used for rgbhv and composite video, but i want it to be future-proof for MADI and HD-SDI. the cabling itself is of sufficient quality, but i'm doubtful about the connectors. the whole installation has a star topology, so the worst case is * source * 5m or so of suitable cable * bnc wall socket * 20m installation cable (-63dB/100m @ 3ghz) * a ghielmetti patchbay (which includes two canare contacts to the patch cord and two bnc on the rear, unfortunately) * another 20m installation cable * bnc wall socket * another 5m cable * sink question 1: any hopes for reliable hd-sdi? question 2: how can it be that a kick-ass company like ghielmetti does not offer video patchbays that allow direct connection of coax installation cables, but require rear bnc connections instead? question 2b: is there an alternative for direct rear coax connection, thereby cutting out two potentially disruptive contact surfaces? question 3: i'm thinking of getting neutrik isolated bnc connectors (the d-type ones that are semi-recessed and thus well protected from clumsy passers-by). but their soldering lugs break the coaxial structure - cause for concern? question 4: do i really want to solder hf stuff (even though the voltages are not too high), or will it unsolder itself eventually? any recommendations as to procedures and tin? thanks in advance, jörn

14 years, 8 months

Re: [LAD] tapiir website/source

by Philipp

Excerpts from Philipp's message of 2010-03-06 18:30:58 +0100: > I noticed a while ago that the tapiir website is gone or at least > non-functional. Do you guys know more about it? > > http://www.iua.upf.es/~mdeboer/tapiir/ links to: > http://www.iua.upf.es/~mdeboer/projects/tapiir/ links to: > http://www.resorama.com/maarten/projects/tapiir which returns 404 > > I do have a tarball however, version 0.7.2 and still compiling with > recent gcc versions: > http://aur.archlinux.org/packages/tapiir/tapiir/tapiir-0.7.2.tar.gz > > If there is a new website or a newer tarball, please let me know. > > Regards, > Philipp Hi, it seems the source is still not up or gone again. Any advice? I still have db3059abc56a59e9beaed4a8ea693e6b tapiir-0.7.2.tar.gz and could host it somewhere if that helps anything.. Regards, Philipp

14 years, 8 months

[ANN] Qtractor 0.4.8 - The Fiery Demigoddess released!

by Rui Nuno Capela

howdy so i lied, bluffed all the way, so what? should I be sorry? what you'd expect from this one self-called ber-procrastinator ? and then there's hope. alas, not the messiah, rather my development drive at my own pace. believe it or not, it is on-going and it will sure happen real soon ;) no sweat. The whole automation prophecy will be realized and delivered. yes, TYOQA just failed, slipped a bit. it doesn't mean it was abandoned though or, uh, procrastinated... well, it's only a happy new year after all:) the road to automation is being already being paved and walked although, i must say, it is no yellow-bricked one. the drive has begun. definitely, 2011 will be TYOQA (aha, read that again with a bold tee:)! more than automation, which infrastructure is already lurking in there, trus me, all work is being carried out at the backyard for the time being. blossoms might just pop out this spring ;) one thing i may wish to leave sound and clear: it is very likely that, in the very near future, that there will be some dot-release before the all-mighty-one release, whatever. now that the surprise-effect is gone, the long overdue and hailed beta release cycle that will present you and carve its deeds on stone with the dynamic-curves and automation features et al., will be nothing less nor before the coming version numbered as the 0.5.x scheme. then, and only then, the current alpha-cycle will be concluded. of course, that will be also the time for translations to be called in. just be a little more patient :) and then i lied a second time, when said those parodied f&d release code-names were exhausted. thanks to a lengthy but intermittent fall/winter-of-coding period, i had the chance to wake up one morning with the imagination score in its lowest end and roar an inner WTH! as they say around here, there's no second without a third. so another lie is there waiting to be told. or is it not? there, one would say: time will tell... Release highlights: * Archive/Zip session file bundle (save as... .qtz) (NEW) * Mixer MIDI controller mapping/learn (NEW) * LV2 GTK UI support (NEW) * LV2 Persist extension support (NEW) * MIDI Tools on main track/clips view(NEW) * Floating tool-tips while dragging/moving/pasting (NEW) * Rescale and Timeshift MIDI tools (NEW) * MIDI Quantize percentage (NEW) * Track range selection (NEW) * Audio insert send, wet/dry controls (NEW) * Audio clip pitch-shifting (FIX) * Metronome dedicated outputs related crash (FIX) * Stop transport tool/button action (NEW) * Mouse-wheel zooming (NEW) and a few more assorted features and fixes--see below the complete (boring) change-log for gruesome details. Nuff said. Qtractor 0.4.8 (fiery demigoddess) released! Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.4.8.tar.gz - source package (openSUSE 11.3): http://downloads.sourceforge.net/qtractor/qtractor-0.4.8-2.rncbc.suse113.sr… - binary packages (openSUSE 11.3): http://downloads.sourceforge.net/qtractor/qtractor-0.4.8-2.rncbc.suse113.i5… http://downloads.sourceforge.net/qtractor/qtractor-0.4.8-2.rncbc.suse113.x8… - user manual (archeologically dated): http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf Weblog (upstream support): http://www.rncbc.org License: Qtractor is free, openosource software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - MIDI controller mapping/learn is now possible on all mixer controls (monitor, gain, panning, record, mute, solo). - An internal rewrite (aka. refactoring) have been carried out, making sure that all track state action buttons (R, M, S) are now all under the observer pattern umbrella. - Single track range selection is now available on main menu (Edit/Select/Track Range; default keyboard shortcut: Ctrl+Shift+R); additionally to vertical range and horizontal track actions (Edit/Select/Range, Track) all these operations can now toggle over the previous selection. - Direct clip selection from Files list item has been brute-forcefully implemented (after being challenged by Jiri Prochaszka aka Anchakor:). - Files tree widget sticky "New Group" item fixed. - A new menu option has been added (View/Tool Tips) to show/hide a floating tool-tip while dragging, moving, resizing or pasting selected clips or events over the main tracks view and MIDI clip editor (piano-roll) respectively, displaying current target position and status. - Attempt to reset audio/MIDI time drift compensator on every engine start and loop turnaround. - Moving the punch-out marker over the main track time ruler was failing to shrink the punch-in/out range, now it does (not). - MIDI clip tools (quantize, transpose, normalize, randomize, resize, rescale and the new timeshift) are now all accessible from the main tracks view (Edit/Clip/Tools menu) and apply to all events on current selected clip(s). - LV2 Persist extension support is being introduced. - A new timeshift MIDI tool has been added, after an awesome patch by Jiri Prochaszka aka Anchakor; applies to selected events between edit markers, distorting their time and duration (optionally), either slowing down and accelerating, based on a given parameter P value. - Audio clip/buffer pitch-shifting fixes with regard to latency correction due on the RubberBand library one-pass (real-time) processing mode. - New Send Gain and Dry/Wet control parameters have been implemented for audio Inserts pseudo-plugins. - MIDI channel/master volume enqueued events are now affected by the current track/bus volume (0-100%). - Prevent old rounding error when resetting to plugin parameter default value with the mouse middle-button click while hovering a slider widget (observer). - A quantize percentage has been added to MIDI clip editor quantize tool (Tool/Quantize...) for time and duration quantization (0% for none; 100% for full regular quantization). - Metronome bus/ports are now created at engine start and not when user switches it on anymore. - Make sure all audio clip buffers are in sync upon smooth-ramping going off and playback is rolling. - Copy-pasting across controller event types is now possible on the MIDI clip editor (aka piano-roll). - Finally indulged, the genuine transport stop button makes its appearance on main toolbar and menu. - Main tracks grid visibility option (View/Snap/Grid). - Yet another off-by-one (frame) audio buffer bug got squashed away: rare symptom was that some audio clips were being left dead silent right after playback of their first looping period. - Plugin parameter name/label now a proper attribute of its respective MIDI Controller observer instance, allowing to be shown on dialog title (MIDI learn). - Default session file format saved on JACK session demand is now the bundle archive/zip one (.qtz). - Plugin selection dialog now shows whether a plugin features its own editor (GUI) and/or external state configuration (EXT). - Help/Shortcuts... window positioning and sizing are now preserved. - All plugin chain changes over the track properties dialog now sure counts as a dirty action (possibly fixing bug #3104129). - Newly extracted archive/zip session directories are now removed automatically from the file-system on session close, prompting the user for confirmation (cf. View/Options.../Display/Confirm Removals). - Ctrl+mouse-wheel is now set for zooming in/out, on main track-view and all applicable MIDI clip editor views (piano-roll), according to current zoom mode (see View/Zoom Horizontal, Vertical or All for both ways simultaneously). - New MIDI clip editor (piano-roll) mouse hovering effect (eye-candy++). - After too many a user request, a brand new session archive file type is being introduced (.qtz) which tries to bundle in one single zip archive all the media and contents of a session. - Add that to eye-candy: either loop or punch-in/out outer ranges are now shaded on the main track-view, thumb-view and MIDI clip editor (piano-roll) views. - LV2 GTK UI plug-in hosting is now roaring its ugly head (EXPERIMENTAL). - Ignore all initial and decremental notifications of audio engine's buffer-size changes. - Internal audio buffer loop points were not being set properly for non-zero clip offsets, leaving some as severely out-of-sync while rolling over loop turns. Now fixed again, hopefully. - Avoid audio peak file clashing when deriving from audio sample files with distinct absolute paths but the very same file (base)name. - A new MIDI editor (piano-roll) tool has been added: Rescale event times, durations and/or values by a percentage between 1 and 1000% (adapted thanks to patch #3081954, by Jesse Lucas). - Attempt to mitigate audio clip sequencing glitches on single-core/single-thread machines. cheers && enjoy (be happy!) -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

14 years, 8 months

[Somewhat OT] Running QSC Venue Manager on wine ?

by fons＠kokkinizita.net

Hello all, Anyone managed to run QSC's Venue Manager software on wine ? <http://www.qscaudio.com/products/software/qscontrolnet/> Tried it yesterday - running the installer displays a message that it is checking for 'required Microsoft components' and that this could take 5 to 10 minutes. But it was still checking an hour later... But I'm a wine noob, so maybe I'm just missing the obvious... Ciao, -- FA There are three of them, and Alleline.

14 years, 8 months

New mailing list for Android Audio Developers

by Olivier Guilyardi

Hi everyone! I am glad to announce the creation of the andraudio mailing list, dedicated to audio development on Android, at: andraudio(a)music.columbia.edu More info and subscribing: http://music.columbia.edu/mailman/listinfo/andraudio This list is meant to be a place to discuss about audio development, in the context of music and sound applications, but also games and other apps which use audio on Android. Discussions and questions about both Java and native APIs are welcome. In addition to application-level topics, we are interested in discussing about Android audio system internals, for educational purposes, as well as finding new ways to work with sound on Android. So please come and join us if audio development on Android interests you. -- Olivier

14 years, 8 months

[LAA] [ANN] guitarix released gx_head

by hermann

I'm happy to announce the first public release of gx_head. gx_head is a simple guitar mono tube amplifier simulation based on the work we have done in the guitarix project. gx_head provide 3 tube models (12AX7, 12AU7, 6V6) and 8 different tonestack models(Bassman, Twin Reverb, Princeton, JCM-800, JCM-2000, M-Lead, M2199, AC30), so you can simply create the amp-model to your needs. gx_head comes with a bunch of in-build effects, like distortion, crybaby, autowah, phaser, flanger, echo, delay, . . . The effects could ordered in two Racks, on for the mono effects, witch could be load for pre or post processing, and one for the stereo effects, witch could only used in post processing. Effects are loadable over the menu, a pop-up menu in the racks, or a plugin bar. Settings could saved/load as presets. gx_head comes with some factory settings provided by guitarix/gx_head friend "funkmuscle", thanks therefore. All UI controllers could connected with jack midi via MIDI learn with your external MIDI controllers. gx_head is ready for language support via gettext() and comes thanks to Pablo Fernández with a Spanish translation. The style file gx2 is contributed by zettberlin, thanks Hartmut some features in short: * 8 tonestack models * 3 tube models * cabinet impulse response module * bass boster * easy Impulse Response file support via zita-convolver * on the fly IR-file resampling via zita-resampler * Oscilloscope and tuner * multi band distortion model * scalable EQ * phaser, flanger, stereo delay, stereo echo, * overdrive, compressor, freeverb, reverb, * chorus, moog filter, low/high pass filter, . . * MIDI learn * Patch Info widget * Preset File Load/Export option * factory settings * language support * shining User Interface via GTK/gtkmm * . . . . have fun _________________________________________________________________________ gx_head is licensed under the GPL. screenshots: http://sourceforge.net/apps/wordpress/guitarix/ direct download: http://sourceforge.net/projects/guitarix/files/gx_head/gx_head-0.12.0.tar.b… download: http://sourceforge.net/projects/guitarix/ please report bugs and suggestions in our forum here: http://sourceforge.net/apps/phpbb/guitarix/ ________________________________________________________________________ For extra Impulse Responses, gx_head uses the zita-convolver library, and, for resampling we use zita-resampler, both written by Fons Adriaensen. http://www.kokkinizita.net/linuxaudio/index.html We use the marvellous faust compiler to build the amp and effects and will say thanks to : Julius Smith http://ccrma.stanford.edu/realsimple/faust/ : Albert Graef http://q-lang.sourceforge.net/examples.html#Faust : Yann Orlary http://faust.grame.fr/ ________________________________________________________________________ For faust users : All used Faust dsp files are included in /gx_head/src/faust, the resulting .cc files are in /gx_head/src/faust-cc The tools we use to convert (post-processing and plot) the resulting faust cpp files to the needed include format, stay in the /gx_head/tools directory. ________________________________________________________________________ regards guitarix development team

14 years, 8 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