Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7501 discussions

by Patrick Shirkey

On 11/29/2009 03:36 PM, Ken Restivo wrote: > On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote: > >> Nick Copeland: >> >>> Adrian Knoth: >>> >>>> I'm also somewhat interested in the network part, I feel IPv6 could help >>>> a lot. It supports autoconfiguration and it has decent multicast >>>> support, so it would be possible to broadcast/multicast the streams on >>>> the net (LAN). This could be useful if you want to access the stream at >>>> a mixing console for a life setup and simultaneously record it on a >>>> computer. >>>> >>> Put another way, it would be far more compatible if this were done over >>> an IP stream rather than any native ethernet stream, not least it could use >>> any ethernet driver that linux supports rather than a small subset of them. >>> >> Ack, a standard ip-stream is a sensible first choise. >> >> >>> Perhaps the project needs to be specified with regards to its goals? >>> >> ... >> >> My goals is "just" to extend another project (industrial i/o). >> What would your goals be ? >> >> Shall we decide on a single mailing list ? >> >> > IIRC the motivation for this was: > > 1) Firewire is going away on laptops > 2) USB 2.0 is proprietary and non-standard > 3) Because of (1) and (2), Linux Audio users will soon be left without any way to do multichannel recording on laptops. > > The original thread converged on a goal pretty quickly: an inexpensive, multi-channel audio interface which is open hardware and software, and uses Gig Ethernet as its physical connection method. > > So, if I were going to put the goal simply: I'd like a Focusrite Saffire (or equivalent) that runs over Ethernet, please :-) Price-wise, it'd be nice if it cost the same or less than equivalent USB 2.0 product. Latency-wise, comparable with USB 2.0. > > In terms of how many I/O, I think that was still being calculated and experimentation was going to be required. Obviously options for 4, 8, or 16 I/O would be nice. > > Did anyone have a good reason for not including support for a usb-1.0/2.0/3.0 interface seeing as we can write the driver ourselves and adhere to the standard? Most chipsets these days have support for both port types. It would be very useful if the schematic provided tracks for both ootb. BTW, I will be able to contribute development funds towards this project if required once we have a BoM. Cheers. Patrick Shirkey Boost Hardware Ltd

15 years, 6 months

installing stk

by james morris

I've built the Synthesis ToolKit and want to install it, but make install Is there an easy way? I can't install the package for my distro because I've got zero audio packages installed - all built from sauce. James.

15 years, 6 months

Mini-ANN: linux-si470x (0.1)

by Mario Lang

Hi. I recently got myself an ADS InstantFM USB radio tuner card. This is exactly what I always wanted, a tuner with a built-in USB soundcard, so no need for loopback cables or anything. It also happens to have RDS, which can be programmed from user-space since 2.6.32. So to celebrate the release of 2.6.32, I wrote a small command-line tool (basically for myself) to work with that card. The tool impelemnts the following features as of now: * Decode most important RDS messages (program name, radiotext) * Allow for playback via JACK or ALSA * Allow to record to an OGG file The recording and playback features are currently implemented using helper tools: arecord, aplay, oggenc and alsa_in. Here is the URL: http://delysid.org/linux-si470x.tar.xz Future ideas: * Write the capture and playback code in C to allow for: * Stop during playback, buffering the audio for later playback. * Record during playback like time-machine: Buffer a defined amount of audio from the past, and use it when the user requests recording. * Maybe integrate libSoundTouch for realtime pitch shifting and time compression (if playback is behind realtime). If you have such a card (luck you!) give the RDS decoding a whirl. Patches of course always welcome. P.S.: A very good existing tool for realtime playback of audio for this tuner card is mplayer: mplayer -radio adevice=hw=2.0:arate=96000 -rawaudio rate=96000 radio://91.2/capture If all you need is this, by all means, go with mplayer. linux-si470x is more geared towards integrating RDS decoding into a command-line tool for operating these tuner cards. P.S.2: Version 0.1 of linux-si470x is now 2 days old. So this is indeed a very early pre-release. But since I didn't find anything equivalent, I thought I'd release it anyway in case someone can make early use of it. -- CYa, ⡍⠁⠗⠊⠕

15 years, 6 months

Re: [LAD] [LAU] Update of jconv

by fons＠kokkinizita.net

On Tue, Dec 01, 2009 at 10:57:58PM -0800, Ken Restivo wrote: > Really? A huge number of tracks I've published, were > mixed in Ardour freewheeling mode, using jconv for > reverb. Worked fine for me, at least with the older versions. You've been lucky :-) This will probably still work with the new version (maybe even 'better' as the result of a bug fix), but it's not by design. In theory zita-convolver could be modified quite easily to work correclty in freewheeling even on MP systems. The complicated part is switching between normal mode and freewheeling 'on the fly' - I've not worked out how to do that correctly. But as said, on a single processor system it will work. What is happening is this: zita convolver uses some processing threads that effectively run with a period that is a power-of-2 multiple of Jack's basic period. They run on RT priorities just below the one of Jack's process thread (-1 for for each doubling of the period). The output of these threads must be ready when their next period starts. Zita-convolver checks this condition and will report errors if these threads are too slow, but it will not wait for them - you're not supposed to wait in Jack's callback, and if your system does support the CPU load for the given configuration they will be ready, even with some safety margin. When freewheeling, Jack's main process thread will be non-RT, while these extra threads remain at RT. So they will pre-empts Jack's thread and will appear to be always ready on time. Except when you have 2 CPUs: then Jack's thread will be allowed to continue even if some of the others have not yet completed their work. The issue is complicated a bit more by the way these threads are scheduled, it is *not* (viem with monospaced font) 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 4 4 4 8 8 but 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 4 4 4 8 i.e. in each period at most one one them is at its longer period boundary. Ciao, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?

15 years, 7 months

arm dev board running linux-rt patch

by Nathanael Anderson

Is anyone on the list familiar with running jack and and a rt kernel on an arm based board (beagle board or similar). I'd like to make my own embedded guitar fx module using rackarrack and ldaspa plugins controlled via midi. Without the hastle of always having to bring my laptop with me. -wirelessdreamer

15 years, 7 months

L2Ork story on Slashdot brings up the age-old question whether Linux is ready for serious audio use

by Ivica Ico Bukvic

Dear fellow FOSS enthusiasts, This is probably already old news according to Internet standards but as it turns out we spent a good time this evening in class not knowing that we got slashdotted. For those interested in belatedly joining the discussion, please visit: http://entertainment.slashdot.org/story/09/12/03/2018253/Introducing-L2Ork-W orlds-First-Linux-Laptop-Orchestra Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio 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/

15 years, 7 months

[LAA] [ANN] guitarix-0.05.3-1 quick release

by hermann

This is a quick guitarix update to cover the new release of jconvolver eg. jconv guitarix is a simple Linux Rock Guitar amplifier and is designed to achieve nice thrash/metal/rock/blues guitar sounds. Guitarix uses the Jack Audio Connection Kit as its audio backend and brings in one input and two output ports to the jack graph. To cover the renaming of jconv to jconvolver, guitarix-0.05.3-1 looks now first for jconvolver, if it isn't installed, it looks for jconv. Also a patch from Michal Seben (OpenSuse) is added to cover a build fail at openSUSE:Factory. Thanks Michal. :-) Additional, there is a (rt) 2 Channel delay chooser for the output to jconv, and the Chorus effect work in Stereo now. have fun ________________________________________________________________________ Project page with screenshots: http://guitarix.sourceforge.net/ download: http://sourceforge.net/projects/guitarix/ ________________________________________________________________________ For capture, guitarix uses the external application 'jack_capture' (version >= 0.9.30) written by Kjetil S. Matheussen. If you don't have it installed, you can look here: http://old.notam02.no/arkiv/src/?M=D For extra Impulse Responses, guitarix uses the convolution application 'jconv' created by Fons Adriaensen. If you don't have it installed, you can look here: http://www.kokkinizita.net/linuxaudio/index.html I(hermann) use faust to build the prototype and will say thanks to : Julius Smith http://ccrma.stanford.edu/realsimple/faust/ : Albert Graef http://q-lang.sourceforge.net/examples.html#Faust : Yann Orlary http://faust.grame.fr/ guitarix is licensed under the GPL. regards Hermann Meyer & James Warden ------------------------------------------

15 years, 7 months

Re: [LAD] [LAU] [LAA] [ANN] guitarix-0.05.2-1 released

by hermann

Am Donnerstag, den 03.12.2009, 14:04 +0100 schrieb Hartmut Noack: > hermann schrieb: > > I'm happy to announce a new guitarix release > > > > guitarix is a simple Linux Rock Guitar amplifier and is designed > > to achieve nice thrash/metal/rock/blues guitar sounds. > > Guitarix uses the Jack Audio Connection Kit as its audio backend > > and brings in one input and two output ports to the jack graph. > > Nice one, thatnk you :-) > > I love to see this project grow - a simple works-right out of the box > amp for Linux is extremely welcome. > BTW: do you think, you could turn it into a LV2-plugin? > > Some people could consider then to boost stability and performance of > their Linux audio system by dropping VST via WINE.... > Thanks Hartmut, good to hear that you like it. :-) Make guitarix a LV2-plugin, is at least a question of development power. We would love that to, but, Guitarix is a young small project, we are only 2 developers, and we both have at first other tasks in mind witch we wone implement. In fact, it will be easy for a bit experienced LV2 developer to port the "control chain" of guitarix to LV2. Our source is spiked with comments witch make it easy to jump in and grep the needed source. Guitarix is a open Project, open for developers who wone join the project. gruß hermann

15 years, 7 months

jack ringbuffer question

by lieven moors

Hi everyone, I just started writing my first c++ program, and I'm kind of stuck with something I cannot understand. After a few days of trying to figure this out, I decided to ask for more professional help. I'm working on a kind of arpeggiator for linux (which I intend to release under GPL). The program uses a text file, in which the user can specify a number of arpeggios. Each arpeggio is loaded into an object called 'Arp', and for every Arp I make a jack port, and a ringbuffer. (the port and ringbuffer are stored in an object called Arp_jack) A seperate thread, watches the text file for modifications (using inotify), and every time the file is changed, the file is loaded afresh, and the new Arps are put in the respective ringbuffers. The ringbuffers have a size of two Arps, and the idea is that when a new Arp arrives, the old one is discarded. If there is only one Arp in the buffer, the program keeps on reading the same one. This code is part of the inotify thread: while (i < len) { struct inotify_event *event; event = (struct inotify_event *) &buf[i]; if ( event->wd == wd ) { vector<Arp>* arps = new vector<Arp> ; read_load_file( arps ) ; for( uint x = 0; x < arps->size(); x++ ) { const char* arp_char = reinterpret_cast<const char*>(&(*arps)[x]); jack_ringbuffer_write( (*ARPS_JACK)[x].rb, arp_char, sizeof( Arp )); } //delete arps ; } The next code fragment comes from the process callback. As you can see, I'm using jack_ringbuffer_get_read_vector to read the raw data, and I advance the the read pointer when a new arp is available: if( (jack_ringbuffer_read_space( (*arps_jack)[i].rb ) ) == (sizeof( Arp ) * 2) ) { jack_ringbuffer_read_advance( (*arps_jack)[i].rb, sizeof(Arp) ) ; } if( (jack_ringbuffer_read_space( (*arps_jack)[i].rb ) ) == sizeof( Arp ) ) { jack_ringbuffer_data_t data[2] ; jack_ringbuffer_get_read_vector( (*arps_jack)[i].rb, data ) ; if ( data[0].len > 0 ) { arp = reinterpret_cast<Arp*>( data[0].buf ) ; steps = &arp->steps ; scale = &arp->scale ; } else if( data[1].len > 0) { cout << "data in second part of ringbuffer, this should not happen!" << endl ; } .... Now to the question. The code works as I expect, as long as I don't delete the vector of arps in the inotify thread (see the commented line). When I do delete the vector, the program segfaults. (and also when I allocate the vector on the stack, and it gets cleaned up automatically) I thought that writing to the ringbuffer with jack_ringbuffer_write copies the data to the ringbuffer, so I don't understand why this should have an influence. Is it a problem that I put the ringbuffer in an object which is accessed by two different threads without using a mutex? I've tried using a mutex,but I still had the segmentation fault. Any help with this would be really appreciated. Thanks for your help, Lieven

15 years, 7 months

HDMI Audio

by Jens M Andreasen

Seing that HDMI interfaces are getting implemented everywhere - a bit like S/PDIF before that, but now with 8 uncompressed channels @192k and 24 bits - does anybody know what kind frame sizes are used and what the implications would be for realtime audio-processing? (.. as opposed to buffering up and re-playing pre-recorded material from a DVD.) Not that I am aware of anything reasonable to connect to at the receiving end yet - but who knows, that might change.

15 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