Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7440 discussions

by David E. Storey

Hey there... I have an incredibly naive question... How does one mix n channels of audio down to one channel? I've scoured the 'net as best I could and haven't really found anything very authoritative. Suppose I'm dealing with float point data between -1.0 and 1.0 and have n channels. I know physically, it's all a summation of the individual waves, but strictly, summation of multiple waves between -1.0 and 1.0 doesn't keep you between -1.0 and 1.0. Looking through sox, they tend to multiply by some gain value relative to the number of channels. (namely... an average) So is averaging considered a valid professional audio method of digital mixing? what if your source samples are all 16bit? Wouldn't you need to dither in a case like that? Doesn't averaging also imply truncation of your source signal? Am I missing something here? I've tried looking to see what jack and ardour do, but was lefting wondering WHERE to look. respectfully, d!

21 years

[linux-audio-dev] M-Audio MobilePre/Sonica/Transit/Ozone testers wanted

by Clemens Ladisch

The M-Audio MobilePre/Sonica/Transit/Ozone devices need a firmware download before they can be used with Linux. I've released a first beta of the madfu-firmware package which tries to accomplish this. Please note that I do not have any of these devices, and that the loader is not tested at all. That's why I'm searching for volunteers. :-) To download the beta, go to http://sourceforge.net/project/showfiles.php?group_id=87777&release_id=1833… Please send any success/failure reports to usb-midi-fw-user(a)lists.sf.net Regards, Clemens

21 years

[linux-audio-dev] midi controls API, is it possible?

by antoine rivoire

Hi all, I am working towards using a set of linux audio apps in a live context. With recent development of Jack and apps such as djEQ and such, things look promising. In this light, an idea came to mind. (Keep in mind that I am thinking aloud, and that I am no expert in audio or midi programming). How feasible would it be to implement and a Midi controller API to have a standard, graphical ( a la qJackconnect) application API that Synths and such could use to change midi controllers assignment on the fly or load existing presets? I don't think that the audio framework that has been worked on in linux had live use in mind, but I am convinced that it lends itself to it. In the same context, and this might already be possible, is it possible to have a script calling different apps with patches/presets for each one of those? I am thinking along those lines: during performance: Call script -> opens say Zynaddsubfx with a certain master, Freqtweak with a certain session, Hydrogen with a certain song etc -> call end of piece from script which exits all these apps -> call another script for next piece. Regards Ant- -- antoine rivoire <antoine.rivoire(a)ntlworld.com>

21 years

Re: [linux-audio-dev] What's the best audio IO API on Linux

by hexe_2003＠directbox.com

-------- directBOX Reply --------------- From: harold_zhu(a)hotmail.com To : linux-audio-dev(a)music.columbia.edu Date: 15.09.2003 04:13:24 <p>Hi, Folks: <p>I am new here and I am also kind of new to Linux, so I have a basic question. I have worked on a multi-media project on Windows platform, and I used WaveIn and WaveOut functions as audio IO interface to capture and playback real-time audio. Now, I need to do a port to Linux.......so what's the best audio IO API on Linux? <p>In my search so far, I understand that both OSS and ALSA can do the job (real-time audio capture/play).......but what's the difference? Stability wise? Ease-of-use? Performance wise? Also any other candidate, in particular, cross-platform wrapper API? <p>Thanks Express yourself with MSN Messenger 6.0 -- download now! ---- Hi! Well, the main differences between the OSS-Layer and ALSA are: 1.) alsa is the new driver in linux kernel >= 2.6.X 2.) oss-layers need ioctl() - calls to manage/configure sound devices (and ioctl() calls are just possible for root-users !!!!!),so oss is really user-unfriendly if you want to programm a application 3.) alsa is easier to use for midi / pcm capturing/playback 4.) both are less documentated ( I can tell you that !!! :) ) , but alsa has a few basing programming tuts for C ( c++) 5.) alsa is basicly said a "wrapper", a front-end of the oss-arch and it is highly recommended to use alsa at all. I hope this helps, Sascha Retzki __________________________________________________ Verpassen Sie keine eBay-Auktion und bieten Sie bequem und schnell über das Telefon mit http://www.telefonbieten.de Ihre eMails auf dem Handy lesen - ohne Zeitverlust - 24h/Tag eMail, FAX, SMS, VoiceMail mit http://www.directbox.com

21 years

Re: Re: [linux-audio-dev] more practical stuff about synth-programming -- jack seems to be less documentated

by hexe_2003＠directbox.com

-------- directBOX Reply --------------- From: paul(a)linuxaudiosystems.com To : linux-audio-dev(a)music.columbia.edu Date: 18.09.2003 15:00:29 >It allows you to get a basic DSP algorithm producing sound without you >worrying about how to configure the audio interface, and then later >lets that same output be (potentially) routed to other applications >for processing/manipulation/recording. Well, this sounds very interesting; but where can I find developers documentation about jack ? Like I said, the Homepage is not interesting for that part of information need... . And has anybody some interesting c-algorythm documentation on how to produce convolution ? I mean: oscilating basing wave -> mix it together with a lfo -> filter it with delay, for example -> ... greetz, Sascha Retzki __________________________________________________ Verpassen Sie keine eBay-Auktion und bieten Sie bequem und schnell über das Telefon mit http://www.telefonbieten.de Ihre eMails auf dem Handy lesen - ohne Zeitverlust - 24h/Tag eMail, FAX, SMS, VoiceMail mit http://www.directbox.com

21 years

Re: [linux-audio-dev] lowlatency test at linuxdevices

by Benno Senoner

Paul Davis wrote: > I hope this is not true: > > "Embedded systems often need to poll hardware or do other tasks on a > fixed schedule. POSIX timers make it easy to arrange any task to get > scheduled periodically. The clock that the timer uses can be set to > tick at a rate a fine as one kilohertz, so that software engineers can > control the scheduling of tasks with precision." > The promise of the high-res timer patch was usec resolution, not msec. > This would be a great loss. Does anybody know any more? Yes unfortunately it is true what they say in the article. The current timer resolution is 1msec (HZ = 1024, so to be precise the resolution is (1/1024) sec). In short the story is as follows: Linus accepted the POSIX 1003.1b Section 14 (Clocks and Timers) API in kernel 2.6 but not yet it's implementation (patches available here http://high-res-timers.sourceforge.net/ ). This means that applications using the POSIX 1003.1b timer API can specify timing values nanosecond resolution but for now only msec resolution is provided. But when the Linus & co will let in the kernel the high-res timer implementation, those apps will instantly be able to achieve higher resolution without recompilation etc. Yes usec resolution would be handy for some audio apps but I for now I am happy of being able to achieve msec resolution in MIDI playback without resorting to the RTC device which cannot easily be shared. PS: in the article they talk about 4500usec worst case scheduling latency (= 4.5msec), seems a bit disappointing. I'm curious what they mean with worst case, which kind of test suites they used etc. 2.4 + some LL patches let you reliably work with sub 3msec BTW. Benno ------------------------------------------------- This mail sent through http://www.gardena.net

21 years

[linux-audio-dev] [ANN] Lemux version 0.2

by Joost Yervante Damad

Lemux is a collection of (GPL) LADSPA instruments based on devices from the openMSX emulator and other sources (e.g. sidplay2). Changes against 0.1: - all instruments are working, currently: - SCCChannel (e.g. from Konami games) (a 32 byte 8bit looped samples instrument) - PSGChannel (the standard sound chip from MSX) (a 1/2 square wave with noise and AM) - MUSICChannel (the FM OPLL chip from MSX-MUSIC) (a 2 operator FM chip, with 15 standard instruments and 1 custom FM instrument that is fully configurable) - MUSICDrum (FM OPLL Drums) (5 standard drum sounds from OPLL) - SID (The full C64 audio chip) - instrument volumes are now normalized More info (and audio samples) can be found at the website: http://lumatec.be/joost/lemux/ Greetings, Joost Damad

21 years

[linux-audio-dev] Streaming compressed audio from the network

by Juhana Sadeharju

Hello. If I understood correctly, several companies are wanting patent royalties for streaming compressed audio from the network. Take a look at mpg321 (GPL clone of mpg123): Usage: mpg123 [options] file(s) | URL(s) | - So, this playing from the network URLs is no no, or what? What other software are able to play a compressed audio from the network? Juhana

21 years

[linux-audio-dev] next power of two

by Maarten de Boer

Hi, A colleague of mine found this very clever algoritm to calculate the next power of two for a given number. It comes from the Prophecy SDK for 3d game development http://www.twilight3d.com/modules.php?op=modload&name=Downloads&file=index Since this is a kind of thing often needed in audio processing, I wanted to share it with you. I certainly can not think of a faster (or more elegant) way of doing it. Maarten ////// /// Returns the closest power-of-two number greater or equal /// to n for the given (unsigned) integer n. /// Will return 0 when n = 0 and 1 when n = 1. ////// inline uint32_t nextPowerOfTwo(uint32_t n) { --n; n |= n >> 16; n |= n >> 8; n |= n >> 4; n |= n >> 2; n |= n >> 1; ++n; return n; }

21 years

Re: [linux-audio-dev] next power of two

by Taybin Rutkin

Heh, that doesn't sound very RISC-like to me... Taybin -----Original Message----- From: Maarten de Boer <mdeboer(a)iua.upf.es> Sent: Sep 18, 2003 7:41 AM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] next power of two By the way, it seems the PPC has instructions to do it. >From the "PPC compiler writers guide": Round Up or Down to Next Power of 2 The floor power of 2 ( flp2) and ceiling power of 2 ( clp2) functions are similar to the floor and ceiling functions, respectively, but they round to an integral power of 2, rather than to an integer.

21 years

Jump to page:

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