Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] Please help: 16-channel recording w/ LAYLA, ALSA, JACK, ARDOUR

by Lance Blisters

I bought a Layla24 and Cardbus adaptor. Works beatifully with ALSA/JACK/ARDOUR up to 8 channels. However, the soundcard presents the 8 analog channels as device 0 and 8 digital channels as device 1. JACK will only open one device at a time. So in order to record and play back 16 channels with Ardour, I apparently need to create a virtual ALSA device combining the two LAYLA subdevices. Which brings me back to a place I always find myself when working with new sound gear - ALSA LIMBO, a dark claustrophobic space occupied only by unidentified .asoundrc fragments, paved with device anomolies, mined with disinformation bomblets, seen through the funhouse mirrors of fruitless google sessions. Cascades of similar plugin types of indeterminate direction, each encased in the next like a 12-step turducken, translated through an inconsistent mix of multiple (equivalent?) syntaxes, with the smallest deviation producing a cryptic failure. A breadcrumb trail of trials and errors spirals back further than I can see, and the only sounds I can hear over the queasy rumblings building in my stomach, is me repeating to myself that OF COURSE it is possible, I can't be the ONLY person to try to use all channels with JACK, and if I just dig through another 10 pages of search results i'll surely find a .asoundrc which solves the whole thing for me. And then I wake, throat hoarse, sticky with fever sweat, to apply ice to my forehead and plaster to the fresh hole in my wall. And I beg of you, someone, please, for the love of all that is holy, just give me the damn answer so i can get on with my life. And not a "use the multi plugin" answer, because THAT IS NO ANSWER, THAT IS ONLY A TAUNT. An actual, complete .asoundrc which has actually worked in practice, with .ctl, mmap, exclusivity, #channels, etc accounted for. The kind which saves me literal hours of very literal frustration. Thanks in advance, -geoff

19 years, 6 months

[linux-audio-dev] [ANN] GNU Denemo 0.75

by Adam Tee

GNU Denemo, a GTK+ front-end to GNU Lilypond Major changes include: Moved back to Plain C for future releases Reimplementation of keymaps so they are now XML based Midi import Lilypond Export Updates Reimplementation of rc files so that they are now XML Removal of Blank rest modes Crash Recovery Lots of memory leak fixes Help Manual now available Revised CSound export Revised Print functionality Blank notes are now displayed in Yellow to aid in viewing the score Keybindings for inserting Time Signatures, Key Signatures and Clefs Adam Maintainer GNU Denemo http://denemo.sourceforge.net

19 years, 6 months

[linux-audio-dev] [ot] How do GUI-libs notify the program of changes?

by Julien Claassen

Hi all! I know it's completely OT, but I think there maybe people here, who could help me. Problem is: I'm still on my libcui (character user interface) project and I wonder: I push a button, slide a slider... How does the UI notify the program of this change? How do Engine and UI communicate? Please anyone: HELP ME! Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide

19 years, 6 months

[linux-audio-dev] Measuring playback and capture quality.

by James Courtier-Dutton

Hi, Are there any linux tools out there that will sample the line in, and display a detailed spectrum scope of the detected sound? E.g. http://www.pcavtech.com/soundcards/ct462048/SNR_LB_FS.gif Eventually I wish to send a test signal from one sound card to another and compare the frequency response/noise etc. of the line input of the card. James

19 years, 6 months

[linux-audio-dev] Linux Audio Wiki on port 2500 no more

by Hans Fugal

The wiki that was at http://fugal.net:2500 is no longer there. It now has its own subdomain: http://lawiki.fugal.net I would be perfectly happy to entertain a more dedicated domain name, or more appropriate subdomain of an existing domain, if someone wants to foot the bill. If I can figure out how in a short amount of time, I'll put up a redirect at the old address. -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach

19 years, 6 months

[linux-audio-dev] [ANN] netjack-0.11rc5

by torbenh＠gmx.de

netjack-0.11rc5 Some pieces of Code which can deliver you the full jackd experience with multiple Computers. Links JackPorts via generic IP networks. The alsa_in and alsa_out client can connect jackd to an unrelated alsa Soundcard. And their algorithm has been improved. Also downsampling and bitrate reduction is included now, to make it work on low bitrate links. Tested over the Internet some times now, with moderate success. Also compiles on OSX... with-alsa=0 -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

19 years, 7 months

[linux-audio-dev] GPL Audio Hardware

by Richard Smith

The following post came across the the Open graphics list from one of the founders of the project looking for other things to do with the technology they have developed. I thought I'd post it here. Anyone interested should contact Tim. For anyone who dosen't know what OGD1 is see: http://kerneltrap.org/node/6262 I would think that with a little guidence from this list and tight integration with ardour and jack that a _really_ kicking pro audio setup could be produced. ============= From: Timothy Miller <theosib(a)gmail.com> To: ogml <open-graphics(a)duskglow.com> Since we're having a bit of a lull in the discussions on OGML, I thought I might start off a discussion about some ideas I've had that would benefit the Linux community as well as give OGP and Traversal a boost financially. The Open Graphics Project has gotten everyone involved a lot of attention. While it's still possible to get graphics cards supported by open source drivers, that supply is dwinding. At the rate things are going, we'll soon have no choices left. Politically and socially, the OGP is a great idea. Economically, however, it's entirely a different story. Because of the development and costs involved, low-end graphics is actually not such a great place to start. The attention we get because we want to do graphics is a major driving force, but there are much better ways to get our stream of funds started. One such idea that's been brought up before is ultra high end audio. The low-end is solved; it's called AC97 and is found in every PC chipset you can buy today. But imagine taking what would normally cost tens to hundreds of thousands of dollars in audio recording and production equipment and applying the open source model to it. Designing and producing a low-end commodity product is hard. But designing a niche audio product that sold competitively for thousands of dollars is relatively easy to pull off. To begin with, we now become much less cost-sensitive for parts, so the end product can be FPGA-based. That makes OGD1 an ideal development platform for a new audio device; in fact, it's major overkill. Once the new design is finished, we'd mass-produce a new board using a smaller FPGA and include all of the audio I/O hardware directly on-board. I know basically nothing about audio technology. But given what little I do know, here are some things that I think would be relatively easy to do with OGD1 and, what shall we call it, OAC1: - 60+ audio channels (pick your combination of in and out) - (A specialized card could handle lots more channels) - 24-bit precision per channel - Sample rates in the hundreds of kilohertz - Thousands of audio samples and MIDI instruments - Sample-based and algorithmically-generated sound-effects - Fourier analysis, band filters, mixing, and other sorts of math stuff that if I could name it, you'd be impressed - Noise-free signals (because we have experience with graphics) - Accelerated "3D sound" - Accelerated compression/decompression - Lots of other things Given hardware acceleration for most parts of audio processing, plus some excellent piece of open source sound studio software, I don't see why we couldn't produce a combination that is as good as or better than what you find in music recording studios, television stations, and every other place where you might find a need for this. Imagine how much money this could save musicians. The only thing we can't provide is the recording room with the proper accoustics. If a reduced version of the card sold for $1000, we'd have more than a few gamers and multimedia enthusiasts buying it for their 50-speaker surround-sound reality-immersion systems. Were such a project started, I would have to carefully tune my involvement. Since Howard, Andy, and I do not have a background in audio technology, it would probably be best for someone with appropriate experience to lead. But if the community can spec this product and help us design it (we can put into hardware any algorithm you specify), Traversal can produce it. The whole project, from start to finish, would be developed under GPL. This would be quite a major effort, due to the requirement for more than just drivers. Unlike the OGP, which started out of a corporation and has retained some of that flavor, the OAP would have to organize itself and push itself along. In my mind, the first major problem is getting the right people in the community together to develop the specs. So, what do you all think of this idea? Comments? Suggestions? Discussion! :) ================== -- Richard A. Smith

19 years, 7 months

[linux-audio-dev] liblo: restarting the server thread

by Dave Griffiths

Hi all, I'm trying to restart a liblo thread with the same port, but something seems to being kept hold of, as it fails (this may be intentional though). I have a test case here - am I being daft, or should this work: ---8<--- #include <stdio.h> #include <lo/lo.h> void handler(int num, const char *msg, const char *path) { printf("liblo server error %d\n",num); } int main() { printf("once\n"); lo_server_thread thr = lo_server_thread_new("4444",handler); lo_server_thread_start(thr); lo_server_thread_stop(thr); lo_server_thread_free(thr); printf("twice\n"); thr = lo_server_thread_new("4444",handler); } --->8--- I get the output: once twice liblo server error 9904 cheers, dave

19 years, 7 months

[linux-audio-dev] EMU 1212M

by Dmitry Baikov

On 4/6/06, James Courtier-Dutton <James(a)superbug.co.uk> wrote: > Creative have actually donated an X-Fi and an EMU1212M to me. > No datasheets, but at least having the hardware is a start. (Creative > pass me some datasheets for other cards though) > I have currently got as far as horrible noises coming from the EMU1212M. So, does it mean that soon we'll have linux drivers for Emu 1212, 1616 and 1818? Regards, Dmitry.

19 years, 7 months

[linux-audio-dev] fast linear resampling on ARM - suggestions?

by Tobias Scharnberg

Hello List, I'm trying to find a library or code-snippet in order to do audio resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to resample the data in realtime - resampling a buffer of data, not a soundfile. The quality doesn't need to be good so I guess the best solution might be linear audio resampling. The device to do the resampling on is an ARM CM-X255 running at 400MHz. I tried out libsamplerate so far but when I tested it with the soundfile conversion test program it needed 3,5 secs to sample from 8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me. Is there something faster that can do the job? Any suggestions are highly welcome Greetings, Tobias

19 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