Linux-audio-user December 2012

linux-audio-user@lists.linuxaudio.org

116 participants
113 discussions

A surprisingly stupid RT priority question

by Ken Restivo

OK, I know I've been using Linux audio for 6 years now, and gigged and recorded with it extensively for most of those, yadda yadda. But it seems I've had an embarassingly huge hole in my knowledge the whole time. I was under the impression that, in order to use real time priorities/permissions and Ingo kernels, it was required for the process ITSELF early in the main() routine of its source code, to make some system calls to claim RT priority. In fact, I specifically remember reading or even writing source code in C which did that (probably based on JACK sample code). I don't recall the name of the syscall, but it was something obvious and well-documented. Also, I remember that it was also required that the software behave properly in order to be real-time capable, something about callbacks taking some predictable amount of time. Or perhaps that was only a JACK requirement. Why am I asking these dumb-ass questions now? Because I've been playing around with Liquidsoap and Airtime for some radio stations, and I'm obsessed with getting them as rock-solid on cheap/free/old hardware as I'd been able to get with my gigging and studio synths. It physically pains me to hear audio stuttering because Apache is running on the same box. It seems an outrage to me. Shouldn't happen. Ever. I used to record and mix multi-track songs in Ardour with tons of soft-synths WHILE A KERNEL COMPILE WAS GOING ON THE SAME MACHINE without a single glitch. I expect no less. So I asked on the Liquidsoap list, and I got only shrugs and a pointer to the Gentoo page in response (why? I have no idea. I use Debian, and that's irrelevant to the question at hand anyway.). So what's the deal? Is there a way to give Ingo-approved preemptive RT priority to things that aren't real-time apps and aren't specifically architected for that? What, if anything, would break? And, if I wanted to hack Liquidsoap (which would require learning ML, which wouldn't be a bad thing to know anyway), is it even possible to get it RT-capable, or are there low-level C system calls required in order to make that work? Sorry for the long and obscure question, but it's been bothering me for a while, and I figured someone here would know the answer, or where I might find it. Thanks. -ken

12 years, 7 months

Re: [LAU] [ANN] Radium V1.9.14

by Kjetil Matheussen

David Baron: > Would love to give this a try but cannot build it. > > I make packages, then BUILDTYPE=RELEASE ./build_linux.sh -j7 > > This complains "packages not build," hangs a bit and then exits. Seems like making packages failed. Can you post the terminal output when running "make packages"? (for example to http://pastebin.com/) Also, do you have all dependencies installed? At least libXaw devel, and possibly libsndfile devel as well, are needed to build the packages.

12 years, 7 months

[ANN] Radium V1.9.14

by Kjetil Matheussen

Radium is a music editor with a new and better interface. It's inspired by trackers, but has fewer limitations and uses graphics to show musical data. Screenshot: =========== http://users.notam02.no/~kjetism/radium/pictures/radium-1-9-14.png Source code: ============ http://archive.notam02.no/arkiv/src/?C=M;O=D Homepage: ========= http://users.notam02.no/~kjetism/radium/ Source code repository: ======================= https://github.com/kmatheussen/radium Most important changes 1.9.6 -> 1.9.14: ======================================= * Waveform data is shown in the editor for the sampler instrument. * Colored areas replaced breakpoint curves for velocity representation. (looks much less confusing) * Only show gfx nodes for the track the mouse is currently placed over. * Various other graphical improvements * Fixed denormals on 32 bit Linux. (-mpmath=sse) * Fix various horrible bugs for those with non-C locale settings Thanks to "DoosC" for helping to debug. * Switch shift and right-alt keybindings for left/right arrow. Now: * Right Shift + left/right moves cursor to previous / next track * Right Alt + left/right changes velocity for note playing under cursor. * Need to press altgr or right shift less than 0.25 seconds to play. * Radium doesn't freeze when trying to play after it has been running for a few hours. * Dont create block undo too often. (Most notable when changing velocity using keyboard) * Don't reset temponode track size when zooming. * Fix pesky memory bug, sometimes causing the program to quit because it ran out of memory. Graphics should also be snappier in some situations after this fix. It was caused by the gfx queue growing and growing when QWidget::paintEvent wasnt called directly after drawing something. * Dont crash when pasting block in certain situations. * Remove reading of uninitialized memory in slider painter. * TAB switches between common window configs * Show message box if parsing soundfont file fails * Add -Wall option to RELEASE build * Make track headers of current instrument more distinct * Larger window during startup * Fix missing sound on AMD phenom processor. Thanks to DoosC for helping to debug. * Disable text border by default (except for line numbers), and ignore saved text border setting * Ignore minnodesize and use font height*2 instead. * Implement reset font size for qt * Demo song audio adjustments * Set default colors/fonts menu options * Qt: set DontUseNativeMenuBar on all systems, not just osx. Menues requires mono font to look right (fix for unity) * Dont stop playing when changeing patch for a track * Various graphical improvements * Use "---" instead of STP. * "make install" should work without first running the program. * Shift+left/right to change note volume works even if cursor is not placed on the same line as the note name. * Fixed zooming-in-a-lot bug. * Pan-per-note for the sampler instrument. Means that the track panner works for that track only. * Fixed samplefile font in sample file selector. * Different panning algorithm. (Dont just lower volume in one channel on stereo files) (Warning: may change sound of existing songs) * Remove -mtune=native for linux builds. * Linux: Use standard paths for lrdf files * Instructions on how to compile from git

12 years, 7 months

S/PDIFF on a delta1010(lt)

by Julien Claassen

Hello everyone1 I'm very new to the world of digital audio. but I wonder; I can see 12 capture ports in JACK, of which only 8 should be analogue inputs. So the rest must be digital? So here are my questions: Which items in the alsamixer correspond to their volume/routing? I'd like to route everything to PCM out. Is it possible to have all 8 analogue ins and the digital inputs work at the same time without having to hassle the card and ALSA? Sorry, I'm sure, that these are really questions of a simpleton, but I can't help it. :-) Kindly yours Julien ---------------------------------------- http://juliencoder.de/nama/music.html

12 years, 7 months

Re: [LAU] S/PDIFF on a delta1010(lt)

by Len Ovens

On Fri, December 7, 2012 3:35 pm, Len Ovens wrote: > On Fri, December 7, 2012 12:00 pm, Julien Claassen wrote: >> Hello everyone1 >> I'm very new to the world of digital audio. but I wonder; I can see >> 12 >> capture ports in JACK, of which only 8 should be analogue inputs. So the >> rest >> must be digital? So here are my questions: >> Which items in the alsamixer correspond to their volume/routing? I'd >> like to >> route everything to PCM out. Is it possible to have all 8 analogue ins >> and >> the >> digital inputs work at the same time without having to hassle the card >> and >> ALSA? >> Sorry, I'm sure, that these are really questions of a simpleton, but >> I >> can't >> help it. :-) > > I have a delta66 which also has 12 ins and 10 outs. The ice 1712 is the > same on both. > > i/o 1 - 8 are the ADC 1 - 8 and the PCM 1 - 8. > i/o 9 & 10 is the stereo s/pdif in and out > input 11 & 12 is the output of the internal digital mixer (AKA > Multi-mixer) which can be used as a no latency (almost) monitor mixer if > the user doesn't have an external unit. > > In my case i/o 5-8 don't do anything (though the outputs can still be used > by the internal mixer). Oops sorry, You said alsamixer which is 0 based, so everything is off by 1. That is, in ALSA ADC = jackcapture 1 and ADC 1 = jackcapture 2 etc. -- Len Ovens www.OvenWerks.net

12 years, 7 months

Rock album produced with Linux

by Tom Szilagyi

Hi all, I am pleased to announce the album Decline recently completed and released by my side-project rockband called Submareen. This is a real band playing real instruments (no synthesized sounds at all, everything recorded thru mics), mostly in the classic rock style. The whole album (9 tracks, 51 minutes) comprises original music written by the band. The album was recorded and produced using Linux, for the most part Ardour 2 with 'mixing in the box' done with LinuxDSP, IR and some TAP plugins. Recorded, edited and mixed within Ardour in 44.1k / 24bit. A separate "mastering session" with the 24-bit track mixes was setup with the LinuxDSP multi band compressor and TAP scaling limiter as mastering processors to produce the final audio, dithered to 16 bits via the Ardour exporting process. A cue file was made with gcdmaster and the master audio file was cut in tracks via shnsplit to obtain the final CD tracks. You can give it a complete (128kbps quality) listen at: http://music.submareen.net Some additional information regarding its production is available on the band's website at: http://submareen.net In case you have any questions regarding the recording, production, mixing or whatever, I'm happy to answer them. Comments are also welcome. Enjoy! Tom

12 years, 7 months

[Music made with linux] Modlys: Julen har bragt

by Atte

Hi Today is the first day of advent, and I've just released a new version of the Danish christmas carol "Julen har bragt" (B.S.Ingemann). Music and melody are new, while the lyrics are taken from the original carol. http://music.modlys.dk/track/julen-har-bragt https://dl.dropbox.com/u/4343030/julen_har_bragt.mp3 Enjoy! -- Atte http://atte.dk http://modlys.dk

12 years, 7 months

23 new dronings

by Louigi Verona

Hey fellas! I've been busy these past 3-4 weeks, got some new tunes for you, *droning170 * - *droning192*. Pretty diverse bunch again, from dreamy soundscapes to sinister and inferno ones. Several experiments included ;) http://www.louigiverona.ru/?page=projects&s=music&t=droning Enjoy! -- Louigi Verona http://www.louigiverona.ru/

12 years, 7 months

what about a meta distribution system?

by renato

Hi, I just had a [very fuzzy] idea that might be worth, or it might be not... I thought I'd just put it out here in the wild, maybe someone finds it insightful and makes something out of it. You're warned, it's quite a rambling... here it goes: what about creating some sort of self-contained linux-audio package manager, which is distro agnostic? I'm thinking of python (even perl if I'm right has a similar tool), where you have tools like pip to search, install and uninstall modules and you can easily create local installations on your system (virtualenvs) where you can tinker all you want without compromising system wide settings. Ideally with this system for audio you would have access to latest binaries of all audio apps and preconfigured environments... You could download the exact binary versions and configurations the professional and semi-professional on this list use and install them in a local directory, ready to use and make music, without spending time on configuration. Of course there are things that would not be easy (or possible at all) to fit in this scheme, like jackd, rt-kernel and audio card configuration... But on the other hand I'd love it if when I wanted to try out the latest apps I could just download a known working configuration and start making music right away, instead of spending days debugging compiling issues due to slightly mismatching library versions or whatever... The reason all this stems from is that I am only a computer-music hobbyist and dedicate a little portion of my time to it. It often happens I found out about a cool new app (din,giada, non-software, muse2...) and when I find some free time to try and make sounds with it, I never find binaries for it and I frequently can't compile it the first time, so I have to start the usual cycle: report bug to dev, wait for reply, supply more info, download patch, recompile and so on. I don't know if such a thing is technically possible... But don't the latest video games from the Humble Indie bundles use something similar? I.e. they usually supply a distro-agnostic installer which puts all the binary it needs in a self-contained directory, and then it runs more or less without interacting with the rest of the system... Ok I'm not sure it's exactly like this, but I think at least the critical libs which the game depends on are provided, to ensure compatibility throughout many different systems. Wouldn't such a thing, together with the possibility I was mentioning before of sharing such micro-distributions (maybe using something like PGP-signing to be sure you're downloading binaries only from trusted sources), be a great boon for linux audio users? cheers, renato

12 years, 7 months

IRQ and RT question

by Aaron Krister Johnson

Hi all, I posted this as a followup to an earlier thread, but I think the traffic buried it. I was eager and curious to hear other's knowledge and experience: I have an EEEPC 1000HE netbook (used to run Arch but I got tired of having to compile, or failing to compile, some extra pacakges) that runs Xubuntu, usually with XFCE of course, but sometimes with Fluxbox. Also have a bigger laptop, and HP pavilion7, running Mint with Maya Desktop (I also switch it to Fluxbox sometimes). Anyway, it seems the EEE has suboptimal IRQ hardware settings for RT low latency audio...doing less /proc/interrupts shows that there's a lot of sharing, like the audio and video card being on the same IRQ. Indeed, running Csound FLTK gui interfaces and moving them while processing the csound orchestra sometimes makes pops and crackle dropouts, while the same thing on the better IRQ set HP Pavilion shows flawless performance. Even if I run an outboard USB audio interface (Lexicon Lambda) on the EEE, there is still suboptimal USB Irq settings to contend with. I've always suspected IRQ settings, which are unfortunately hard-wired in laptops, to be profoundly influential in RT performance, but I wanted the audio guru programmers to comment. Thanks, AKJ -- Aaron Krister Johnson http://www.akjmusic.com http://www.untwelve.org

12 years, 7 months

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-user December 2012