Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7441 discussions

by Allann Jones

Hi, Anyone knows how can I use callback builtin functions to operations like capture, playback and events using ALSA API? For a while I'd implemented calls to callback functions in each return of 'writei' and 'readi'. Thank you.

19 years, 3 months

Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)

by Peter Zubaj

Hi, Why not solve this kinds of problems. Soulutions: 1) Remove OSS drivers from kernel - then all problems will be alsa problems. 2) Remove OSS emulation from alsa - then all problems will be OSS problems. Otherways this will be newer end. Peter Zubaj ___________________________________________________________________________ Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete. http://www.wanda.sk/

19 years, 3 months

Re: [linux-audio-dev] Re: Looking for fast integer resampling code

by Kjetil Svalastog Matheussen <k.s.matheussen＠notam02.no>

Erik de Castro Lopo: > > Kjetil Svalastog Matheussen wrote: > >> I was primarily testing speed, but both libraries where using the sinc >> routine, so... > > Yes, but you can design a sinc filter with 10 coefficients and one > with 10000. The one with 10000 coefficients will have a steeper > transition band and a better signal to noise ratio. > Yes. But back to the point, I think there is an extremely good chance that mus_src (even by setting the width-argument to 5 (default value is 10 which is also faster than SRC_SINC_FASTEST)) will sound better than whats being produced by a linear resampler, and might be exactly be what the person asking the question is looking for.

19 years, 3 months

Re: [linux-audio-dev] How to access "real-time" capabilities

by Jonathan Woithe

Lee Revell wrote: > On Fri, 2005-06-10 at 11:12 -0700, Ian wrote: > > Can anyone tell me *very briefly* what is the current > > state of play regarding realtime-lsm in the 2.6.* > > kernels and whether this feature (or something like it > > ) is likely to be introduced into the kernel anytime > > soon. > > realtime-lsm should be considered deprecated. The solution accepted by > Linus is rlimit based. I think this will be in 2.6.12 (seems to be in > the release candidates). Check the archives for "rlimit". > > This will require patching PAM and bash. In the interim you could try set_rtlimit: http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz It allows you to access the enhanced rlimits (ie: RT scheduling and nice levels) under 2.6.12 kernel or later without needing to patch anything. In fact, even once PAM/etc are patched this might be preferred by some since it allows you to control the limits based on the program being run; so for example you can allow /usr/local/bin/ardour to run at realtime priority 50 while /usr/bin/yes (for example) can't. Regards jonathan

19 years, 3 months

Re: [linux-audio-dev] Re: Looking for fast integer resampling code

by Kjetil Svalastog Matheussen

Erik de Castro Lopo: > > > > I recently did a lot of benchmarking between libsamplerate and mus_src > > in clm/sndlib. My result was quite interesting, the fastest mus_src sinc > > resampler where a lot faster than the fastest libsamplerate resampler. > > I think most people would agree that speed is not the most important > aspect when measuring the quality of a sample rate converter. > I was primarily testing speed, but both libraries where using the sinc routine, so... > With libsamplerate, I can state that the three sinc based converters > have the following characteristics: > > SNR Bandwidth > SRC_SINC_FASTEST 102.42 dB 80.23 % > SRC_SINC_MEDIUM_QUALITY 98.99 dB 90.68 % > SRC_SINC_BEST_QUALITY 97.43 dB 96.96% > > where SNR is signal to noise ratio and Bandwidth its a percentage of > the theoretical best bandwidth (ie half of the minimum of the source > and desination sample rate). > > > A third program is the original sinc-resampler from Julius Smith: > > http://ccrma-www.stanford.edu/~jos/resample/ > > I don't know how this one performs compaired to the other two though. > > libsamplerate the same algorithm as this one. I think Julius O. Smith > developed this algorithm. > He did, and Bil Schottstaedt used this algorithm as well for mus_src. When I compaired mus_src with width=5, and libsamplerate with SRC_SINC_FASTEST, the first one is much faster, I don't know what kind of SNR/Bandwidth you get with your way of measuring when using mus_src with width=5, but the source is easy to read so I guess you can figure it out. --

19 years, 3 months

[linux-audio-dev] Re: Looking for fast integer resampling code

by Kjetil Svalastog Matheussen

Dave Chapman: > > The most common case will be downsampling 48KHz->44.1KHz, but there are > also users who need upsampling from various lower frequencies (e.g. for > use with audio books). > > So we're looking for pointers to any high quality (but fast!) resampling > code that could be used. I recently did a lot of benchmarking between libsamplerate and mus_src in clm/sndlib. My result was quite interesting, the fastest mus_src sinc resampler where a lot faster than the fastest libsamplerate resampler. I don't have the results available right now, but I remember that mus_src performance wasn't very far from beating the linear resampler in libsamplerate. I did a lot of test with various types of data and compiler-options, so I don't think it was a coinsidence. However, it might have been because of some optimalization gcc was doing or something to do with the cache. The mus_src code is far smaller and easier to read than the one for libsamplerate. I did not hear any difference in soundquality, but I guess there might be a difference. Sndlib: http://ccrma.stanford.edu/software/snd/snd/sndlib.html mus_src is available in the file clm.c . libsamplerate: http://www.mega-nerd.com/SRC/ A third program is the original sinc-resampler from Julius Smith: http://ccrma-www.stanford.edu/~jos/resample/ I don't know how this one performs compaired to the other two though. --

19 years, 3 months

[linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?

by Jay Vaughan

hi all, i'm currently working on a rather large project which i'd like to fully support under Linux .. it requires, however, a functioning MIDI sub-system. for this reason, i'd like to ask members of LAD to report on their experiences with using professional MIDI interfaces, such as (for example) the Motu MTP AV, Digidesign MIDEX-8, etc? what is the 'easiest' MIDI interface to get working under the average Linux kernel? what sort of experiences do folks have with getting MIDI working (on a programming level) using API's such as (but not limited to) ALSA, and MidiShare? for me so far, MidiShare seems to offer the most direct and usable approach .. while ALSA is wraught with complexity and dependencies which often seem out of control. i'd like to know what your experience, as developers, has been with getting a working MIDI subsystem under Linux ... -- ; Jay Vaughan

19 years, 3 months

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

by Rui Nuno Capela

QjackCtl 0.2.16 is finally out! After laying around for a long time in the backyard (aka CVS:), the Qt front-end to the one-of-a-kind JACK audio server daemon is finally made public. Rejoyce! As one can read from the changelog: - ALSA sequencer client/port name changes are now properly detected on the MIDI connections widget (as noted by Chris Cannam. Thanks). - Long overdue transport buttons (rewind, backward and forward) finally landed onto the main control window, at last :). - Duplication (copy) of patchbay socket items was added. - Do not ever try to start the JACK server if there's one already found running, on which case the client-only mode of operation is then activated (as kindly suggested by Orm Finnendahl, thanks). - After several Mac OS X user requests, ALSA/MIDI sequencer support is now an option, otherwise detected at configure time and conditionally compiled in if, and only if, ALSA is found available (which has been a primordial assumption on Linux systems:). Ah, and that just makes for the blind inclusion of another backend driver option: coreaudio. - Actual OSS device selection menu now featured on setup dialog; these adds to the device selection button menus for the OSS driver settings. - Delayed geometry setup of windows upon startup was added as an optional workaround to subtle problems due to window decoration information not being available at window creation time on some window managers (as patch proposed by Dirk Jagdmann. Thanks). - Fixed some minor but rather old bug that was quitting the application abruptly, when one switches off the system tray icon while the main application widget is hidden. - Cancel is now an option when creating a new patchbay definition. - Context menus are finally littered with icons. - Minor configure and Makefile install fixes, as Debian and Mac OS X specialties. Also, install does the right thing with target file modes (thanks to Matt Flax and Ebrahim Mayat, for pointing these out). You can get away with it from the usual place: http://qjackctl.sourceforge.net/ http://sourceforge.net/projects/qjackctl Enjoy! -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

19 years, 3 months

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

by Rui Nuno Capela

19 years, 3 months

[linux-audio-dev] [OT] disaster redux

by Dave Phillips

Greetings: It has not been a good week. As I mentioned yesterday I swapped my hardware into an identical box as my original machine. Yesterday everything seemed to have returned to normal operation. I watched some movies, worked on some music, and so forth. Today I powered up the box, logged on to the net, downloaded the latest Csound CVS and started compiling. After a few minutes everything froze again, the machine was locked tight as a drum. I had to pull the plug to restart, but when grub came up my keyboard was frozen. I pulled the plug again and got my keyboard back after restarting. Now I'm running memtest again. I realized yesterday that I'd run it on only one RAM stick so I thought I'd better check again. However, at this point I'm starting to suspect a bad drive. But *two* bad drives in the system ?? As I mentioned in an earlier message, the machine failure occurred regardless of which drive I was using (RH9 on /dev/hdb, FC3 on /dev/hda). So I'm bummed again. Looks like it's time to bite the bullet and buy a whole new system. :( Best, dp

19 years, 3 months

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