Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

by Lee Revell

Linked from this article: http://linux.slashdot.org/article.pl?sid=05/11/20/2255217 I found this paper from MontaVista. In addition to being a good high level overview of how modern Linux kernels achieve low latency they give special credit to the Linux audio developer community and Paul Davis's open letter to the kernel developers for driving the evolution of Linux 2.6 into a viable soft RT platform. http://linuxdevices.com/articles/AT9697872711.html Lee

19 years, 7 months

[linux-audio-dev] SMDITools and ESI4000

by Dan Richert

hello. I've been trying to get SMDITools working between linux and an E-Mu ESI4000. My sampler is being detected although on the wrong ID (the sampler is set to 4 and it's being detected at 0 ). Whenver I try to receive from or send to the sampler, I'm getting this: *** Error : Out of range *** as the README suggests, i made a symbolic link to /dev/sga from /dev/scsi/host0/bus0/target4/lun4/generic (i've also got sg0 - sg8 in /dev ... could it be looking at those first? ) the only scsi devices i have on the system is the esi4000 and an iomega zip drive between the computer and sampler. iomega drive is set to id 5 (scsi interface is at 7). also, does anybody know of any linux programs that work with the esi4000 file system? it would be great to be able to generate programs/banks. thanks. -d

19 years, 7 months

[linux-audio-dev] Channels and best practice

by Hans Fugal

I'm writing a library in ruby for dealing with audio data, and I'm faced with a design decision. For several reasons, the best thing to use in ruby for numerical data is NArray[1] which is implemented in C for efficiency. So my code is basically a wrapper around NArray which gives some more specific functionality. I want to support multichannel data, and this is where the design decision comes. Most of the time I've seen code that handles multichannel information in an interleaved fashion (each frame is consecutive samples in the array), but I have once or twice seen channels placed end-to-end or in different arrays altogether. It will of course be possible to extract and/or merge channels to deal with libraries (e.g. libsndfile, which I will also be wrapping) or existing code that works one way or the other, but I wonder which should be the internal format to use. What are your thoughts? What is best practice on multichannel audio, or is it always application-specific? For a fluctuating peek (think CVS, although I use darcs) into what I'm doing, check out http://hans.fugal.net/src/ruby-audio 1. http://www.ir.isas.ac.jp/~masa/ruby/index-e.html -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach

19 years, 7 months

[linux-audio-dev] [ANN] QjackCtl 0.2.19 released!

by Rui Nuno Capela

Hi, QjackCtl 0.2.19 has been released. The Qt(cutie)-based GUI control panel for the JACK Audio Connection Kit service has come of age. You can grab it right away from the "official" home site: http://qjackctl.sourceforge.net Release notes as taken straight from the change-log: - Connections widget views are now properly refreshed after renaming client/ports (aliases). - Disabled system tray and ALSA sequencer support on configure time, whenever building for MacOSX as default. - Fixed the major issues with selecting an audio interface on Mac OSX; the button the right of the interface combo is now much better looking than it was before; input/output channel counts are also updated automatically now (thanks to Jesse Chappell for the patch). - Prevent the setting of the coreaudio device id on the jackd command line (-n) whenever the default interface is being selected. - The connections and patchbay windows are now allowed to have a wider connection lines frame panel; splitter width sizes are now persistent across application sessions (thanks to Filipe Tomás for the hint). - Activation toggling feedback on the patchbay widget has been fixed; additionally and as found convenient, the most recently used patchbay definitions can now be loaded immediately by selecting from a drop-down list widget, which replaces the old static patchbay name status text, and adds a lil'icon too :) - All widget captions changed to include proper application title prefix. - Attempt to bring those aging autoconf templates to date; sample SPEC file for RPM build is now being included and generated at configure time. - The current selected device is now shown with a checkmark on the device selection menu(s), while on the settings dialog. - Set to use QApplication::setMainWidget() instead of registering the traditional lastWindowClosed() signal to quit() slot, just to let the -geometry command line argument have some effect on X11. Enjoy, -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

19 years, 7 months

[linux-audio-dev] LADSPA, GUIs, OSC and LADSPA_HINT_SAMPLE_RATE

by Luis Garrido

Hi! I am working on a GUI designing tool for LADSPA/DSSI around Qt designer. The idea is to extend the DSSI gui concept to LADSPA (OSC control included) and provide a skinnable tool to manually design GUIs. I plan also to include some user interaction enhancements. You can see some fancy concept diagram here http://flam.sourceforge.net/ There is some code behind it, too, but at the moment its structure is fluctuating and no effort of autotoolization/sconification has been done. There is a working skinnable slider and flamwizard is half finished. The skinnability will by provided by means of QStyle plugins. You can have very minimalistic depictions of the UI gadgets or hardware panel simulations. The GUI viewer, called flammer, will allow for loading/saving presets and load alternate GUI layouts for a given plugin at runtime. Now I have a doubt about LADSPA_HINT_SAMPLE_RATE. To effectively incorporate this hinting in the GUI, the host must have some means of letting know the GUI what the current sample rate is. Is there any standard procedure for achieving this? Comments, ideas, please? Cheers, Luis

19 years, 7 months

[linux-audio-dev] alsa help

by Aaron

Hi all, Denemo is really lacking alsa support. Unfortunatly Denemo has only one coder who is working a full time job. Is there a kind soul out there who could help implement ALSA support for Denemo. And if you live nearby I would gladly buy you a beer of your choice :) thats if you drink beer... Thanks Aaron

19 years, 7 months

[linux-audio-dev] the Linux-Powered Korg OASYS

by Jan Weil

<http://digitalmedia.oreilly.com/2005/11/09/inside-the-korg-oasys.html> Cheers Jan

19 years, 7 months

[linux-audio-dev] LDAS (Low Delay Audio Streamer) 0.1.0

by asbjs＠stud.ntnu.no

LDAS (Low Delay Audio Streamer) is software for full-duplex low-latency transmission of audio over IP. This is the first public release. At this point, the basic functionality is present -- LDAS is capable of transmitting full duplex two-channel audio between two computers. This has been tested using the ldas_mate binary running on two computers equipped with SoundBlaster Live sound cards. (Note however that the software is still in an early state. Features are lacking, and the code is somewhat fragile.) * Download: http://www.q2s.ntnu.no/~asbjs/ldas/ldas-0.1.0.tar * Web page: http://www.q2s.ntnu.no/~asbjs/ldas/ldas.html * Mailing list: https://pat.q2s.ntnu.no/mailman/listinfo/ldas-dev * Q2S web page: http://www.q2s.ntnu.no/ LDAS is released under the GNU GPL. It comes with no warranty. Many thanks to Lee Revell, who has taken part in the development of LDAS. His contributions have been very valuable, and a great help in getting this far. LDAS is developed at Centre for Quantifiable Quality of Service in Communication Systems (Q2S), at the Norwegian University of Science and Technology. Asbjørn Sæbø -- Asbjørn Sæbø Post.doc., Centre for Quantifiable Quality of Service in Communication Systems Norwegian University of Science and Technology

19 years, 7 months

[linux-audio-dev] [OT] ALSA Modular can't open ALSA device

by Artemiy Pavlov

Hello all! Please excuse me for a little off-topic post. I've just upgraded my Mandriva distro from 2005 to 2006, and now AMS won't start: [artemio@localhost ams-1.8.7]$ ams QMultiInputContext::changeInputMethod(): index=0, slave=xim LADSPA_PATH: /usr/lib/ladspa/ loadPath: /home/artemio/audio/patches/AMS/, savePath: /home/artemio/audio/patches/AMS/ Alsa_driver: detected more than 1024 playback channnels, reset to 2. ALSA lib pcm_mmap.c:368:(snd_pcm_mmap) mmap failed: Invalid argument Alsa_driver: can't set playback hardware parameters. Can't connect to ALSA What can this mean? Other audio apps making use of ALSA work just fine (Hydrogen, ZynAddSubFx, etc.). Thanks for any help, Artemiy.

19 years, 7 months

[linux-audio-dev] Re: Mixer controls

by Juhana Sadeharju

>From: James Courtier-Dutton <James(a)superbug.co.uk> > >It was just an example. The actual range depends on the sound card >hardware, but the typical limit is something like -60 dB or -80 dB. Do you process each channel with audio software prior mixing? If yes, then I would suggest to fix the hardware levels to the optimum level, and use gains only in software. As FA wrote, soundcards most likely do not have click-free mutes and smooth gains. When the hardware is fixed, you may do faded mutes in software with good quality. Fixing the hardware input and output levels makes sense to me. The input devices all have fixed SNR -- it does not help to crank up the soundcard input level as it brings the noise up. The output would be fixed for the same reasons. Also, fixing the output prevents you accidentally damage the speakers and your ears. When you crank up the gain in software, you may have a software limiter prior the monitor outputs. Once I watched when a friend mastered CDs. The fades were auditioned by cranking up the level on the mixer desk. A couple of times happened that the level was not set back to normal position when needed. :-| By fixing the hardware (including external mixer desk) in the audio path, you may have full control with the software. Soundcards are not optimal for listening fades. Only software gain allows one to audition the fades. With hardware gain the sound can be muddy, but most likely your card cannot make +64 dB gains needed in listening the fades. Cards equipped with an user-programmable dsp chip allows one to move the code from the software to the firmware. I'm in understanding that in SB Live all hardware gains are actually software gains. I.e., they have fixed the hardware. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

19 years, 7 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