Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] sample-accurate comparison

by Andrew Gaydenko

Hi! The aim is trivial: - get some wav file, - burn it to CD-R(W), - rip it, get a copy, - compare the original file with the copy. If I understand well, the main problem here is to determine "the same starting point" for each of files. Is there some kind of software which may be useful in such comparison. (probably, some of answer may be like this: "learn scheme/ruby and use snd". I'm interested in more short way :-) Andrew

20 years, 7 months

[linux-audio-dev] Re: LAC 2005 streaming: please test!

by Jordan

Seems to be pretty good. The audio samples were flawless in XMMS. I played the video files in the VideoLAN client. They seemed to be pretty good, but the video was quite a bit jumpy in high-res mode (could be on my end, of course).

20 years, 7 months

Re: [linux-audio-dev] GPL concerns

by eviltwin69＠cableone.net

On Wed, 6 Apr 2005 22:09 , Erik de Castro Lopo <erikd-lad(a)mega-nerd.com> sent: >On Wed, 06 Apr 2005 00:31:15 -0500 >Shane lists(a)itsagesolutions.com> wrote: > >> Hey everyone. I have a bland but important question for everyone. Say >> hypothetically a company is developing an audio product using lots of >> GPL source, but for whatever marketing reasons asks for NDA concerning >> the codebase. Lots of GPL work is referenced and at least dynamically >> linked, and though the company has directly stated that it will release >> the codebase publicly with the product release (once it is complete). >> >> I am curious as to the general feel in the community on such practices. >> Would this 1) be a violation of the GPL, > >Yes. > >> 2) if it is how tolerant would >> the OSS community be, considering the general good intent of the >> project, and > >If any of my code is involved, I will prusue the matter. > > >> 3) if I were asked to sign such a NDA would that document >> be a binding agreement even if the NDA itself might be a violation of >> the GPL since it is inherently counterintuitive to the intent of the >> GPL. > >The GPL is pretty clear about this. The GPL comes into action when >the binaries or code derived from GPL code is **distributed**. >That means that you and the company can hack on whatever GPL code >you like as long as they don't release a binary (under NDA or not). > If you are part of the company or a contractor to the company and the product is not distributed outside the company you can do whatever you want with the code without having to release it. If you are outside the company and have to sign an NDA then I think that would be considered distribution and would therefore violate the GPL. As Erik said, once it's distributed then it has to be released. Jan

20 years, 7 months

Re: Re: [linux-audio-dev] FOSS-tools for realtime audio analysis?

by mathias_lundgren＠bredband.net

> > From: Alfons Adriaensen <fons.adriaensen(a)alcatel.be> > Date: 2005/04/06 on PM 01:00:45 GMT > To: "The Linux Audio Developers' Mailing List" > <linux-audio-dev(a)music.columbia.edu> > Ämne: Re: [linux-audio-dev] FOSS-tools for realtime audio analysis? > > You may mave a look at JAAA, (JACK and ALSA Audio Analyser). This is a > realtime 'technical' (rather than musical) spectrum analyser, designed > to make accurate measurements. It will also generate sines and white > Gaussian noise. It's at > > <http://users.skynet.be/solaris/linuxadio> > > You will also need some small shared libs available from the same > place. > > I'm considering some additional functionality, and if you have any > specific requirements I'd be interested to know. > Thanks! Actually, it's a friend of mine interested in something like this. One thing that I know he was curious about was if it would be possible to develop some kind of test-case for external hardware, which could give an indication of whether something is wrong with it or not. >From just taking a peek at it, I'm getting the impression that this is mainly a graphical tool (which is really cool). Anyway, he's not afraid of hacking if this is what he's looking for. Are features like these anything you've considered/already implemented/interesting? > I am also working on a Room Impulse Response measurement system using > a sine sweep as the stimulus. First release expected in a about two > months. > > -- > FA > > > >

20 years, 7 months

[linux-audio-dev] [Fwd: ICMC 2005 Free Sound Project]

by Xavier Amatriain

> > I would like to invite you all to have a look at The Freesound Project. > > -> http://freesound.iua.upf.edu/ > > This project was started in the context of ICMC 2005, and is a website for creative-commons licensed audio material exchange. If you want to know more about the project (why it was started and what it's goals are) have a look at this page: > > -> http://freesound.iua.upf.edu/whatIsFreesound.php > > Don't hesitate to contact me (bdejong(a)iua.upf.edu) for more information or feedback. > > > kindest regards, > > Xavier Serra > ICMC 2005 Program Chair > > PS: please feel free to forward this message to relevant mailing lists or interested people. > > -- /********************************** ********* Xavier Amatriain ******** ****** Music Technology Group ***** ** IUA- Universitat Pompeu Fabra ** ****** www.iua.upf.es/~xamat ****** ***********************************/

20 years, 7 months

[linux-audio-dev] FOSS-tools for realtime audio analysis?

by mathias_lundgren＠bredband.net

Hi! Are there any tools/libraries around which makes it possible to do something like this? 1) Feed an audio signal (f.ex. a sinus wave) into external hardware 2) Record the signal returned from the external hardware 3) "Compare" the two signals (realtime would be neat, if you know what latency you have btwn output/input I hope this might be achieved w Jack) and perform some kind of analysis of what the external hardware does to the signal (S/N ratio, damping, etc etc). Open source stuff would of course be preferable /Mathias

20 years, 7 months

[linux-audio-dev] [PATCH] liblo & pattern matching callback

by Martin Habets

Hi Steve, Was testing this scenario today, which may look familiar to you: - I created a server with some methods: '/ping/documentation' and '/osc-schema/documentation', both of which use the same handler 'doc'. - I send query '/*/documentation' to the server. - 'doc' got called twice with path '/*/documentation'. The unexpanded path makes it impossible for the handler to determine what container was intended. In my interpretation the OSC spec is not completely explicit on this point, but I think the intention was to send the expanded path to the handler. The spec is specific in stating that '*' is invalid in an OSC method, and it talks about the "OSC Address of a OSC Method". Initially I hacked liblo to always send the expanded path. However, the result was also that the generic method handler (oh, I used that too :) got called with a NULL path. Since that is useless to that handler it seems best to me to use the unexpanded path for this case. The resulting patch is applied. Please let me know your view on this. Cheers, -- Martin --------------------------------------------------------------------------- Index: liblo/src/server.c =================================================================== --- liblo.orig/src/server.c 2005-03-02 19:15:47.000000000 +0000 +++ liblo/src/server.c 2005-03-26 11:33:41.000000000 +0000 @@ -463,6 +463,7 @@ lo_address src = lo_address_new(NULL, NULL); char hostname[LO_HOST_SIZE]; char portname[32]; + const char *pptr; free(msg->types); msg->types = types; @@ -542,7 +543,13 @@ } } - ret = it->handler(path, types, argv, argc, msg, + /* Send wildcard path to generic handler, expanded path + to others. + */ + pptr = path; + if (it->path) pptr = it->path; + + ret = it->handler(pptr, types, argv, argc, msg, it->user_data); } else if (lo_can_coerce_spec(types, it->typespec)) { @@ -572,7 +579,13 @@ } endian_fixed = 1; - ret = it->handler(path, it->typespec, argv, argc, msg, + /* Send wildcard path to generic handler, expanded path + to others. + */ + pptr = path; + if (it->path) pptr = it->path; + + ret = it->handler(pptr, it->typespec, argv, argc, msg, it->user_data); free(argv); free(data_co);

20 years, 7 months

[linux-audio-dev] Jacklaunch vs. asoundrc jack plugin

by Ivica Ico Bukvic

Hi all, First of all, please accept my apologies for cross-posting. I simply feel that this issue may be of interest to all these groups. After some research and experimenting with jacklaunch (libjackasyn) as well as alsa .asoundrc jack plugin I found out that very few apps actually cooperate with either of these. Jack plugin for asoundrc practically works only with aplay/arecord and freebirth. Audacity doesn't cooperate with either, while jacklaunch even though it has been reported to work with sweep doesn't on my machines (mdk 10.0 and 10.1). I've tested latest jack, sweep, Alsa 1.0.6 and 1.0.7 (I did not go beyond that as 1.0.8 has apparent issues with hdsploader) and had no luck whatsoever. Hence, I am just wondering at this point whether asoundrc jack is still in the testing phase (some of the errors that apps reported trying to use jack plug were due to inability to probe some info from the alsa driver which implies possible incompleteness of the implementation or weird probing from the app's side) and also whether anyone has had better luck than myself using either of these with audacity, sweep, and other non-jackified, yet important Linux audio apps via either of the aforementioned ways. FWIW, it would be really nice to see some united effort to jackify some of the other critical Linux audio apps even if their original authors do not feel like that is one of their priorities (I know, I know, if I am so interested in such developments then I might as well set an example by doing what I am advocating, which is something I would love to do, but unfortunately currently the notion of "free time" in my life is but a joke). Many thanks! Best wishes, Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico/ -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.3 - Release Date: 4/5/2005

20 years, 7 months

[linux-audio-dev] live pa questions

by Dave Griffiths

Hi all, Is there a chance that signals generated from software could damage live PA equipment? I'm guessing not, as there is obviously (I assume) some limiting built into soundcards, but I'm just wondering what applications do to, if anything, to help. It's just something that worries me sometimes when playing live, and generating particually nasty noises by accident, or design :) cheers, dave

20 years, 7 months

Re: [linux-audio-dev] live pa questions

by Pieter Palmers

Andres Cabrera wrote: >>Overheating of the amp is nonsense. Most amplifiers operate in class A >>or AB anyway, and maybe in class D. Heat dissipation is independant of >>the input signal for these amps. The types that might build up a problem >>with heat (e.g. class H) aren't used in PA enviroments. And before the >>amp overheats, your speakers will be dead. >> >> > >Thanks for clarifying. I remembered I heard about overheating somewhere >with DC, and thought it was on the amp. >Adding a small DC offset is one easy way of getting rid of denormal >problems (in programs like csound and pd), do you know if this small DC >offset is able to produce these effects? > > I don't know about the output stage of a soundcard. (Almost) every soundcard uses a delta-sigma DAC, which needs some sort of low pass filtering. It needs an output buffer to transform the rather high impedance of this filter to a low output impedance, so the question is if there is some sort of DC decoupling impemented in this buffer. I don't know, but using a voltmeter (or scope) while applying a DC signal to the card will answer that. if you take a look at the specs of the EMU1820M it states "Frequency Response: 0.0/-.35dB, 20Hz - 20kHz" which would mean that it doesn't output DC signals. But as far as I know, most audio input stages are capacitively coupled, thereby removing such DC offsets, so there is little chance that this type of signals will propagate through the entire signal chain. Greets, Pieter

20 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