Linux-audio-dev June 2005

linux-audio-dev@lists.linuxaudio.org

120 participants
101 discussions

[linux-audio-dev] Proposed scary kernel change for 2.6.13

by Lee Revell

Andrew Morton and others want to change the default value of HZ to ~250 for kernel 2.6.13, "to save power on laptops". I think this is absolutely insane, I should not even have to explain why. If you feel the same way, *please* complain about it on LKML. The thread is called "-mm -> 2.6.13 merge status". They at least need to merge the high-res timers patch at the same time, so that users will not see a regression in the sleep() resolution from 1ms to 3ms. Lee

20 years

[linux-audio-dev] more on damaging signals

by Dave Griffiths

Hi all, I posted some questions a while back about signals that could potentially damage PA speakers, or equipment after amplification. I'm starting to look at using a genetic programming synthesiser I'm writing for live performance: http://www.pawfal.org/index.php?page=WigWamJam This synthesiser can create arbitary functions for rendering samples, these functions are then randomly mutated and guided by the user by aesthetic choice. As you can imagine, during this process rather nasty sounds can be generated (this may not prove to be a useable system for live use without people getting annoyed and throwing things at me, but, erm, bear with me here :) Other than user driven selection based on the audible results, some automatic removal of functions is going to have to happen. From people's feedback on LAD these would include rendered sounds that have the following features: * high dc offset * very low frequency * very high frequency I'd like to avoid filtering the sounds as a post process ideally, but I guess some enveloping would be needed to prevent sudden jumps in dc at the beginning and end of the samples. I'd also automatically remove functions that result in silent samples. Any thoughts? cheers, dave www.pawfal.org/nebogeo

20 years

[linux-audio-dev] Pro?

by Jens M Andreasen

Hi! There has been some discussion lately involving keywords such as "amateuer" and "professional". An "amateur" works for the love of it (as in 'amore'.) A "professional" works to earn his/her daily bread (as in 'proffezione'.) Those two concepts are not mutuallally exclusive per se. It is not unsual though, for "pros" to get fed up with their chosen line and still do their thing for the love of money, or lack of alternatives. Whatever .. We also have touched the words 'consumer' as well as 'producer'. Playing an mp3 (or ogg?) is a typical consumer behaviour. Creating an mp3 (or ogg) from scratch as in you, recording your grandma singing "Happy Billday", is a production. So?! When we say 'pro', it would make much more sense if we could agree on that this means "produzione" rather than "profezionale". Mvh // Jens M Andreasen (My appologies to Benno for the mindless ad hoc Italian/Latin lingo.) --

20 years

Re: [linux-audio-dev] Re: Re: What Parts of Linux Audio Simply Work Great?

by eviltwin69＠cableone.net

On Mon, 2005-06-20 at 15:48 +0200, Alfons Adriaensen wrote: > [Tim Orford] > > > although "pros" have some valuable knowledge, one of the funny > > things about them (and i am guilty of this) is that they all > > think other pros are like them, which is not remotely true. > > There are big differences between pros in different professions, > > and even within the same discipline. The differences are not > > overcomable, and i think you would be better off trying to analyse > > and accomodate the differences rather than underplaying their > > existance. > > > Wise Words (but I suspect you wanted to write 'not *un*overcomable') > > "Insurmountable" would be even better. Jan

20 years

[linux-audio-dev] Linux RT Summery

by Garett Shulman

There is a length sumerry of the LKML RT discussions here: http://kerneltrap.org/mailarchive/1/message/76742/thread -Garett

20 years

[linux-audio-dev] Re: Re: What Parts of Linux Audio Simply Work Great?

by Lachlan Davison

> > 3. 'amateur' users vs. 'professionals'. > > Since a took a clear stand on this matter, let me define what > I mean by a 'professional' in this context: someone who makes > a living by providing a service to customers who pay for it. > I still maintain that someone in this position will not mind > logging in as different users for his personal and pro work. > He / she will probably use different machines anyway. It's > just a matter of 'best practice' and professional conduct. > > > > > As was already pointed out, prosumer and professional users > > > will in all probably have two different audio cards anyway. > > > At least for the hobbyist (and I can speak for them): > > disagreed :) . Just to join in... from a dance music making perspective i'm not sure if i understand this customer concept. Does your fav rock band use "best practice" and professional conduct? are they not professional? I hope at least some of the people on here are interested in making music too, and i hope we can focus on that. The key thing i've learned from my limited experience with music, more time making music and less time getting your computer to work means better music. So i think the goal really needs to be as Jay said, it just works. Though i'm coming from the just doing it for fun camp so take that into account.

20 years

Subject: Re: [linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?

by lazzaro

> On Sat, Jun 18, 2005 at 02:34:46AM +0200, Christoph Eckert wrote: >>> I think we should (and can) keep the desktop and 'pro' >>> worlds separate. >>> >> >> I do not agree :) . We're in the free software world, so >> there's no need to tell the non-pro-audio-users "use anything >> else". How OS X solves this problem may be instructive. [most facts below are probably right, I'm sure I got a few wrong ...] In the System Preferences->Sound menu, a user can choose the default audio input and audio output device. In the CoreAudio API, this choice becomes the current value of kAudioHardwarePropertyDefaultInputDevice and kAudioHardwarePropertyDefaultOutputDevice. Consumer-oriented apps use those Defaults, as a rule; content-creation apps usually have their own Preferences that let you select the audio devices for the app. CoreMIDI works this way too. So, the underlying system is "pro", but there are provisions in the API to handle the mindset of both pro and consumer worlds. Finally, note that Apple solved the legacy problem by emulating Sound Manager (OS 9 audio API). Until Tiger, QuickTime actually used Sound Manager. Many other apps still do. If Linux followed this model, one would write emulators over jack for all of the consumer audio APIs being used in jack, to accommodate the installed base, and have the emulations work well enough to convince distros to just ship jack as the bottom layer, and use its emulated APIs. Then, you can start evangelizing direct jack calls to all application developers, consumer and pro alike. Yes, this takes a lot of work, and is not in the direct path of solving pro audio problems. Just like I've spent 5 years on pushing RTP MIDI through the standards process because I felt someone had to do it, I think the Linux audio API problem only gets solved if someone decides to dedicate 5 years of their life to doing it. That's how long a systems project takes to have an impact on the world. Good luck. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

20 years

[linux-audio-dev] alsa ethernet streaming?

by Garett Shulman

Hello, I would like push audio streams over ethernet and was wondering what avenues people have tried. I intend to have two linux boxes (or more). Box1 has the user interface and all of the audio data. Box2 has no user interface and is plugged into an amplifier and speakers. Eventually I would like to have many Box2's. I envision an application with a server running on box2 and a client running on box1. Ideally the client would create an ALSA input and the server would create an ALSA output. Then, the client connects to the server, any ALSA enabled app connects to the input created by the client, and audio is heard from the speakers connected to the server. I have no expectations that such an application actually exists. I'm curious as to what options do exists to push audio over etherenet. -Garett

20 years

[linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?

by Peter Zubaj

>What I mean is if you have your soundserver, you are still left with >rewritting every single app you ever want to use to use the soundserver, >otherwise the problem still remains. There are a hell of a lot of tools >around that use either plain OSS or direct ALSA. Why not simply use alsa api. alsa-lib is not dependand on alsa-driver. You can write(for example)esd alsa-lib plugin. All applications which uses alsa api can be redirected to esd using this plugin withou user notify this. If needed, it can go directly to soundcard or dmix. What makes alsa unique is alsa-lib (I personally thing this is best alsa part) not alsa-drivers. Peter Zubaj ___________________________________________________________________________ Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete. http://www.wanda.sk/

20 years

Re: [linux-audio-dev] Re: What Parts of Linux Audio Simply Work Great?

by Peter Zubaj

>this woud IMHO be the best solution, but it will not happen or >at least last very long until > >* all distros will have JACK running per default >* all developers of any audio program have rewritten their >code. Why not use only ALSA API. There is alsa to jack plugin. If someone wants use jack it can be used to route audio to jack. Also there are alsa <-> OSS driver plugins. This means you can output sound from alsa app to oss driver or capture from alsa driver without any source change. Peter Zubaj ___________________________________________________________________________ Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete. http://www.wanda.sk/

20 years

← Newer
1
2
3
4
5
6
7
...
11
Older →

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 June 2005