Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

1 participants
7445 discussions

Re: [LAD] Anyone have experience with OSS (3 or 4)?

by Kjetil S. Matheussen

Lennart Poettering: >> by itself plus providing low-latency performance (with mixing) when >> that is required. Leaving out mixing to third-parties, plus exposing >> a very complicated low-level API and a complicated >> plugin/configuration system (which probably has taken a more time to >> develop than implementing a proper mixing engine), has created lots >> of chaos. > > You cannot blame the ALSA folks that they didn't supply you a full > audio stack from top to bottom from day one with the limited amount of > manpower available. Just accept that their are different layers in the > stack and that different projects need to tackle them. And in the end > it doesn't matter which part of the stack has what name and is written > by whom. > Please read what I wrote one more time. I pointed out a very low-level API, no mixing, and a complicated configuration system. This causes software (programmed against ALSA) very often to be buggy, or simply not run because alsa doesn't do mixing. I'm certainly not blaming the ALSA foks for not doing enough work, (quite the opposite), but instead I'm pointing out some design desicions which I think have been quite disastrous. (As far as I know, mixing for all devices has never been on any TODO list in ALSA because they think it's wrong)

14 years, 9 months

Re: [LAD] Atomic Operations

by lieven moors

Here are the details... http://effocore.googlecode.com/files/EffoDesign_LockFree.pdf

14 years, 9 months

Re: [LAD] Anyone have experience with OSS (3 or 4)?

by Kjetil S. Matheussen

Lennart Poettering: > > On Thu, 17.12.09 13:52, Kjetil S. Matheussen (k.s.matheussen(a)notam02.no) wrote: > >> Mixing works just fine, even when using ASIO. Maybe you have to start >> the asio program first though, I don't know. But still, there's no >> reason why you shouldn't have a global option, lets say 256 frames >> 48000Hz, that everything mixes down to, and then software which needs >> hardcore low-level performance must obey to that setting. > > Uh, that's a great way to burn your battery. > > If you care about more than pro audio, then you want to dynamically > adjust the sleep times based on the requirements of the clients > connected. That means you cannot use fixed sized hardware fragments > anymore, but need to schedule audio more dynamically using system > timers. > > This in fact is where most of the complexity in systems such as > PulseAudio stems from. > Okay, I didn't know that. But this is still no reason why ALSA shouldn't take care of mixing/scheduling/etc. by itself plus providing low-latency performance (with mixing) when that is required. Leaving out mixing to third-parties, plus exposing a very complicated low-level API and a complicated plugin/configuration system (which probably has taken a more time to develop than implementing a proper mixing engine), has created lots of chaos.

14 years, 9 months

Anyone have experience with OSS (3 or 4)?

by Kjetil S. Matheussen

After about 10 years of frustration, I'm a bit tired of alsa. Does anyone know if OSS supports proper software mixing? Is the alsa emulation working somewhat okay? Are there any problems configuring the machine to use more than one card?

14 years, 9 months

Re: [LAD] Atomic Operations

by lieven moors

< However you can also use them to < implement circular FIFOs for example, which is a trick used all the < time in audio as well as in kernel programming. For anyone interested... The Effo libraries seem to have a fair choise of lock-free queue and ringbuffer implementations in the addon project: http://code.google.com/p/effoaddon/ But I have to admit that i find these concepts quite confusing...

14 years, 9 months

Atomic Operations

by Gabriel M. Beddingfield

Recently on this list, Paul referred to an "atomic integer swap" and an "atomic pointer swap." This was a new concept to me (and possibly others), and this e-mail shares what I've learned. If you access a variable from multiple threads -- even a built-in variable like 'int', it is important to control access to the variable with a mutex, semaphore, or an atomic operation. Alexander Sandler, on his blog, wrote a couple of good articles on the subject: "Do you need a mutex to protect an int?" http://www.alexonlinux.com/do-you-need-mutex-to-protect-int "Multithreaded simple data type access and atomic variables" http://www.alexonlinux.com/multithreaded-simple-data-type-access-and-atomic… The first article contains code that calculates a wrong answer on multiprocessor machines. I've attached a similar example that will even fail on a single-processor machine. There is a wealth of reading material on using Mutexes and Semaphores. However, information on atomic operations appears to be sparse and hard-to-follow. So, here's what I've found: + At the moment, there is no built-in support in C/C++ for atomic operations. You will need to use a library, compiler extension, or write your own in assembly code. + The GCC compiler has the built-in __sync_*() functions[1] that provide atomic operations. Note that the attached example is using this. + glib provides the g_atomic_*() functions[2]. + Qt 4 has the q_atomic_*() functions.[3] While they are accessible, they are /not/ a part of their stable, public API. + The next version of ISO C++ (code name c++0x) is expected to have support for atomic operations (E.g. the std::atomic<T> template) and memory barriers. It may even require that all built-in types be atomic. + In the x86 instruction set, these are usually implemented using the 'LOCK' instruction prefix.[5] When using atomic operations, perhaps the best advice I found is near the end of Sandler's second article: "When using atomic variables, some extra precautions have to be taken.... There is nothing that prevents you from incrementing value of the atomic variable with __sync_fetch_and_add() as I just demonstrated and later in the code doing same thing with regular ++ operator. "To address this problem, I strongly suggest wrapping around atomic functions and variables with either ADT in C or C++ class."[4] Peace, Gabriel [1] http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html [2] http://www.gtk.org/api/2.6/glib/glib-Atomic-Operations.html [3] http://doc.trolltech.com/4.3/atomic-operations.html See also the Qt header file QtCore/qatomic_i386.h, and its brothers. [4] http://www.alexonlinux.com/multithreaded-simple-data-type-access-and-atomic… [5] http://siyobik.info/index.php?module=x86&id=159

14 years, 9 months

ladspavst.linuxaudio.org site is going offline

by Ivica Ico Bukvic

All ladspavst users/contributors, A ladspavst visitor has brought to my attention that the ladspavst.linuxaudio.org has been spammed for quite some time, rendering a page into useless goop of spam. This is mainly due to lack of moderation. As a result, I've no other choice than to take the site offline until further notice. If you or someone you know is supposed to take care of this site, please contact me and we'll figure out the best way to bring this site back online. Until that happens, the site will remain offline. Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) ico(a)vt.edu http://www.music.vt.edu/faculty/bukvic/

14 years, 9 months

Maximum size of SysEx messages in JACK MIDI and ALSA sequencer

by Dominic Sacré

Hi, I'm wondering what the size limit is for SysEx messages in the JACK MIDI and ALSA sequencer APIs. My observations so far: In JACK MIDI, a SysEx message can be as large as the MIDI port buffer, which in turn has the same size as an audio buffer for one period. This is assuming that there are no other events transmitted on the same port during the same period. Is this correct? Or are applications somehow expected to handle larger SysEx messages split over multiple periods? In the documentation of the ALSA sequencer API, I couldn't find any mention of an upper limit. Some sources suggest that ALSA splits SysEx messages into chunks of 256 bytes, but from my own attempts at sending larger messages, it seems the limit is actually somewhere around 5500 bytes. Unfortunately ALSA doesn't seem to report an error when I try to send larger chunks, instead the messages just disappear. Can anyone shed some light on how to handle larger SysEx messages correctly? Thanks, Dominic

14 years, 9 months

libsndfile-1.0.21

by Erik de Castro Lopo

Hi all, Yesterday I released version 1.0.21 of libsndfile. Its available here: http://www.mega-nerd.com/libsndfile/#Download Main changes for this version are: * Add a couple of new binary programs to programs/ dir. * Remove sndfile-jackplay (now in sndfile-tools package). * Add windows only function sf_wchar_open(). * Bunch of minor bug fixes. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

14 years, 9 months

Hi,,go to Dopcity !!

by Γιάννης Γράβεζας

dear www.dopcity.com ，It can be a good place for select christmas gift! let's go!

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