Linux-audio-user

linux-audio-user@lists.linuxaudio.org

20661 discussions

[linux-audio-user] [OT] recording fom turntable (ripping LPs)

by Erik Steffl

so i finally got the recording on sb live! platinum working and I'd like to rip my old LP collection. So I bought the only turntable with pre-amp I have found, connected it and the sound was terrible (I think it was mostly too weak, wasn't even at 50% at max), it's also a cheap denon. I connected it to the RCA inputs on the liveDrive (front panel). BTW the liveDrive RCA work ok with line6 guitar pod and iPod. so my off-topic question is - how to connect the turntable? which turntable to get? since I mostly plan to use it to rip the LPs and I'm not going to use it afterward I'd prefer cheaper solutions (not the denon though:-) I also have receiver with phono input (so no pre-amp in turntable needed) but I have no way to get the signal out of receiver, it only has speaker outputs. so I guess I need sort-of-decent turntable with pre-amp or turntable plus external pre-amp? any recommendations? (and yes, I am using linux box with gramofile, so this is at least close to the topic:-) TIA erik

21 years, 6 months

Re: [linux-audio-user] Fwd: [Jamin] Re: soft clip: Achieving Gain, inconsequential overloads

by davidrclark＠earthlink.net

Mark, > You know, in all of my time spent messing with Pro Tools, and being > involved in the forums where a lot of us have shared our music for > critical comment, the only comment I've EVER heard about my mixes not > being loud enough is that people don't want to be bothered dealing with > the volume control on their system. So why doesn't the volume go to the average? Or why doesn't everybody turn their volumes DOWN instead of UP? You can't explain that by what you just said. Something else is going on. That something else tends to favor louder. Also, Ron Parker recently posted: "I have to admit the new loud master is better." Why is that? Now I myself have turned up my volumes considerably for exactly the reason you said: To match other volumes. But the explanation of why things tend up not down and not to an average MAY be a preference for more harmonics. Suppose someone turns up the volume for more harmonics. The rest of us come along and increase our volume to keep pace. The levels now are all the same. Someone turns up the volume again for more harmonics. The rest of use do the same, but merely to keep pace. And so on. We're part of the problem.

21 years, 6 months

[linux-audio-user] [ANN] Ecasound 2.3.3 released

by Kai Vehmanen

Hello all, this year's first stable Ecasound release is now out! Most of the final tuning for this release was done last Sunday while watching and listening to the last sessions of 'laconf2'. Many thanks to all the organizers and participants! And special thanks for the excellant net coverage of the event! But now, back to the 2.3.3 release -- here are the details: 1. Summary of changes Bugs in ecasignalview, effect presets, NetECI protocol parser and the C ECI implementation have been fixed. Many build system issues, including errors in building against libsndfile-1.0.4 and older, have been resolved. A separate section covering ecasound.el, the ecasound emacs interface, has been added to the Ecasound Control Interface Guide. The Ecasound User's Guide has also been updated. --- 2. What is Ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release * Preset handling fixes: When saving chainsetups containing presets, values of preset parameters were not saved correctly. Also problems with presets containing untitled parameters have been fixed. * New ecasoundrc(5) setting "autodetect" for "default-output" has been added. When selected, libecasound will check for JACK support and whether a JACK server is running, if not found, check for ALSA, then OSS, and finally fallback to using "rtnull". This feature is especially useful to apps such as ecaplay. * Fixes to ecasignalview: Proper cleanup after receiving an interrupt from keyboard (SIGINT/CTRL-C) has been added. Originally tested on FreeBSD, but helps on Linux as well. * Ecasound Interactive Mode (EIAM) updates: Added new command 'map-ladspa-id-list' to allow listing the available plugins by their unique ID numbers. A special case value of '-1' is now understood by 'cs-set-length'. This allows undoing any previously set length value. * Ecasound Control Interface (ECI) updates: Added a section on ecasound.el - the Ecasound emacs interface - to the ECI Guide [1]. Several bugs have been fixed in the ECI C implementation. A serious bug in NetECI protocol parser, that caused parsing long (over 32 chars) commands to fail, has also been fixed. * Documentation updates: The Ecasound User's Guide [2] has been updated. Also, a bug in the groff source for the ecasound(1) man page that prevented man from showing the last five pages of the document, has been fixed. * Build system fixes: Problems in building against libsndfile-1.0.4 and older have been fixed. 'libecasound-config --libs' has been fixed to return the full list of external libraries. Based on recent discussions on linux-audio-dev, minor changes have been made to processing CFLAGS, CXXFLAGS and LDFLAGS. Full list of changes is available at <http://www.wakkanet.fi/~kaiv/ecasound/history.html>. --- 4. Interface and configuration file changes * ecasoundrc(5) - "default-output": new value "autodetect" (default) --- 5. Contributors Patches - Accepted code, documentation and build system changes Michael Ewe (2) -- bugfixes to ecasignalview and ECI C impl Mario Lang (1) -- section on ecasound.el to ECI Guide Eric Rzewnicki (1) -- set of updates to Ecasound User's Guide Kai Vehmanen (n/a) -- various Bug Hunting - Reports that led to bugfixes (items closed) Pierre Lorenzon (1) -- bugs in ecasound's daemon-mode protocol parser Jan Weil (1) -- cs-save dit not save preset parameters Feature suggestions - Ideas that led to new features (items) Jan Weil (2) -- map-ladspa-id-list command, -t:1 option --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.3.3.tar.gz Referenced documents: [1] - http://www.eca.cx/eci-guide [2] - http://www.eca.cx/eca-u-guide Distributions with maintained Ecasound support: Agnula - http://www.agnula.org AltLinux - http://www.altlinux.com Debian - http://www.debian.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org Mandrake - http://www.mandrake.org PLD Linux - http://www.pld.org.pl SuSE Linux - http://www.suse.de/en Contrib Packages and Add-On Distributions: AudioSlack for Slackware - http://www.audioslack.com PlanetCCRMA for RedHat/Fedora - http://www-ccrma.stanford.edu/planetccrma/software Thac's RPMs for Mandrake - http://rpm.nyvalls.se Note! Distributors do not necessarily provide packages for the very latest Ecasound version. --- http://www.eca.cx Audio software for Linux!

21 years, 6 months

[linux-audio-user] Hot or not? I'd say the former

by Frank Barknecht

Hallo, see this test of the "Hercules Audio - DJ Console": http://www.hothardware.com/printarticle.cfm?articleid=342 Cool. only a bit too expensive. Ciao -- Frank Barknecht _ ______footils.org__

21 years, 6 months

Re: [linux-audio-user] Indexing the Read Pointer in /dev/dsp

by Martin McCormick

Paul Winkler writes: >> That sounds impressive. Someone correct me if I am wrong, but >> Jack requires X windows for just about everything. > >Not at all. Many of the clients do, but the server certainly doesn't. >Ecasound is a featureful client that doesn't either. Thank you. I am glad to be wrong about things like that. I started reading some about Jack and thought it was totally X. I guess you can say I don't know Jack. Martin McCormick

21 years, 6 months

Re: [linux-audio-user] Indexing the Read Pointer in /dev/dsp

by Martin McCormick

Malcolm Baldridge writes: >Funny, I've written a simple program (derived from the Jack "simple_client") >recent to do something similar. That sounds impressive. Someone correct me if I am wrong, but Jack requires X windows for just about everything. As a computer user who is blind, X is just not quite ready to productively use yet. My program uses the raw /dev/dsp PCM audio device. Without any IOCTL directives, this device reads and writes a 8 thousand sample-per-second stream of 8-bit audio. It is great for communications audio and no good for anything else.:-) My program idles by reading the samples and looking for any that are a given value above or below 0X80 which is the value one gets from the A/D converter under silence. If there is a swing through 0 to the other side of the cycle, a flag gets set. I make sure that several 0 crossings go by to avoid transient trips and then I set the VOX delay timer which tells the rest of the program to store samples in the output file. There is a buffer between the input and output so as to preserve the wave form and not chop it off. I burn roughly 25 megs for each hour of captured audio. I don't see anything wrong with making a new file for each recording, but I think there is a limit to the number of files one can have in a directory. That is the only pitfall I can see. There is one more bell to this program. If the sample read is 0 or 1 at one extreme or 0Xfe or 0Xff at the other, I send the bell character to warn that the audio is probably going in to clipping and to reduce the input level. The warning functions like a peak indicator. >What it does (for now, I'm sure I'll be adding more to it) is: > >1) Monitor the command-line specified input port for a sound above the >squelch level. > >2) Apply a configurable DC Bias adjustment [squelch comparison is performed >after this] > >3) Keep track of the peak samples processed to pass a "scaling value" to >normalise the sound data. [This is also post-DC Bias adjustment.] > >3a) I'm also looking at various dynamic compression [gain reduction] strategie

21 years, 6 months

Re: [linux-audio-user] Fwd: [Jamin] Re: soft clip: Achieving Gain, inconsequential overloads

by davidrclark＠earthlink.net

Hi Mark, > No, in my experience it doesn't favor louder always. I'm talking about historical trends, not individual experience, individual instruments, every single genre, etc. > had pictures of how volumes have grown over the years That's it! > I do not for a second think that this has all happened because the best > producers were doing a bad job 15-20 years ago. I agree. (Doesn't everybody?) > I'm just saying that I've not heard this argued in any other forum. That's why I brought it up. > Where do these come from, and why? See my earlier posting here (nonlinear processes in inner ear). I'm not claiming that everybody prefers this under all circumstances, just that there MAY be a general preference for denser spectra that drives this loudness increase. I also suggest that a preference for better dynamics occasionally reverses this trend. Other explanations (for the gradual increase in loudness) I've seen are not very satisfactory, esp. "Oh, it's just fashionable." I think it's related to the general trend towards richer orchestration which occurs in many genres.

21 years, 6 months

[linux-audio-user] Audacity/Windows/Plugins

by Mark Knecht

Hi, Sorry, but a very non-linux question. I wonder if anyone here can say anyting about how the Windows version of Audacity works? Is it stable? Does the VST enabler work? Is it stable? Does it only provide for audio suite/non-realtime operation on Audacity Audio, or does it allow Audacity to become a VSti platform of any type? Thanks in advance, Mark

21 years, 6 months

[linux-audio-user] [ANN] Linux Audio Conference #2 live streams, cams and chat available tomorrow

by Joern Nettingsmeier

hi everyone! for those who have not heard it yet, the second international Linux Audio Conference is taking place at the ZKM Karlsruhe/Germany from 29.4. to 2.5.2004. see http://www.zkm.de/lad/ for details. we have a number of very interesting presentations, all of which will be streamed out live, for the unlucky folks who can't be here in person. additionally, you will be able to download the presentation slides in advance should you wish to follow a lecture. there will be feedback channels on IRC, operated by folks who are in the lecture rooms. they will relay questions from you to the live audience. if all goes well, webcams will upload still images every 30 seconds to give you an idea of the ambience and of which slide is currently up. all important information on streaming relays, downloadable material, irc channels etc. will be dumped to http://linuxaudiodev.org/eventszkm2004.php3 . this page will be updated very frequently during the next days. the streams won't be up until tomorrow morning, but the chat rooms are already there. please forward this mail to any interested people. and no, we do not fear the slashdot effect :) enjoy, joern

21 years, 6 months

[linux-audio-user] Indexing the Read Pointer in /dev/dsp

by Martin McCormick

I have the beginnings of a program I have written that listens to the digital stream from /dev/dsp and records sound to a file when there is any sound. Communications types call this a VOX or Voice Operated relay with X being the abbreviation for relay. I want to also make a log of the time each recording started which is relatively easy to do especially if one uses the extensive time and date functions in UNIX. I think I can even store the stamps in the binary file with the audio. Retrieving those data in a meaningful manner, however, seems to be a problem. I want the playback program to display the time of the start of each recording as it begins to play. The /dev/dsp device is buffered so what really happens when you play a file is that the file pointer runs ahead of the actual byte being pushed through the sound card at any given time. The operating system blocks any more data being stuffed in to /dev/dsp, but the byte being pushed in may be 64 Kbytes ahead of what is playing right now. That's the problem. If I wrote a program to display the time a recording started, you would see that stamp some variable amount of time from instantly to maybe 8 seconds ahead of when the corresponding sound came out the speakers. I have been experimenting with methods of editing binary files and one has the same problem there in that when you reach the place you wanted to cut the virtual tape, the data which are flowing in to /dev/dsp are about 8 seconds past that point and it is hard to tell exactly where to edit. Is there any function that returns some offset or index value as to how much buffer is left? The trick to putting time stamps in with the audio should be to not ever allow a value of 0 to be stored from the A/D converter. When a new recording starts, store a NULL or 0 in the file followed by the 32-bit time and date value that UNIX systems store. Audio can follow after that. When playing back the file, look for the 0 and then use the next 4 bytes to recover the time and date. This would be a piece of cake if not for that variable buffer. The buffer is essential, however, for proper sound. I think that this buffer is actually the DMA channel at work so an indicator that it had run out or would soon run out would also be useful for those who want to synchronize sound with other activities. I have been playing with the VOX program for a couple of years and it works pretty well for recording radio transmissions but two transmissions could be anywhere from a quarter of a second apart to days apart. The program neatly cuts out the silence, but one has no idea when each recording actually started. In amateur radio, such information is useful when unusual skip or propagation conditions are present or in cases of malicious interference or malfunctions when one is trying to document when a particular event happened. For those of you used to recording high fidelity, the 8 seconds I refer to is with mono audio at 8,000 samples per second. Other sample rates and sample widths will certainly de pleat the buffer much faster. Martin McCormick WB5AGZ Stillwater, OK OSU Information Technology Division Network Operations Group

21 years, 6 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-user