From smoerk at gmail.com Tue Nov 1 05:51:57 2005 From: smoerk at gmail.com (oliver oli) Date: Tue Nov 1 05:53:00 2005 Subject: [linux-audio-dev] how to mix various s/pdif sources? Message-ID: <436748CD.1010909@gmail.com> hello, i would like to mix several (up to six) s/pdif sources in the digital domain. the problem is, that every source has its own clock and possibly different sample rate. is there any software that can open several non-synchronized sound cards at the same time? iirc there was a patch for jackd for drift compensation, but i cannot find it in anymore and i'm also not sure if that would help. Minidisc 44100.17 ==S/PDIF==> Sound Card 1 ==> Audio App \ \ Laptop 48000.23 ==S/PDIF==> Sound Card 2 ==> Audio App --> D/A (96khz) / DAT 48000.09 ==S/PDIF==> Sound Card 3 ==> Audio App / From beachnase at web.de Tue Nov 1 07:13:11 2005 From: beachnase at web.de (Frank Neumann) Date: Tue Nov 1 07:14:09 2005 Subject: [linux-audio-dev] Linux Audio Conference #4 (LAC2006): Call for Papers/Music etc Message-ID: Dear all, this should have come one month earlier, but such is life..anyway: This mail is to announce the calls for papers/music/etc for the 4th International Linux Audio Conference (LAC2006). See http://lac.zkm.de/2006 for more information. LAC2006 will take place 27-30 April 2006, again at the ZKM | Institute for Music and Acoustics in Karlsruhe, Germany. We have tried to simplify things a little bit since LAC2005. There are calls for papers, demos, workshops, and music. The former category BOFS has been merged with the workshops. There is no call for project notes anymore; instead we have the call for demos now. The call for posters has been discarded. We hope everybody agrees that this is an improvement and we are looking forward to many interesting submissions for LAC2006! Please feel free to forward this email to anybody who is interested. Thank you for reading! Frank Neumann and Goetz Dipper *********************************************************************** Call for Papers We invite submissions of papers addressing all areas of audio processing based on Linux and open source software. Papers can focus on technical, artistic or scientific issues and can target developers or users. This includes (but is not limited to) the following categories: * Computer Music * Music Production * Instruments * Drivers and Sound Architecture * Audio Distributions * Generic (Usage, Documentation etc.) The conference is held in english, so all papers and presentations will have to be done in english, too. Length of a paper is 4-8 pages. Papers have to include an abstract (50-100 words). The abstract will be published separately on the conference website once the paper has been accepted. Also, papers should include up to 5 keywords. In general talks should take 20-30 minutes followed by 5 minutes discussion. Please notify us if you need a special technical setup. The technical standard setup will be: * microphone (head set) * projector with XVGA input (resolution 1024x768) * stereo speaker setup with mini jack input If you are not able to bring your laptop along with you, please notify us in advance. How to submit * File format is PDF, formatted for A4 paper. Make use of the templates for paper formatting available at: http://lac.zkm.de/2006/downloads.shtml * See our check list to ensure that you do not forget to enclose all necessary information: http://lac.zkm.de/2006/submission_instructions.shtml * Send your paper and all necessary information by 8 Jan 2006 via email to this address: lac2006 at zkm dot de * You will be notified by 19 Feb 2006 whether your paper has been accepted. The reviewers may ask you to modify your paper in order to be accepted. The deadline for the final version is March 12, 2006. Important Dates 08 Jan 2006: Paper submission deadline 19 Feb 2006: Notification of acceptance 12 Mar 2006: Final version deadline 27 - 30 Apr 2006: Conference *********************************************************************** Call for Demos This is the only new category of LAC2006. You do not need to write a whole paper, but rather a short abstract only (50-100 words). This category is mainly thought for software demos. Be aware though that in case of too many submissions papers take priority over demos. See section "Call for Papers" for info on the duration of talks and the technical setup. How to submit * See our check list to ensure that you do not forget to enclose all necessary information: http://lac.zkm.de/2006/submission_instructions.shtml * Send your abstract and all necessary information by 8 Jan 2006 via email to this address: lac2006 at zkm dot de * You will be notified by 19 Feb 2006 whether your submission has been accepted. Deadline for submissions is 08 Jan 2006. *********************************************************************** Call for Workshops With respect to their content workshops do not differ from talks: Workshops can have technical focus as well as artistic or scientific focus. Workshops can be targeted to developers as well as users. See section "Call for Papers" for more info on this. The shape of the workshop is completely up to you. E.g. it can be tutorial-like ("how to write an ALSA driver/ a jack application/ a LADSPA plugin/ etc.") or it can be BOFS-like (e.g. a meeting of like-minded users and/or developers to exchange experience and knowledge about a specific topic), or it can be anything in between. Workshops can take place in seminar rooms or in a public space like the ZKM cafe. Depending on the location, attendance might be limited to ca 10 people. There is no deadline for submitting workshops. However, we strongly encourage you to submit early. It will be more likely to get a free slot and it will be easier for attendants to know about the workshop if it is published on the conference website. If you expect the attendants to prepare their laptops for your workshop (e.g. by installing some software) or if there are other requirements, please note so in your abstract. How to submit * See our check list to ensure that you do not forget to enclose all necessary information. http://lac.zkm.de/2006/submission_instructions.shtml * Send an abstract (ca. 50-100 words) and all necessary information via email to this address: lac2006 at zkm dot de * The abstract will be published on the conference website once the workshop has been accepted (not before 27 Feb 2006 though). *********************************************************************** Call for Music There will be some concerts during the conference. We are looking for music that has been produced completely or mostly under Linux and/or with open source software: * "Serious" compositions, to be played in a concert-like context * Electronica, Chill-Out, Ambient etc., to be played in a less formal, "party-like" context. Additionally you are welcome to give a talk about your piece. We encourage you especially to show how you made the piece using open source software. Please send a short abstract (ca. 50-100 words) if you want to give a talk. If you want to participate, send your composition(s) to this address: LAC2006 - Call for Music ZKM | Institut fuer Musik und Akustik Lorenzstr. 19 D-76135 Karlsruhe Germany Make use of one of the following media formats: * Media: Audio-CD, DVD or CD-ROM * File formats: aiff or wav * Channels: mono, stereo or multi-channel * Samplerate: 44.1, 48, or 96 kHz * Resolution: 16 or 24 bit Include the following items with your submission (in English): * Requirements (speaker setup, instruments etc.) * A filled-out and signed printout of the form available here: http://lac.zkm.de/2006/downloads.shtml For the printed programme and to be published online and on the conference CD, in continuous text (no table or list please): * A short commentary on the composition(s) (each ca. 150 words) * A short Curriculum Vitae (ca. 100 words) Deadline for submissions is 08 Jan 2006. A jury will select the compositions that will be performed/played. Furthermore, the jury will give out three prices to participants to contribute to their travel expenses. Besides artistic criteria and technical reasons, these criteria apply for the selection: * Tape pieces or pieces which are performed by the composer herself will generally have more chances to get included. * If we get more pieces than we can include in the programme, composers who are attending the conference are preferred. Terms and conditions for participation can be found in the form mentioned above. This form includes among other things: * I will receive no fees whether my composition is played or not. * GEMA fees (in case of performance) will be paid by ZKM. * The material I send to ZKM will not be returned. Additionally to this Call for Music, there will be an open stage called "Plug & Chill - The Linux Jam Night" at Saturday night (29 Apr 2006), where attendents of the conference are invited to perform their pieces in a less "official" context. There is no deadline for this, so people can decide during the conference if they want to participate. However if you already know that you want to participate do not hesitate to inform us. Send us an email to lac2006 at zkm dot de and include a description of your equipment and a short characterisation of your music (keywords only). During the conference it is possible to register at the info desk. Note that there is a time limit for "Plug & Chill". If we have received too many registrations already you might not get a slot. Contributions to "Plug & Chill" should not exceed 10 min. There will be a room at ZKM where people can meet during the conference and rehearse for "Plug & Chill". *********************************************************************** From kouhia at nic.funet.fi Tue Nov 1 14:24:58 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Tue Nov 1 14:25:03 2005 Subject: [linux-audio-dev] Re: Radio receiver. Message-ID: How about a software which can combine the outputs coming from two receivers tuned to the same station? Typically with short-wave receivers (tuned to distant radio station) there are problems. With two or more receivers (perhaps located at different cities and connected via Internet!) the problems can be reduced and the station signal restored. This kind of signal restoration must be known already in other contexts. Strange, I recently read a recent (2000+) paper. They praised (like having a patent on them) two innovations: (1) an audio editor could handle non-audio signals, e.g., RF signal, ultrasound, etc., and (2) the above kind of receiver combination. The innovation (1) was discussed at 1997/98 here or elsewhere, and I invented the innovation (2) at 1993. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From dmills at spamblock.demon.co.uk Tue Nov 1 15:11:59 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Tue Nov 1 15:12:15 2005 Subject: [linux-audio-dev] Re: Radio receiver. In-Reply-To: References: Message-ID: <200511012011.59697.dmills@spamblock.demon.co.uk> On Tuesday 01 November 2005 19:24, Juhana Sadeharju wrote: Hate to burst your bubble.... > was discussed at 1997/98 here or elsewhere, and I invented the > innovation (2) at 1993. Google for diversity reception, I think you will be surprised by just how far back this trick goes. I know people were doing it with FM radio mics in the eighties and probably well before then. The radio astronomers are of course the world experts at this, see projects like the 'very long baseline array' for a project using software to combine the outputs of **LOTS** of geographically separated radios. You need really good clocks to pull this off well. Regards, Dan. From fons.adriaensen at skynet.be Tue Nov 1 15:41:14 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Tue Nov 1 15:50:42 2005 Subject: [linux-audio-dev] Re: Radio receiver. In-Reply-To: References: Message-ID: <20051101204113.GA5057@linux-1> On Tue, Nov 01, 2005 at 09:24:58PM +0200, Juhana Sadeharju wrote: > How about a software which can combine the outputs coming from > two receivers tuned to the same station? > ... > Strange, I recently read a recent (2000+) paper. They praised > (like having a patent on them) two innovations: (1) an audio editor > could handle non-audio signals, e.g., RF signal, ultrasound, etc., > and (2) the above kind of receiver combination. The innovation (1) > was discussed at 1997/98 here or elsewhere, and I invented the > innovation (2) at 1993. It's much older than your 1993 invention. It's called 'diversity reception' and has been used for at least 50 years. -- FA From letz at grame.fr Wed Nov 2 05:05:34 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Wed Nov 2 05:06:24 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051031011835.GC5085@linux-1> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> Message-ID: Le 31 oct. 05 ? 02:18, fons adriaensen a ?crit : > On Mon, Oct 31, 2005 at 01:44:45AM +0100, Florian Schmidt wrote: > > >> Btw: i just discovered that pthread mutexes and condvars can have a >> "process shared" flag which makes it possiblo to synchronize threads >> across processes as it seems. Could be useful for jack, no? >> >> pthread_condvar_setpshared() >> pthread_mutexattr_setpshared() >> >> Or do i misread that manpage? >> > > Manpages sometimes document things that are not (yet) implemented. > Maybe it is now (in 2.6) but I'm quite sure it was not in 2.4. > > For jack, all you need is the futexes (which are system wide, > I tested that). I'm pretty sure that all of jack can be written > without requiring a mutex shared with the client threads. > > A big advantage of using futexes in shared memory would be > that they don't have to be recreated each time the callback > order changes - unlike the pipes, they are not bound to a > process, and to modify the 'trigger chain' all you need is > to change some pointers. > In Jackdmp we have tested 2 system for inter-process synchronization: fifo (the way it was done in regular jackd) and POSIX named semaphore (which are built on top of futex on recent system version) In both cases, each already running client get access to the synchronization primitive (fifo or POSIX named sema) defined by a new coming client. The synchronization primitive is "opened" once when a new client appears and is "closed" when the client quits. The synchronization primitive that has to be signaled then depends of the graph topology. > But ISTR that OSX only has named shared futexes (i.e. accessed > via a file descriptor), and then of course the problem remains. On OSX, on can use Mach semaphore (internal and non portable...) POSIX named semaphore or fifo. Stephane From fons.adriaensen at alcatel.be Wed Nov 2 05:29:11 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Wed Nov 2 05:32:34 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> Message-ID: <20051102102911.GA10945@bth05w.ABSp.alcatel.be> On Wed, Nov 02, 2005 at 11:05:34AM +0100, St?phane Letz wrote: > > Le 31 oct. 05 à 02:18, fons adriaensen a écrit : > > >A big advantage of using futexes in shared memory would be > >that they don't have to be recreated each time the callback > >order changes - unlike the pipes, they are not bound to a > >process, and to modify the 'trigger chain' all you need is > >to change some pointers. > > > > In Jackdmp we have tested 2 system for inter-process synchronization: > fifo (the way it was done in regular jackd) and POSIX named semaphore > (which are built on top of futex on recent system version) > > In both cases, each already running client get access to the > synchronization primitive (fifo or POSIX named sema) defined by a new > coming client. The synchronization primitive is "opened" once when a > new client appears and is "closed" when the client quits. The > synchronization primitive that has to be signaled then depends of the > graph topology. I must be missing something essential here. Access to named things that have to be opened is normally by a file descriptor, and file descriptors are bound a process. How then can you give *all* clients access to the named pipe or sema created for a new client ? -- FA From mista.tapas at gmx.net Wed Nov 2 05:48:58 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Wed Nov 2 05:49:03 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> Message-ID: <20051102114858.013e1840@mango.fruits.de> On Wed, 2 Nov 2005 11:05:34 +0100 St?phane Letz wrote: > In Jackdmp we have tested 2 system for inter-process synchronization: > fifo (the way it was done in regular jackd) and POSIX named semaphore > (which are built on top of futex on recent system version) > > In both cases, each already running client get access to the > synchronization primitive (fifo or POSIX named sema) defined by a new > coming client. The synchronization primitive is "opened" once when a > new client appears and is "closed" when the client quits. The > synchronization primitive that has to be signaled then depends of the > graph topology. > > > But ISTR that OSX only has named shared futexes (i.e. accessed > > via a file descriptor), and then of course the problem remains. > > On OSX, on can use Mach semaphore (internal and non portable...) > POSIX named semaphore or fifo. > > Stephane What results did you get? Did the semaphore perform better/worse than the fifo? What about pthread condition variables with pshared flag set? I read somewhere it should be implemented by now (at least on 2.6 systems). Flo -- Palimm Palimm! http://tapas.affenbande.org From letz at grame.fr Wed Nov 2 05:56:59 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Wed Nov 2 05:57:49 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051102102911.GA10945@bth05w.ABSp.alcatel.be> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102102911.GA10945@bth05w.ABSp.alcatel.be> Message-ID: Le 2 nov. 05 ? 11:29, Alfons Adriaensen a ?crit : > On Wed, Nov 02, 2005 at 11:05:34AM +0100, St?phane Letz wrote: >> >> Le 31 oct. 05 ? 02:18, fons adriaensen a ?crit : >> >>> A big advantage of using futexes in shared memory would be >>> that they don't have to be recreated each time the callback >>> order changes - unlike the pipes, they are not bound to a >>> process, and to modify the 'trigger chain' all you need is >>> to change some pointers. >>> >> >> In Jackdmp we have tested 2 system for inter-process synchronization: >> fifo (the way it was done in regular jackd) and POSIX named semaphore >> (which are built on top of futex on recent system version) >> >> In both cases, each already running client get access to the >> synchronization primitive (fifo or POSIX named sema) defined by a new >> coming client. The synchronization primitive is "opened" once when a >> new client appears and is "closed" when the client quits. The >> synchronization primitive that has to be signaled then depends of the >> graph topology. > > I must be missing something essential here. Access to named things > that have to be opened is normally by a file descriptor, and file > descriptors are bound a process. How then can you give *all* clients > access to the named pipe or sema created for a new client ? > > - The synchronization primitive is actually created by the server when a new client register. Then a client identifier (built using the actual client name) is transfered to all running clients that will define/access the synchronization primitive in their own process. Stephane From fons.adriaensen at alcatel.be Wed Nov 2 06:11:41 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Wed Nov 2 06:11:45 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: References: <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102102911.GA10945@bth05w.ABSp.alcatel.be> Message-ID: <20051102111141.GD10945@bth05w.ABSp.alcatel.be> On Wed, Nov 02, 2005 at 11:56:59AM +0100, St?phane Letz wrote: > >I must be missing something essential here. Access to named things > >that have to be opened is normally by a file descriptor, and file > >descriptors are bound a process. How then can you give *all* clients > >access to the named pipe or sema created for a new client ? > > The synchronization primitive is actually created by the server when > a new client register. Then a client identifier (built using the > actual client name) is transfered to all running clients that will > define/access the synchronization primitive in their own process. But in order to define/access it in their own process, they have to open() it, i.e. perfrom a call to the filesystem, or am I wrong here ? This means that changing the graph order can never be a RT operation, unless clients get a second, non-RT thread to perform this call from. (or do it in their own non-RT user code, but that would be horrible). -- FA From conrad.berhoerster at gmx.de Wed Nov 2 06:21:21 2005 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Wed Nov 2 06:25:05 2005 Subject: [linux-audio-dev] jack and setuid Message-ID: <200511021221.22850.conrad.berhoerster@gmx.de> Hello Lists, I don't know, where ich can fix my little problem. Maybe i 've missed some explanations and/or haven't read my mails good enough. anyway, i try to install a linuxbox for audio on slackware i have installed slackware and patching the kernel 2.6.14 vanilla with patch-2.6.14-rt2. Then i installed the set_rtlimits1.1.0 software, because Slackware has no PAM. First. this must be all for audio in realtime , is this right?? then i have to set the setuid. aus root i have done bash-3.00$ su Password: bash-3.00# chmod ugo+s /usr/local/bin/jackd bash-3.00# exit bash-3.00$ ls -la /usr/local/bin/jackd -rwsr-sr-x 1 root root 206476 2005-11-01 15:23 /usr/local/bin/jackd bash-3.00$ whoami soundroom bash-3.00$ jackd -dalsa& [1] 3202 bash-3.00$ jackd 0.100.0 Copyright 2001-2005 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. loading driver .. creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit control device hw:0 configuring for 48000Hz, period = 1024 frames, buffer = 2 periods nperiods = 2 for capture nperiods = 2 for playback bash-3.00$ ps -aux [..] root 3202 0.0 0.4 10472 2380 pts/1 S 12:03 0:00 jackd -dalsa root 3203 0.0 0.4 10472 2380 pts/1 R 12:03 0:00 jackd -dalsa root 3204 0.0 0.4 10472 2380 pts/1 S 12:03 0:00 jackd -dalsa root 3205 0.0 0.4 10472 2380 pts/1 S 12:03 0:00 jackd -dalsa root 3206 0.2 0.4 10472 2380 pts/1 S 12:03 0:00 jackd -dalsa [..] bash-3.00$ jack_lsp JACK server not running why i can't use jack an normal user? what have i missed? why there are 5 processes of jack? is this a secure way? do i need every application as suid? From letz at grame.fr Wed Nov 2 06:26:20 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Wed Nov 2 06:27:10 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051102114858.013e1840@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102114858.013e1840@mango.fruits.de> Message-ID: Le 2 nov. 05 ? 11:48, Florian Schmidt a ?crit : > On Wed, 2 Nov 2005 11:05:34 +0100 > St?phane Letz wrote: > >> In Jackdmp we have tested 2 system for inter-process synchronization: >> fifo (the way it was done in regular jackd) and POSIX named semaphore >> (which are built on top of futex on recent system version) >> >> In both cases, each already running client get access to the >> synchronization primitive (fifo or POSIX named sema) defined by a new >> coming client. The synchronization primitive is "opened" once when a >> new client appears and is "closed" when the client quits. The >> synchronization primitive that has to be signaled then depends of the >> graph topology. >> >>> But ISTR that OSX only has named shared futexes (i.e. accessed >>> via a file descriptor), and then of course the problem remains. >> >> On OSX, on can use Mach semaphore (internal and non portable...) >> POSIX named semaphore or fifo. >> >> Stephane > > What results did you get? Did the semaphore perform better/worse than > the fifo? What about pthread condition variables with pshared flag > set? > I read somewhere it should be implemented by now (at least on 2.6 > systems). > > Flo > On Linux, the semaphore is a bit faster than fifo. On OSX we have in speed order : Mach semaphore, POSIX semaphore, fifo I've not tested the pthread condition variables with pshared flag set, it should probably work also on recent 2.6 kernel. But i guess all primitives are built on top of futex APi on the end. Stephane From letz at grame.fr Wed Nov 2 06:38:49 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Wed Nov 2 06:39:37 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051102111141.GD10945@bth05w.ABSp.alcatel.be> References: <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102102911.GA10945@bth05w.ABSp.alcatel.be> <20051102111141.GD10945@bth05w.ABSp.alcatel.be> Message-ID: <277C5202-9A57-4D38-9F71-50F90DD7BCC6@grame.fr> Le 2 nov. 05 ? 12:11, Alfons Adriaensen a ?crit : > On Wed, Nov 02, 2005 at 11:56:59AM +0100, St?phane Letz wrote: > >>> I must be missing something essential here. Access to named things >>> that have to be opened is normally by a file descriptor, and file >>> descriptors are bound a process. How then can you give *all* clients >>> access to the named pipe or sema created for a new client ? >> >> The synchronization primitive is actually created by the server when >> a new client register. Then a client identifier (built using the >> actual client name) is transfered to all running clients that will >> define/access the synchronization primitive in their own process. > > But in order to define/access it in their own process, they have to > open() > it, i.e. perfrom a call to the filesystem, or am I wrong here ? Yes, clients use open *once* when the new client opens. This is done in a non RT thread (what we call the "notification" thread that also handle all non RT events like callback...) > This means that changing the graph order can never be a RT operation, > unless clients get a second, non-RT thread to perform this call from. There is no need to open the synchronization primitive at graph re- order time. Since a given client can access all synchronization primitive, when the graph order changes, then the client will possibly have to notify another primitive. Stephane From jens.andreasen at chello.se Wed Nov 2 06:56:22 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed Nov 2 06:56:31 2005 Subject: [linux-audio-dev] jack and setuid In-Reply-To: <200511021221.22850.conrad.berhoerster@gmx.de> References: <200511021221.22850.conrad.berhoerster@gmx.de> Message-ID: <1130932582.18649.16.camel@c80-216-125-193.cm-upc.chello.se> On Wed, 2005-11-02 at 12:21 +0100, conrad berh?rster wrote: > > bash-3.00$ jack_lsp > JACK server not running > > why i can't use jack an normal user? what have i missed? why there are 5 > processes of jack? is this a secure way? do i need every application as suid? Yes. The jackd and your application needs to belong to the same user. So in order for the suid strategy to work, all your jack applications must also be suid. Not all applications can run as suid root because the underlying UI will not allow it. If you have source, try the inserting the following before starting any UI thread: /** * Give back ownership to the real user, * so that we don't fuck up the machine while * posing as root. * */ setreuid(getuid(), getuid()); While we are at it; there is a bug in some some versions of libpthread, causing the new UI thread to inherit RT capabilities set in the calling thread. Workaround, explicitly turn it off as in: pthread_attr_init(&i_thread_attr); // We do not want to paint pixels at insane speeds pthread_attr_setinheritsched(&i_thread_attr,PTHREAD_EXPLICIT_SCHED); pthread_create(&i_thread,&i_thread_attr,interface,NULL); > > -- mvh // Jens M Andreasen From fons.adriaensen at alcatel.be Wed Nov 2 07:43:46 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Wed Nov 2 07:44:01 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <277C5202-9A57-4D38-9F71-50F90DD7BCC6@grame.fr> References: <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102102911.GA10945@bth05w.ABSp.alcatel.be> <20051102111141.GD10945@bth05w.ABSp.alcatel.be> <277C5202-9A57-4D38-9F71-50F90DD7BCC6@grame.fr> Message-ID: <20051102124346.GF10945@bth05w.ABSp.alcatel.be> On Wed, Nov 02, 2005 at 12:38:49PM +0100, St?phane Letz wrote: > Yes, clients use open *once* when the new client opens. This is done > in a non RT thread (what we call the "notification" thread that also > handle all non RT events like callback...) > > >This means that changing the graph order can never be a RT operation, > >unless clients get a second, non-RT thread to perform this call from. > > There is no need to open the synchronization primitive at graph re- > order time. Since a given client can access all synchronization > primitive, when the graph order changes, then the client will > possibly have to notify another primitive. So if there are N clients, each of them needs N file descriptors open all the time. System wide the complexity grows as N^2. Not really a good way to tackle an O(N) problem IMHO. -- FA From letz at grame.fr Wed Nov 2 07:57:47 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Wed Nov 2 07:58:36 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051102124346.GF10945@bth05w.ABSp.alcatel.be> References: <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102102911.GA10945@bth05w.ABSp.alcatel.be> <20051102111141.GD10945@bth05w.ABSp.alcatel.be> <277C5202-9A57-4D38-9F71-50F90DD7BCC6@grame.fr> <20051102124346.GF10945@bth05w.ABSp.alcatel.be> Message-ID: <78CCD57F-464E-42DF-8130-23A5698DEFCE@grame.fr> Le 2 nov. 05 ? 13:43, Alfons Adriaensen a ?crit : > On Wed, Nov 02, 2005 at 12:38:49PM +0100, St?phane Letz wrote: > >> Yes, clients use open *once* when the new client opens. This is done >> in a non RT thread (what we call the "notification" thread that also >> handle all non RT events like callback...) >> >>> This means that changing the graph order can never be a RT >>> operation, >>> unless clients get a second, non-RT thread to perform this call >>> from. >> >> There is no need to open the synchronization primitive at graph re- >> order time. Since a given client can access all synchronization >> primitive, when the graph order changes, then the client will >> possibly have to notify another primitive. > > So if there are N clients, each of them needs N file descriptors open > all the time. System wide the complexity grows as N^2. Not really a > good way to tackle an O(N) problem IMHO. Yes but in the jackdmp data flow kind of model, the actual activation order is only known when the graph executes. Or do you have a better idea to do that? Stephane From paul at linuxaudiosystems.com Wed Nov 2 08:02:24 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Nov 2 08:00:23 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] jack and setuid In-Reply-To: <200511021221.22850.conrad.berhoerster@gmx.de> References: <200511021221.22850.conrad.berhoerster@gmx.de> Message-ID: <1130936544.10939.220.camel@localhost.localdomain> > bash-3.00# chmod ugo+s /usr/local/bin/jackd > bash-3.00# exit > bash-3.00$ ls -la /usr/local/bin/jackd > -rwsr-sr-x 1 root root 206476 2005-11-01 15:23 /usr/local/bin/jackd this is a really, really, really bad thing to do. there is no reason to run jackd as root or set it up as setuid root. you should be using some kernel-based technique that allows you to get realtime priviledges without being root (capabilities on 2.4 kernels, realtime-lsm for 2.6.12 or lower, or the new rtlimits code for 2.6.13 or above). if you cannot do that, then just run without realtime or explicitly run all JACK apps as root. do NOT install random, non-security related applications as setuid root. --p From fons.adriaensen at alcatel.be Wed Nov 2 08:05:14 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Wed Nov 2 08:05:22 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <78CCD57F-464E-42DF-8130-23A5698DEFCE@grame.fr> References: <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102102911.GA10945@bth05w.ABSp.alcatel.be> <20051102111141.GD10945@bth05w.ABSp.alcatel.be> <277C5202-9A57-4D38-9F71-50F90DD7BCC6@grame.fr> <20051102124346.GF10945@bth05w.ABSp.alcatel.be> <78CCD57F-464E-42DF-8130-23A5698DEFCE@grame.fr> Message-ID: <20051102130513.GG10945@bth05w.ABSp.alcatel.be> On Wed, Nov 02, 2005 at 01:57:47PM +0100, St?phane Letz wrote: > >So if there are N clients, each of them needs N file descriptors open > >all the time. System wide the complexity grows as N^2. Not really a > >good way to tackle an O(N) problem IMHO. > > Yes but in the jackdmp data flow kind of model, the actual activation > order is only known when the graph executes. > Or do you have a better idea to do that? Yes, don't use named semas, but 'anonymous' ones placed in memory shared by all clients. Each new client gets two pointers, one to the sema it has to wait on (fixed for the client's lifetime), and one it has to signal (changes when the graph is reordered). But of course if OSX doesn't have them, then it's impossible... -- FA From letz at grame.fr Wed Nov 2 08:22:20 2005 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Wed Nov 2 08:23:09 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051102130513.GG10945@bth05w.ABSp.alcatel.be> References: <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> <20051031011835.GC5085@linux-1> <20051102102911.GA10945@bth05w.ABSp.alcatel.be> <20051102111141.GD10945@bth05w.ABSp.alcatel.be> <277C5202-9A57-4D38-9F71-50F90DD7BCC6@grame.fr> <20051102124346.GF10945@bth05w.ABSp.alcatel.be> <78CCD57F-464E-42DF-8130-23A5698DEFCE@grame.fr> <20051102130513.GG10945@bth05w.ABSp.alcatel.be> Message-ID: <43558169-B408-4B58-8524-7FF3F254E143@grame.fr> Le 2 nov. 05 ? 14:05, Alfons Adriaensen a ?crit : > On Wed, Nov 02, 2005 at 01:57:47PM +0100, St?phane Letz wrote: > >>> So if there are N clients, each of them needs N file descriptors >>> open >>> all the time. System wide the complexity grows as N^2. Not really a >>> good way to tackle an O(N) problem IMHO. >> >> Yes but in the jackdmp data flow kind of model, the actual activation >> order is only known when the graph executes. >> Or do you have a better idea to do that? > > Yes, don't use named semas, but 'anonymous' ones placed in memory > shared by all clients. Each new client gets two pointers, one to the > sema it has to wait on (fixed for the client's lifetime), and one it > has to signal (changes when the graph is reordered). But in a data flow model, a given client may have to signal several semaphores. And the client that actually signals the semaphore is only known at activation time. For the following graph for example : --> A IN --> C --> B where A and B can run in parallel, C is activated by the *last* client of A and B that finish its processing. Thus A and B have to "know" the C semaphore. More generally a given client would have to keep a set of semaphores it may have to signal for a given graph topology. This could improve the N*N issue but is more difficult to handle. > > But of course if OSX doesn't have them, then it's impossible... > And OSX does not support them, so i guess we will keep the current (simple...) implementation in jackdmp until the problem you describe becomes a real one in real situations... Stephane From conrad.berhoerster at gmx.de Wed Nov 2 08:25:45 2005 From: conrad.berhoerster at gmx.de (conrad =?utf-8?q?berh=C3=B6rster?=) Date: Wed Nov 2 08:29:41 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] jack and setuid In-Reply-To: <1130936544.10939.220.camel@localhost.localdomain> References: <200511021221.22850.conrad.berhoerster@gmx.de> <1130936544.10939.220.camel@localhost.localdomain> Message-ID: <200511021425.46343.conrad.berhoerster@gmx.de> Am Mittwoch, 2. November 2005 14:02 schrieb Paul Davis: thanks paul, > > bash-3.00# chmod ugo+s /usr/local/bin/jackd > > bash-3.00# exit > > bash-3.00$ ls -la /usr/local/bin/jackd > > -rwsr-sr-x 1 root root 206476 2005-11-01 15:23 /usr/local/bin/jackd > > this is a really, really, really bad thing to do. yes, i have read that, because of security. but don't know a better way. > there is no reason to > run jackd as root or set it up as setuid root. you should be using some > kernel-based technique that allows you to get realtime priviledges > without being root (capabilities on 2.4 kernels, realtime-lsm for 2.6.12 > or lower, or the new rtlimits code for 2.6.13 or above). since i'm using 2.6.14 , you mean set_rtlimits from http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz ? but if i run jack as a user, there are no capture ports, and i have tons of xruns. sizu c~ From asbjs at stud.ntnu.no Wed Nov 2 09:03:33 2005 From: asbjs at stud.ntnu.no (Asbjørn Sæbø) Date: Wed Nov 2 09:03:39 2005 Subject: [linux-audio-dev] LDAS (Low Delay Audio Streamer) 0.1.0 Message-ID: <20051102140333.GB3608@stud.ntnu.no> LDAS (Low Delay Audio Streamer) is software for full-duplex low-latency transmission of audio over IP. This is the first public release. At this point, the basic functionality is present -- LDAS is capable of transmitting full duplex two-channel audio between two computers. This has been tested using the ldas_mate binary running on two computers equipped with SoundBlaster Live sound cards. (Note however that the software is still in an early state. Features are lacking, and the code is somewhat fragile.) * Download: http://www.q2s.ntnu.no/~asbjs/ldas/ldas-0.1.0.tar * Web page: http://www.q2s.ntnu.no/~asbjs/ldas/ldas.html * Mailing list: https://pat.q2s.ntnu.no/mailman/listinfo/ldas-dev * Q2S web page: http://www.q2s.ntnu.no/ LDAS is released under the GNU GPL. It comes with no warranty. Many thanks to Lee Revell, who has taken part in the development of LDAS. His contributions have been very valuable, and a great help in getting this far. LDAS is developed at Centre for Quantifiable Quality of Service in Communication Systems (Q2S), at the Norwegian University of Science and Technology. Asbj?rn S?b? -- Asbj?rn S?b? Post.doc., Centre for Quantifiable Quality of Service in Communication Systems Norwegian University of Science and Technology From conrad.berhoerster at gmx.de Wed Nov 2 09:30:49 2005 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Wed Nov 2 09:34:38 2005 Subject: [linux-audio-dev] xruns Message-ID: <200511021530.49189.conrad.berhoerster@gmx.de> Hello list, well i try to understand the reason of xruns. when will they appear? for me it's curious, that , while copy a big file (> 50MB ) or many small one, there are xruns. so, it seems, that it has nothing to do with the soundcard buffers. any comments? sizu c~ From mista.tapas at gmx.net Wed Nov 2 12:35:22 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Wed Nov 2 12:35:28 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <200511021530.49189.conrad.berhoerster@gmx.de> References: <200511021530.49189.conrad.berhoerster@gmx.de> Message-ID: <20051102183522.437d234b@mango.fruits.de> On Wed, 2 Nov 2005 15:30:49 +0100 conrad berh?rster wrote: > Hello list, > well i try to understand the reason of xruns. when will they appear? > > for me it's curious, that , while copy a big file (> 50MB ) or many small one, > there are xruns. so, it seems, that it has nothing to do with the soundcard > buffers. > > any comments? Well, yeah. First of all your question is very unprecise. I will try to guess the blanks. 1) you are probably talking about jackd as most other alsa apps don't even report their xruns 2) you are probably not running a realtime preemption or other low latency kernel 3) you are not running jack with the realtime flag (-R) The reason for an xrun is basically: The process consuming/producing audio did not do this fast enough (Audio is processed in chunks and you have the time equivalent to one chunk of audio to produce/consume it). This can have many reasons: - you ask too much of your computer (like the computations involved are simply too complex). This would produce a constant stream of xruns though. I suppose you probably see much less then 1 per periodsize/samplerate sec. - this is the more probable reason: Some other process on your system kept your audio producing/consuming process from doing its thang. This second one can be remedied by changing step 2 and 3 above. There's two more potential reasons which i can think of right now: 4) your jack tmpfs is not mounted on a tmpfs or shmfs filesystem 5) NPTL hell (google for this one) Have fun, Flo -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Wed Nov 2 12:38:29 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Wed Nov 2 12:38:37 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] jack and setuid In-Reply-To: <200511021425.46343.conrad.berhoerster@gmx.de> References: <200511021221.22850.conrad.berhoerster@gmx.de> <1130936544.10939.220.camel@localhost.localdomain> <200511021425.46343.conrad.berhoerster@gmx.de> Message-ID: <20051102183829.2adba8cf@mango.fruits.de> On Wed, 2 Nov 2005 14:25:45 +0100 conrad berh??rster wrote: > Am Mittwoch, 2. November 2005 14:02 schrieb Paul Davis: > thanks paul, > > > bash-3.00# chmod ugo+s /usr/local/bin/jackd > > > bash-3.00# exit > > > bash-3.00$ ls -la /usr/local/bin/jackd > > > -rwsr-sr-x 1 root root 206476 2005-11-01 15:23 /usr/local/bin/jackd > > > > this is a really, really, really bad thing to do. > yes, i have read that, because of security. but don't know a better way. > > > there is no reason to > > run jackd as root or set it up as setuid root. you should be using some > > kernel-based technique that allows you to get realtime priviledges > > without being root (capabilities on 2.4 kernels, realtime-lsm for 2.6.12 > > or lower, or the new rtlimits code for 2.6.13 or above). > since i'm using 2.6.14 , you mean set_rtlimits from > http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz ? > > but if i run jack as a user, there are no capture ports, and i have tons of > xruns. Just for completeness sake: You can use the realtime lsm for 2.6.13 and above, too. I would even recommend it, since it's much less of a hassle to setup (rt_limits being the "correct" solution or not). Flo -- Palimm Palimm! http://tapas.affenbande.org From conrad.berhoerster at gmx.de Wed Nov 2 12:46:03 2005 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Wed Nov 2 12:49:52 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] jack and setuid In-Reply-To: <20051102183829.2adba8cf@mango.fruits.de> References: <200511021221.22850.conrad.berhoerster@gmx.de> <200511021425.46343.conrad.berhoerster@gmx.de> <20051102183829.2adba8cf@mango.fruits.de> Message-ID: <200511021846.05368.conrad.berhoerster@gmx.de> Am Mittwoch, 2. November 2005 18:38 schrieb Florian Schmidt: > > Just for completeness sake: You can use the realtime lsm for 2.6.13 and > above, too. I would even recommend it, since it's much less of a hassle > to setup (rt_limits being the "correct" solution or not). > > Flo Just to be sure . Do you mean lsm instead of rt_limits or both. and do you have a link for the lsm patch. sizu c~ From seablade at softhome.net Wed Nov 2 12:55:45 2005 From: seablade at softhome.net (Thomas Vecchione) Date: Wed Nov 2 12:55:33 2005 Subject: [linux-audio-dev] Status of mLAN or similar? Message-ID: <4368FDA1.1090206@softhome.net> I am wondering what the status of the mLAN or something similar is in linux? I have been able to find some mention of talking with Yamaha about it, but past that I cant seem to find anything on it. I am looking for a solution to allow me to connect and stream audio in realtime over firewire to a Mac Mini to run some VSTs on until VST support in Linux is worked out completly. Thanks. Seablade From mista.tapas at gmx.net Wed Nov 2 13:35:52 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Wed Nov 2 13:35:58 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] jack and setuid In-Reply-To: <200511021846.05368.conrad.berhoerster@gmx.de> References: <200511021221.22850.conrad.berhoerster@gmx.de> <200511021425.46343.conrad.berhoerster@gmx.de> <20051102183829.2adba8cf@mango.fruits.de> <200511021846.05368.conrad.berhoerster@gmx.de> Message-ID: <20051102193552.6a2c7ff3@mango.fruits.de> On Wed, 2 Nov 2005 18:46:03 +0100 conrad berh?rster wrote: > > Am Mittwoch, 2. November 2005 18:38 schrieb Florian Schmidt: > > > > Just for completeness sake: You can use the realtime lsm for 2.6.13 and > > above, too. I would even recommend it, since it's much less of a hassle > > to setup (rt_limits being the "correct" solution or not). > > > > Flo > > Just to be sure . Do you mean lsm instead of rt_limits or both. > > and do you have a link for the lsm patch. > > sizu c~ > yep, instead of rt_limits (they both achieve the same goal with vastly different approaches). http://sourceforge.net/projects/realtime-lsm/ -- Palimm Palimm! http://tapas.affenbande.org From scjody at modernduck.com Wed Nov 2 14:51:14 2005 From: scjody at modernduck.com (Jody McIntyre) Date: Wed Nov 2 15:00:23 2005 Subject: [linux-audio-dev] Status of mLAN or similar? In-Reply-To: <4368FDA1.1090206@softhome.net> References: <4368FDA1.1090206@softhome.net> Message-ID: <20051102195114.GO3214@conscoop.ottawa.on.ca> On Wed, Nov 02, 2005 at 12:55:45PM -0500, Thomas Vecchione wrote: > I am wondering what the status of the mLAN or something similar is in > linux? I have been able to find some mention of talking with Yamaha > about it, but past that I cant seem to find anything on it. I am > looking for a solution to allow me to connect and stream audio in > realtime over firewire to a Mac Mini to run some VSTs on until VST > support in Linux is worked out completly. Thanks. I'm working on mLAN support, but my main focus is on streaming audio to/from hardware devices. It will be a while before what you're looking for is supported. I don't even know if the OSX mLAN drivers support it (though, in principle, the Linux PC could pretend to be an mLAN hardware device...) mLAN uses IEC 61883-6 for its streaming. You can find 61883-6 drivers at http://mlanalsa.sourceforge.net/ and http://freebob.sourceforge.net/ but you'll have to do a lot more work to get things going. Neither of these will do any of the connection management that is required. Cheers, Jody > > Seablade -- From ce at christeck.de Wed Nov 2 15:45:33 2005 From: ce at christeck.de (Christoph Eckert) Date: Wed Nov 2 15:45:38 2005 Subject: [linux-audio-dev] Status of mLAN or similar? In-Reply-To: <20051102195114.GO3214@conscoop.ottawa.on.ca> References: <4368FDA1.1090206@softhome.net> <20051102195114.GO3214@conscoop.ottawa.on.ca> Message-ID: <200511022145.33078.ce@christeck.de> Hi, > I'm working on mLAN support, [...] > Neither of these will do any of the connection > management that is required. thanks for the good work, and be ensured that there are at least two eyes looking forward to seing firewire audio working on Linux 8-) . Best regards ce From smoerk at gmail.com Wed Nov 2 20:43:15 2005 From: smoerk at gmail.com (oliver oli) Date: Wed Nov 2 20:43:35 2005 Subject: [linux-audio-dev] Status of mLAN or similar? In-Reply-To: <4368FDA1.1090206@softhome.net> References: <4368FDA1.1090206@softhome.net> Message-ID: <43696B33.5020803@gmail.com> Thomas Vecchione wrote: > I am wondering what the status of the mLAN or something similar is in > linux? I have been able to find some mention of talking with Yamaha > about it, but past that I cant seem to find anything on it. I am > looking for a solution to allow me to connect and stream audio in > realtime over firewire to a Mac Mini to run some VSTs on until VST > support in Linux is worked out completly. Thanks. Have you tried Netjack for connecting Jack OSX with Jack on Linux? From seablade at softhome.net Thu Nov 3 13:10:21 2005 From: seablade at softhome.net (seablade@softhome.net) Date: Thu Nov 3 13:10:27 2005 Subject: [linux-audio-dev] Re: Status of mLAN or similar? In-Reply-To: <43696B33.5020803@gmail.com> References: <4368FDA1.1090206@softhome.net> <43696B33.5020803@gmail.com> Message-ID: oliver oli writes: > Have you tried Netjack for connecting Jack OSX with Jack on Linux? Is there an implementation of netjack for linux? Heh time to go check, I had thought it was just on OSX.... That would allow me to use IP over firewire(I am assuming it is implemented correct?) However I am glad mLAN support is under works, I would definitly love to be able to use my Mac Mini as a VST DSP. Seablade From seablade at softhome.net Thu Nov 3 13:18:23 2005 From: seablade at softhome.net (seablade@softhome.net) Date: Thu Nov 3 13:18:26 2005 Subject: [linux-audio-dev] Re: Status of mLAN or similar? In-Reply-To: <43696B33.5020803@gmail.com> References: <4368FDA1.1090206@softhome.net> <43696B33.5020803@gmail.com> Message-ID: Heh I really should get my head checked, my memory is going on me, so yea I looked into NetJack, it is for Linux;) So if the author is reading this I may be able to give you some feedback soon on if it works crossplatform(x86 Linux to PPC Mac). However is there a way to get more than a stereo pair going back and forth, or am I limited in that function for right now? Seablade From torbenh at gmx.de Thu Nov 3 15:58:29 2005 From: torbenh at gmx.de (torbenh@gmx.de) Date: Thu Nov 3 15:40:07 2005 Subject: [linux-audio-dev] Re: Status of mLAN or similar? In-Reply-To: References: <4368FDA1.1090206@softhome.net> <43696B33.5020803@gmail.com> Message-ID: <20051103205829.GB4435@mobilat> On Thu, Nov 03, 2005 at 11:18:23AM -0700, seablade@softhome.net wrote: > Heh I really should get my head checked, my memory is going on me, so yea I > looked into NetJack, it is for Linux;) So if the author is reading this I > may be able to give you some feedback soon on if it works crossplatform(x86 > Linux to PPC Mac). > > However is there a way to get more than a stereo pair going back and forth, > or am I limited in that function for right now? > > Seablade robert jonssen has a mac and implemented the endianess stuff. my current work in cvs does not convert everything. i will fix this soon. but i am focussing on getting the transport sync between the hosts working. it is definitely a goal to make it work cross platform. because i intend to make some jam session with a friend of mine who will return in january to germany.... in the mean time i need testers who verify cross-platform. and yes you are currently limited to 2 channels because stupid me hardcoded the 2 in some places i did not tidy up yet. but if you use 100mbit 4 channels should be possible without any drawbacks. step by step. i dont have much spare time :( -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From rzewnickie at rfa.org Thu Nov 3 15:47:37 2005 From: rzewnickie at rfa.org (Eric Dantan Rzewnicki) Date: Thu Nov 3 15:47:49 2005 Subject: [linux-audio-dev] digigram mixart cards in smp machine Message-ID: <20051103204737.GA4463@rfa.org> I'm trying to get a digigram mixart8 aes/ebu working in a dual xeon box. A RME digi96 card works fine in the same box and the digigram works fine in a different uni-processor box. I don't know if it's smp related or just the box or what. booting with nosmp does not help. The symptom is that aplay fails with EINVAL when trying to open /dev/snd/pcmC0D0p (or any other device on the card). jackd fails similarly when trying to open the corresponding capture device. Elrond:~# aplay /var/snd/999999_000.wav aplay: main:533: audio open error: Invalid argument The firmware is loaded. aplay works on the same box with the RME card. This is debian sarge with 2.6.13 (also tried 2.6.14) and alsa 1.0.9. Anyone have any thoughts? -- Eric Dantan Rzewnicki | Systems Administrator Technical Operations Division | Radio Free Asia 2025 M Street, NW | Washington, DC 20036 | 202-530-4900 CONFIDENTIAL COMMUNICATION This e-mail message is intended only for the use of the addressee and may contain information that is privileged and confidential. Any unauthorized dissemination, distribution, or copying is strictly prohibited. If you receive this transmission in error, please contact network@rfa.org. From ajtee at ajtee.plus.com Thu Nov 3 16:15:04 2005 From: ajtee at ajtee.plus.com (Adam Tee) Date: Thu Nov 3 16:15:11 2005 Subject: [linux-audio-dev] [ANN] Denemo 0.7.4 Released Message-ID: <436A7DD8.2090304@ajtee.plus.com> Denemo is a GTK+ front end for GNU Lilypond Music Typesetter. http://denemo.sourceforge.net After a long period of time denemo 0.7.4 has been released. New features include : Help Documentation Support for exporting to Lilypond 2.6 All ornaments/articulations added Replace Mode Basic Redo/Undo Functionality for individual objects More Templates available Export to PDF (via lilypond processing) Courtesy of Jens Askengren Also, this mail serves as a call for additional contributors to the project as Lilypond is fast moving rapid development is required to keep up. A plug-in API is being developed to enable export to other file formats or automated composition tools. Any contribution will be greatly received. Adam From jwoithe at physics.adelaide.edu.au Thu Nov 3 17:49:59 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Thu Nov 3 17:50:03 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] jack and setuid Message-ID: <200511032249.jA3Mnxai021075@auster.physics.adelaide.edu.au> Florian Schmidt wrote: > > since i'm using 2.6.14 , you mean set_rtlimits from > > http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz ? > > > > but if i run jack as a user, there are no capture ports, and i have tons of > > xruns. > > Just for completeness sake: You can use the realtime lsm for 2.6.13 and > above, too. I would even recommend it, since it's much less of a hassle > to setup (rt_limits being the "correct" solution or not). I'm a bit puzzled by this statement. lsm requires you get the patch, apply it to your kernel, configure and compile your kernel, install and boot the new kernel and then you can start configuring userspace to take advantage of it. In contrast, using the rtlimits approach can be as simple as grabbing set_rtlimits and compiling it (assuming one has a kernel >= 2.6.13 installed of course). Configuring userspace is via a single simple text file (documented in the source distribution). Using it then boils down to doing things like set_rtlimits -r /usr/local/bin/jackd ... set_rtlimits -r /usr/local/bin/ardour etc when starting applications which need it. Aliases can even be used to hide the set_rtlimits bit if desired. To me this seems a *lot* easier than messing around with patched kernels. It *is* true that (on systems which use PAM) PAM can be patched to provide access to the rtlimits functionality in a transparent way. I will admit that doing things this way is complex and a hassle. I wrote set_rtlimits for two reasons: 1) give myself access to the rtlimits functionality - my system doesn't run PAM, so the PAM patches aren't useful to me personally. 2) provide a much simpler way to get access to the rtlimits functionality in this interim period until PAM (or login in the case of systems not using PAM) support rtlimits out the box. set_rtlimits can also control access to the rtlimit resource on a per-program basis. A patched login wouldn't be able to do this; PAM may or may not - I don't know enough about it to comment. Of course everyone is free to choose the solution which best suits them; if people prefer lsm that's fine by me. As a side comment, I'm currently finalising a new version of set_rtlimits. I've generalised it so it can set other resource limits too - locked-in-memory size for example - since this can also be useful to control on a per-program basis. Consequently its name will change to set_rlimits but the version number will be sequential. Invocation has also been made easier (absolute paths will no longer need to be specified - they will be pulled from the configuration file). I expect to have time to finalise it in the next couple of weeks. Best regards jonathan From conrad.berhoerster at gmx.de Fri Nov 4 09:57:41 2005 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Fri Nov 4 10:01:31 2005 Subject: [linux-audio-dev] jack and setuid In-Reply-To: <200511032249.jA3Mnxai021075@auster.physics.adelaide.edu.au> References: <200511032249.jA3Mnxai021075@auster.physics.adelaide.edu.au> Message-ID: <200511041557.42839.conrad.berhoerster@gmx.de> Am Donnerstag, 3. November 2005 23:49 schrieb Jonathan Woithe: > > I'm a bit puzzled by this statement. lsm requires you get the patch, apply > it to your kernel, configure and compile your kernel, install and boot the > new kernel and then you can start configuring userspace to take advantage > of it. > > In contrast, using the rtlimits approach can be as simple as grabbing > set_rtlimits and compiling it (assuming one has a kernel >= 2.6.13 > installed of course). Configuring userspace is via a single simple text > file (documented in the source distribution). Using it then boils down to > doing things like > > set_rtlimits -r /usr/local/bin/jackd ... > set_rtlimits -r /usr/local/bin/ardour yes jonathan, in my opinion its easier to set up set_rtlimits than lsm but i thought, set_rtlimits gives me the same right as a normal user as when i am root. right? But on my system, when i started jackd as normal user as you wrote above. in the config file i only changed the username into soundroom ------------------------ soundroom@funnjoy:~/src$ set_rtlimits -r /usr/local/bin/jackd -R -dalsa jackd 0.100.0 [..] JACK compiled with System V SHM support. cannot lock down memory for jackd (Cannot allocate memory) loading driver .. creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit control device hw:0 ALSA: Cannot open PCM device alsa_pcm for capture. Falling back to playback-only mode configuring for 48000Hz, period = 1024 frames, buffer = 2 periods nperiods = 2 for playback JACK: unable to mlock() port buffers: Cannot allocate memory jack main caught signal 2 no message buffer overruns ------------------------ and when i'm root evrything went better, i see my two capture devs, have no problems with memory and whatever. ------------------------- root@funnjoy:/home/soundroom/src# jackd -R -dalsa jackd 0.100.0 [..]JACK compiled with System V SHM support. loading driver .. creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit control device hw:0 configuring for 48000Hz, period = 1024 frames, buffer = 2 periods nperiods = 2 for capture nperiods = 2 for playback jack main caught signal 2 no message buffer overruns ------------------------------------------ can someone out there tell me this hint, please From d.sbragion at infotecna.it Fri Nov 4 12:39:15 2005 From: d.sbragion at infotecna.it (Denis Sbragion) Date: Fri Nov 4 12:39:19 2005 Subject: [linux-audio-dev] [ANN] DRC 2.6.1 Message-ID: <5.1.0.14.1.20051104183909.02df0150@pop3.infotecna.lcl> Hello Everybody, DRC 2.6.1 is available at: http://sourceforge.net/project/showfiles.php?group_id=136217 and soon it will be announced at the usual: http://freshmeat.net/projects/drc/ Changes: Minor corrections and improvements have been applied to the documentation and to the pre-echo truncation inversion procedure. A new target transfer function definition procedure based on Uniform B Splines has been introduced. The development environment has been moved to Code::Blocks and GCC/MinGW. Best of listening, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it From mista.tapas at gmx.net Fri Nov 4 14:21:51 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Nov 4 14:22:03 2005 Subject: [linux-audio-dev] [ANN] rt_watchdog Message-ID: <20051104202151.1b39f66f@mango.fruits.de> Hi, here http://affenbande.org/~tapas/rt_watchdog.tgz you find a small program which acts as a watchdog daemon that kills runaway SCHED_FIFO tasks. It does so by setting up two threads: - one high priority (99) consumer that runs every 3 seconds - one low priority (1) producer that runs every second the producer fills a ringbuffer and the consumer drains it. When the ringbuffer runs empty a shell script will be run (via the system() function) that tries to change the scheduling policy of all threads in the system from SCHED_FIFO to SCHED_OTHER. the offending task may naturally not run at prio 99, otherwise the watchdog would never get to run. Here's a potential problem: The shell script potentially changes its own scheduling policy to SCHED_OTHER prior to chnaging the offending runaway task. Ugh! Any hint? Also all IRQ handler threads also have their policy changed. Dunno whether that's good or not. For reference i pasted the script and the c file here: unfifo_stuff.sh (the two arguments are the two thread id's of the rt_watchdog threads, as these are not supposed to have their policy changed). There's also a small test program in the tarball (compiles to test_rt) that wastes cycles SCHED_FIFO (locking the system) but exits eventually, so it's quite safe to test the watchdog with it. Maybe someone else find's it useful. Recommendations, tips, critique are all welcome.. unfifo_stuff.sh #!/bin/bash for i in $( ps -eL -o pid ); do if [ "$i" != "$1" -a "$i" != "$2" ] then chrt -o -p 0 $i fi done rt_watchdog.c: #include #include #include #include #include #include #include #include #include #include #include _syscall0(pid_t,gettid) #include "ringbuffer.h" /* how long to sleep between checks in the high prio thread */ #define SLEEPSECS 3 /* how long to sleep between writing "alive" messages to the ringbuffer from the low prio thread */ #define LP_SLEEPSECS 1 /* the priority of the high prio thread */ #define PRIO 99 /* the priority of the low prio thread */ #define LP_PRIO 1 /* the ringbuffer used to transfer "alive" messages from low prio producer to high prio consumer */ jack_ringbuffer_t *rb; pthread_t low_prio_thread; /* the thread id's for the low prio and high prio threads. these get passed to the unfifo_stuff.sh script to make sure the watchdog doesn't repolicy itself to SCHED_OTHER */ pid_t lp_tid; pid_t hp_tid; void signalled(int signal) { } volatile int thread_finish; /* this is the low prio thread. it simply writes to the ringbuffer to signal that it got to run, meaning it is still alive */ void *lp_thread_func(void *arg) { char data; struct timespec tv; lp_tid = gettid(); /* syslog(LOG_INFO, "lp tid: %i", gettid()); */ data = 0 ; while(!thread_finish) { /* we simply write stuff to the ringbuffer and go back to sleeping we can ignore the return value, cause, when it's full, it's ok the data doesn;t have any meaning. it just needs to be there running full shouldn't happen anyways */ jack_ringbuffer_write(rb, &data, sizeof(data)); /* then sleep a bit. but less than the watchdog high prio thread */ tv.tv_sec = LP_SLEEPSECS; tv.tv_nsec = 0; // sleep(LP_SLEEPSECS); nanosleep(&tv, NULL); } return 0; } int main() { pid_t pid, sid; int done; struct sched_param params; char data; int err; int consumed; int count; struct timespec tv; char unfifo_cmd[1000]; /* Fork off the parent process */ pid = fork(); if (pid < 0) { exit(EXIT_FAILURE); } /* If we got a good PID, then we can exit the parent process. */ if (pid > 0) { exit(EXIT_SUCCESS); } /* Change the file mode mask */ umask(0); /* Open any logs here */ openlog("rt_watchdog", 0, LOG_DAEMON); syslog(LOG_INFO, "started"); /* Create a new SID for the child process */ sid = setsid(); if (sid < 0) { /* Log any failure here */ syslog(LOG_INFO, "setsid failed. exiting"); exit(EXIT_FAILURE); } /* Change the current working directory */ if ((chdir("/")) < 0) { /* Log any failure here */ syslog(LOG_INFO, "chdir failed. exiting"); exit(EXIT_FAILURE); } /* Close out the standard file descriptors */ close(STDIN_FILENO); close(STDOUT_FILENO); close(STDERR_FILENO); // syslog(LOG_INFO, "closed fd's"); /* syslog(LOG_INFO, "hp tid: %i", gettid()); */ hp_tid = gettid(); /* not really nessecary, but wtf */ mlockall(MCL_FUTURE); thread_finish = 0; done = 0; /* get ourself SCHED_FIFO with prio PRIO */ params.sched_priority = PRIO; if (pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶ms)) { syslog(LOG_INFO, "couldn't set realtime prio for main thread.. exiting.."); exit(EXIT_FAILURE); } // syslog(LOG_INFO, "prio set"); /* create a ringbuffer for the low prio thread to signal it's alive */ rb = jack_ringbuffer_create(1024); // syslog(LOG_INFO, "ringbuffer created"); /* create low prio thread */ err = pthread_create(&low_prio_thread, 0, lp_thread_func, 0); if(err) { syslog(LOG_INFO, "couldn't create low prio thread, exiting.."); exit(EXIT_FAILURE); } /* dirty. we really need to wait for the lp thread to have written the lp_tid. (condition variable?) */ sleep(1); // syslog(LOG_INFO, "created low prio thread"); /* make the low prio thread sched_fifo */ params.sched_priority = LP_PRIO; if (pthread_setschedparam(low_prio_thread, SCHED_FIFO, ¶ms)) { syslog(LOG_INFO, "couldn't set realtime prio for lower prio thread.. exiting.."); thread_finish = 1; pthread_join(low_prio_thread, NULL); exit(EXIT_FAILURE); } /* this is the main loop. we somply check whether the low prio thread got to run at all by looking into the ringbuffer. If it's empty, the low prio thread is kinda dead */ count = 0; while(!done) { tv.tv_sec = SLEEPSECS; tv.tv_nsec = 0; nanosleep(&tv, NULL); /* sleep(SLEEPSECS); */ count++; /* syslog(LOG_INFO, "count %i", count); */ /* see if our little brother got to run */ if (jack_ringbuffer_read_space(rb) == 0) { /* oh oh, it didn't */ syslog(LOG_INFO, "low prio thread seems to be starved, taking measures..."); /* we pass our own TID's to the script, so we are excluded from the scheduling policy change */ sprintf(unfifo_cmd, "unfifo_stuff.sh %i %i", lp_tid, hp_tid); syslog(LOG_INFO, "unfifo command:"); syslog(LOG_INFO, unfifo_cmd); if (system(unfifo_cmd) == -1) { syslog(LOG_INFO, "unfifo command failed"); } } else { /* consume stuff from ringbuffer */ consumed = 0; while (jack_ringbuffer_read_space(rb)) { consumed++; jack_ringbuffer_read(rb, &data, 1); } /* syslog(LOG_INFO, "lp alive: %i", consumed); */ } } thread_finish = 1; pthread_join(low_prio_thread, NULL); syslog(LOG_INFO, "exiting"); exit(EXIT_SUCCESS); } test.c: #include #include #include #include int main() { struct sched_param params; int done = 0; struct timeval tv; time_t startsec; unsigned long int loops; int outer_loops; params.sched_priority = 80; pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶ms); gettimeofday(&tv,0); startsec = tv.tv_sec; #if 0 while(!done) { gettimeofday(&tv, 0); if(tv.tv_sec - startsec > 10) done = 1; } #endif for (outer_loops = 0; outer_loops < 4; ++outer_loops) { for (loops = 0; loops < 1000000000; loops++) {done += 1;} } exit (EXIT_SUCCESS); } -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Fri Nov 4 18:34:33 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Fri Nov 4 18:34:43 2005 Subject: [linux-audio-dev] Re: [linux-audio-user] [ANN] rt_watchdog In-Reply-To: <20051104202151.1b39f66f@mango.fruits.de> References: <20051104202151.1b39f66f@mango.fruits.de> Message-ID: <20051105003433.7822cff0@mango.fruits.de> On Fri, 4 Nov 2005 20:21:51 +0100 Florian Schmidt wrote: > > Hi, > > here > > http://affenbande.org/~tapas/rt_watchdog.tgz Hi again. Something is fishy. It just stopped working. And i don't know why. Maybe something with kernel timer priorities. I don't know. So better don't use it unless you want to help debugging :) i idle in #lad on irc.freenode.org. Have fun, Flo -- Palimm Palimm! http://tapas.affenbande.org From rj at spamatica.se Sat Nov 5 10:01:00 2005 From: rj at spamatica.se (Robert Jonsson) Date: Sat Nov 5 10:01:16 2005 Subject: [linux-audio-dev] Re: Status of mLAN or similar? In-Reply-To: <20051103205829.GB4435@mobilat> References: <4368FDA1.1090206@softhome.net> <20051103205829.GB4435@mobilat> Message-ID: <200511051601.01266.rj@spamatica.se> Hi, On Thursday 03 Nov 2005 21:58, torbenh@gmx.de wrote: > On Thu, Nov 03, 2005 at 11:18:23AM -0700, seablade@softhome.net wrote: > > Heh I really should get my head checked, my memory is going on me, so yea > > I looked into NetJack, it is for Linux;) You don't need to get your head checked. The unfortunate truth is that there are two more or less unrelated netjack projects, one is for MacOS, one is for Linux. As Torben points out I did get it to work with PPC Linux (to some degree atleast) but it won't work with MacOS. The network-transport mechanism is not the same between the two so it won't work using macosx-netjack <--> linux-netjack either, atleast not for the moment. Regards, Robert > > So if the author is reading > > this I may be able to give you some feedback soon on if it works > > crossplatform(x86 Linux to PPC Mac). > > > > However is there a way to get more than a stereo pair going back and > > forth, or am I limited in that function for right now? > > > > Seablade > > robert jonssen has a mac and implemented the endianess stuff. > my current work in cvs does not convert everything. i will fix this > soon. but i am focussing on getting the transport sync between the hosts > working. > > it is definitely a goal to make it work cross platform. > > because i intend to make some jam session with a friend of mine who will > return in january to germany.... > > in the mean time i need testers who verify cross-platform. > > and yes you are currently limited to 2 channels because stupid me > hardcoded the 2 in some places i did not tidy up yet. > but if you use 100mbit 4 channels should be possible without any > drawbacks. > > step by step. i dont have much spare time :( -- http://spamatica.se/musicsite/ From kouhia at nic.funet.fi Sat Nov 5 14:23:05 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sat Nov 5 14:23:10 2005 Subject: [linux-audio-dev] Re: Radio receiver. Message-ID: Thanks for the tip on "diversity reception". Yes, I got the idea from astronomer's systems. I use the term "invented" the same way as patenteers: due lack of extensive literary search, I know at most that the thing is new to me. Though, I have never seen such a system used in consumer radios. I'm not sure if it have been used in DX'ing radios either. My test plan was to record the same music station at two cities (apart 200km). Then timescale and align the digitized (1 or 2 hours) recordings manually. And then do the thing. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From ix at replic.net Sat Nov 5 14:56:45 2005 From: ix at replic.net (carmen) Date: Sat Nov 5 14:54:19 2005 Subject: [linux-audio-dev] Re: Radio receiver. In-Reply-To: References: Message-ID: <20051105195645.GB713@replic.net> > Though, I have never seen such a system used in consumer radios. > I'm not sure if it have been used in DX'ing radios either. all of my consumer WiFi radios use this system. the older ones with 2 antennas, but the latest MIMO (their word for diversity reception) models sporting 7 or more... From fons.adriaensen at skynet.be Sat Nov 5 15:05:55 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sat Nov 5 15:00:51 2005 Subject: [linux-audio-dev] Re: Radio receiver. In-Reply-To: References: Message-ID: <20051105200555.GC4960@linux-1> On Sat, Nov 05, 2005 at 09:23:05PM +0200, Juhana Sadeharju wrote: > > Thanks for the tip on "diversity reception". Yes, I got the > idea from astronomer's systems. Normally 'diversity reception' means to combine the signals from 2 or more receivers to obtain a result that has a better S/N ratio (or less missing data) than either of the inputs. What the astronomers are doing is even more tricky. They combine signals from distant receivers not to get a better signal but to improve the angular resolution of the antenna, by 'synthesising' the effect of a very big one. It's called 'interferometry' and can get quite complicated. > My test plan was to record the same music station at two cities > (apart 200km). Then timescale and align the digitized (1 or 2 hours) > recordings manually. And then do the thing. If both recordings are complete and have about the same quality, the best you can obtain is a 3 dB gain in S/N (for analog transmissions - for digital the picture is more complicated). -- FA From James at superbug.co.uk Sun Nov 6 05:59:57 2005 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sun Nov 6 06:59:56 2005 Subject: [linux-audio-dev] Mixer controls Message-ID: <436DE22D.2090705@superbug.co.uk> Hi, I am an ALSA developer. I was hoping that someone on this list would have experience with professional mixing desks. I would like to duplicate the behavior of professional mixing desks in the alsa mixer controls. I am only interested in gain control at this point. There are effectively two separate but linked controls for each gain control. a) Mute control b) Gain control in dB. If I have a gain control that starts at 0 dB, with each step down by 1 dB until -40dB. With DSPs, it is very easy to add the next step down as being the mute level. E.g. Sample * gain_multiplier where for the mute level, gain_multiplier = 0.0, thus resulting is a zero sample output. My question is really what should I do when the gain_multiplier is 0.0 Do I: a) Limit the range of the gain control to 0dB to -40 dB and have a separate Mute control. b) When the gain control has a gain_multiplier of 0.0, automatically activate the Mute control. c) Some other method. Thank you James From torbenh at gmx.de Sun Nov 6 07:27:18 2005 From: torbenh at gmx.de (torbenh@gmx.de) Date: Sun Nov 6 07:08:50 2005 Subject: [linux-audio-dev] Re: Status of mLAN or similar? In-Reply-To: <200511051601.01266.rj@spamatica.se> References: <4368FDA1.1090206@softhome.net> <20051103205829.GB4435@mobilat> <200511051601.01266.rj@spamatica.se> Message-ID: <20051106122718.GA26115@mobilat> On Sat, Nov 05, 2005 at 04:01:00PM +0100, Robert Jonsson wrote: > Hi, > > On Thursday 03 Nov 2005 21:58, torbenh@gmx.de wrote: > > On Thu, Nov 03, 2005 at 11:18:23AM -0700, seablade@softhome.net wrote: > > > Heh I really should get my head checked, my memory is going on me, so yea > > > I looked into NetJack, it is for Linux;) > > You don't need to get your head checked. The unfortunate truth is that there > are two more or less unrelated netjack projects, one is for MacOS, one is for > Linux. > As Torben points out I did get it to work with PPC Linux (to some degree > atleast) but it won't work with MacOS. > The network-transport mechanism is not the same between the two so it won't > work using macosx-netjack <--> linux-netjack either, atleast not for the > moment. i was not aware of this. i cant get the sourcecode of netjack-osx because the j sf cvs services are down... always release source tarballs. ok... now i think this namechoice was REALLY bad. i believe, that both projects work differently. anybody can tell me how the sync is done ? we need a new project name: fast. project can be found using google. no real conflicts. > > Regards, > Robert > > > > So if the author is reading > > > this I may be able to give you some feedback soon on if it works > > > crossplatform(x86 Linux to PPC Mac). > > > > > > However is there a way to get more than a stereo pair going back and > > > forth, or am I limited in that function for right now? > > > > > > Seablade > > > > robert jonssen has a mac and implemented the endianess stuff. > > my current work in cvs does not convert everything. i will fix this > > soon. but i am focussing on getting the transport sync between the hosts > > working. > > > > it is definitely a goal to make it work cross platform. > > > > because i intend to make some jam session with a friend of mine who will > > return in january to germany.... > > > > in the mean time i need testers who verify cross-platform. > > > > and yes you are currently limited to 2 channels because stupid me > > hardcoded the 2 in some places i did not tidy up yet. > > but if you use 100mbit 4 channels should be possible without any > > drawbacks. > > > > step by step. i dont have much spare time :( > > -- > http://spamatica.se/musicsite/ > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language From fons.adriaensen at skynet.be Sun Nov 6 07:49:27 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Nov 6 07:44:19 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <436DE22D.2090705@superbug.co.uk> References: <436DE22D.2090705@superbug.co.uk> Message-ID: <20051106124926.GA4767@linux-1> On Sun, Nov 06, 2005 at 10:59:57AM +0000, James Courtier-Dutton wrote: > My question is really what should I do when the gain_multiplier is 0.0 > > Do I: > a) Limit the range of the gain control to 0dB to -40 dB and have a > separate Mute control. > b) When the gain control has a gain_multiplier of 0.0, automatically > activate the Mute control. > c) Some other method. On most pro mixing desks the fader will go down to zero gain, *and* there will be a separate mute button. The mute may have effects beyond just muting the signal controlled by the fader, .e.g. it could also switch auxiliary sends or have other effects. On a real pro desk it will be 'debounced' i.e. do a fast fade in/out. With some exeptions, most soundcards' mixer controls are not really meant to be used as a mixing desk, just to set gains and forget. Many cards will have very coarse gain steps for example, and the mute function may generate clicks (a sure killer on a pro mixer !). -- FA From James at superbug.co.uk Sun Nov 6 07:21:30 2005 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sun Nov 6 08:21:30 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <20051106124926.GA4767@linux-1> References: <436DE22D.2090705@superbug.co.uk> <20051106124926.GA4767@linux-1> Message-ID: <436DF54A.5090100@superbug.co.uk> fons adriaensen wrote: > On Sun, Nov 06, 2005 at 10:59:57AM +0000, James Courtier-Dutton wrote: > > >>My question is really what should I do when the gain_multiplier is 0.0 >> >>Do I: >>a) Limit the range of the gain control to 0dB to -40 dB and have a >>separate Mute control. >>b) When the gain control has a gain_multiplier of 0.0, automatically >>activate the Mute control. >>c) Some other method. > > > On most pro mixing desks the fader will go down to zero gain, *and* > there will be a separate mute button. The mute may have effects beyond > just muting the signal controlled by the fader, .e.g. it could also > switch auxiliary sends or have other effects. On a real pro desk it > will be 'debounced' i.e. do a fast fade in/out. > > With some exeptions, most soundcards' mixer controls are not really > meant to be used as a mixing desk, just to set gains and forget. > Many cards will have very coarse gain steps for example, and the > mute function may generate clicks (a sure killer on a pro mixer !). > Thank you. Ok, I will have a zero gain_multiplier value in the mixer control slider. I wish to also display in the mixer control a text representation of the dB gain level. The problem I have is what should I display for the 0.0 gain_multiplier setting. I.e. When it effectively mutes the sound output at it's minimal slider setting. a) -999.0 dB b) Some other text entirely. Bear in mind that I only have about 4-5 chars of space to put the text in. James From fons.adriaensen at skynet.be Sun Nov 6 08:44:02 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Nov 6 08:38:59 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <436DF54A.5090100@superbug.co.uk> References: <436DE22D.2090705@superbug.co.uk> <20051106124926.GA4767@linux-1> <436DF54A.5090100@superbug.co.uk> Message-ID: <20051106134402.GC4767@linux-1> On Sun, Nov 06, 2005 at 12:21:30PM +0000, James Courtier-Dutton wrote: > The problem I have is what should I > display for the 0.0 gain_multiplier setting. I.e. When it effectively > mutes the sound output at it's minimal slider setting. "Off" ??? -- FA From tszilagyi at users.sourceforge.net Sun Nov 6 08:53:30 2005 From: tszilagyi at users.sourceforge.net (Tom Szilagyi) Date: Sun Nov 6 08:54:24 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <20051106134402.GC4767@linux-1> References: <436DE22D.2090705@superbug.co.uk> <20051106124926.GA4767@linux-1> <436DF54A.5090100@superbug.co.uk> <20051106134402.GC4767@linux-1> Message-ID: <20051106135330.GA32765@r51> On Sun, Nov 06, 2005 at 02:44:02PM +0100, fons adriaensen wrote: > On Sun, Nov 06, 2005 at 12:21:30PM +0000, James Courtier-Dutton wrote: > > > The problem I have is what should I > > display for the 0.0 gain_multiplier setting. I.e. When it effectively > > mutes the sound output at it's minimal slider setting. > > "Off" ??? What about "-Inf" ? Tom From tim at orford.org Sun Nov 6 09:46:50 2005 From: tim at orford.org (Tim Orford) Date: Sun Nov 6 09:46:55 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <436DE22D.2090705@superbug.co.uk> References: <436DE22D.2090705@superbug.co.uk> Message-ID: <20051106144650.GV12534@orford.org> On Sun, Nov 06, 2005 at 10:59:57AM +0000, James Courtier-Dutton wrote: > If I have a gain control that starts at 0 dB, with each step down by 1 > dB until -40dB. I have no idea what you are trying to do, but this is not enough resolution or range for a real mixer. Regards -- Tim Orford From xaero at inwind.it Sun Nov 6 10:48:43 2005 From: xaero at inwind.it (federico) Date: Sun Nov 6 10:49:32 2005 Subject: [linux-audio-dev] the big jack bug... > crappy audio on XRUNS Message-ID: <436E25DB.2070804@inwind.it> it happens randomly, while I play a soft synth, that jack XRUNs once, and the audio become crappy, noisy, like a kinda of digital effect....bit crusher? then all synthesizers (all audio apps) sound the same sh*t... i tried recording with ardour the output, and the output is clean, so I guess is a problem of sync or something that has to do with the hardware (soundcard). in order to record this noise, i had to connect the soundcard output in its input and record it via analog in: http://xaero.ath.cx/jackbug_stereo.wav.bz2 (it is a stereo file, with the clean track panned on the left, and the dirty one on the right). i hope it could be useful to debug the problem... what other information I can provide useful for debug? note that this happens with many version of alsa (1.0.9b, 1.0.10rc2, 1.0.7 or less) and with many kernels (gentoo-sources (slightly patched for speed improvement), ck-sources, ck-sources+realtime-lsm) i hope to solve this problem, since my audio desktop is unusable as si, since audio crasher after playng for just 5 minutes :( From James at superbug.co.uk Sun Nov 6 10:21:54 2005 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sun Nov 6 11:21:56 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <20051106144650.GV12534@orford.org> References: <436DE22D.2090705@superbug.co.uk> <20051106144650.GV12534@orford.org> Message-ID: <436E1F92.6060002@superbug.co.uk> Tim Orford wrote: > On Sun, Nov 06, 2005 at 10:59:57AM +0000, James Courtier-Dutton wrote: > >>If I have a gain control that starts at 0 dB, with each step down by 1 >>dB until -40dB. > > > I have no idea what you are trying to do, but this is not enough > resolution or range for a real mixer. > > Regards > -- > Tim Orford > > It was just an example. The actual range depends on the sound card hardware, but the typical limit is something like -60 dB or -80 dB. James From luisgarr at gmail.com Sun Nov 6 11:27:24 2005 From: luisgarr at gmail.com (Luis Garrido) Date: Sun Nov 6 11:27:28 2005 Subject: [linux-audio-dev] Re: the big jack bug... > crappy audio on XRUNS Message-ID: <619e193e0511060827y64873685pc0ed3c08bdf996db@mail.gmail.com> Hi! I had a similar problem in my laptop when using a USB soundcard (Edirol UA-25). For me it was not necessarily associated with xruns. Since ardour doesn't record the noise, I would say that the problem is not in jack, but in the alsa driver. It sounded also more like a distortion than noise, since when the output levels were low the effect was less noticeable. I found empirically that harddisk writing operations like saving a file in an application would sometimes make the distortion stop, I'll be damned if I know why (interrupts?). Anyway, setting my USB unit to work at 48 kHz made this problem practically disappear. HTH, Luis > it happens randomly, while I play a soft synth, that jack XRUNs once, > and the audio become crappy, noisy, like a kinda of digital > effect....bit crusher? > > then all synthesizers (all audio apps) sound the same sh*t... > i tried recording with ardour the output, and the output is clean, so I > guess is a problem of sync or something that has to do with the hardware > (soundcard). > > in order to record this noise, i had to connect the soundcard output in > its input and record it via analog in: > http://xaero.ath.cx/jackbug_stereo.wav.bz2 (it is a stereo file, with > the clean track panned on the left, and the dirty one on the right). > > i hope it could be useful to debug the problem... > what other information I can provide useful for debug? > note that this happens with many version of alsa (1.0.9b, 1.0.10rc2, > 1.0.7 or less) and with many kernels (gentoo-sources (slightly patched > for speed improvement), ck-sources, ck-sources+realtime-lsm) > > i hope to solve this problem, since my audio desktop is unusable as si, > since audio crasher after playng for just 5 minutes :( > > From xaero at inwind.it Sun Nov 6 11:41:40 2005 From: xaero at inwind.it (federico) Date: Sun Nov 6 11:42:17 2005 Subject: [linux-audio-dev] Re: the big jack bug... > crappy audio on XRUNS In-Reply-To: <619e193e0511060827y64873685pc0ed3c08bdf996db@mail.gmail.com> References: <619e193e0511060827y64873685pc0ed3c08bdf996db@mail.gmail.com> Message-ID: <436E3244.8070804@inwind.it> Luis Garrido ha scritto: >Hi! > >I had a similar problem in my laptop when using a USB soundcard >(Edirol UA-25). For me it was not necessarily associated with xruns. > > ops i checked, i said XRUN, i meant graph timeout of qjackctl >Since ardour doesn't record the noise, I would say that the problem is >not in jack, but in the alsa driver. > > me think too >It sounded also more like a distortion than noise, since when the >output levels were low the effect was less noticeable. > >I found empirically that harddisk writing operations like saving a >file in an application would sometimes make the distortion stop, I'll >be damned if I know why (interrupts?). > >Anyway, setting my USB unit to work at 48 kHz made this problem >practically disappear. > > > i will try... >HTH, > >Luis > > > >>it happens randomly, while I play a soft synth, that jack XRUNs once, >>and the audio become crappy, noisy, like a kinda of digital >>effect....bit crusher? >> >>then all synthesizers (all audio apps) sound the same sh*t... >>i tried recording with ardour the output, and the output is clean, so I >>guess is a problem of sync or something that has to do with the hardware >>(soundcard). >> >>in order to record this noise, i had to connect the soundcard output in >>its input and record it via analog in: >>http://xaero.ath.cx/jackbug_stereo.wav.bz2 (it is a stereo file, with >>the clean track panned on the left, and the dirty one on the right). >> >>i hope it could be useful to debug the problem... >>what other information I can provide useful for debug? >>note that this happens with many version of alsa (1.0.9b, 1.0.10rc2, >>1.0.7 or less) and with many kernels (gentoo-sources (slightly patched >>for speed improvement), ck-sources, ck-sources+realtime-lsm) >> >>i hope to solve this problem, since my audio desktop is unusable as si, >>since audio crasher after playng for just 5 minutes :( >> >> >> >> > > > From joq at io.com Sun Nov 6 12:25:56 2005 From: joq at io.com (Jack O'Quin) Date: Sun Nov 6 12:19:53 2005 Subject: [linux-audio-dev] Re: [Jackit-devel] the big jack bug... > crappy audio on XRUNS In-Reply-To: <436E25DB.2070804@inwind.it> (federico's message of "Sun, 06 Nov 2005 16:48:43 +0100") References: <436E25DB.2070804@inwind.it> Message-ID: <7qek5tadsr.fsf@io.com> federico writes: > it happens randomly, while I play a soft synth, that jack XRUNs once, > and the audio become crappy, noisy, like a kinda of digital > effect....bit crusher? > > then all synthesizers (all audio apps) sound the same sh*t... > i tried recording with ardour the output, and the output is clean, so > I guess is a problem of sync or something that has to do with the > hardware (soundcard). This is likely a hardware problem. Have you reported it on alsa-devel? What card do you have? -- joq From tim at orford.org Sun Nov 6 13:20:21 2005 From: tim at orford.org (Tim Orford) Date: Sun Nov 6 13:20:27 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <436E1F92.6060002@superbug.co.uk> References: <436DE22D.2090705@superbug.co.uk> <20051106144650.GV12534@orford.org> <436E1F92.6060002@superbug.co.uk> Message-ID: <20051106182021.GW12534@orford.org> On Sun, Nov 06, 2005 at 03:21:54PM +0000, James Courtier-Dutton wrote: > It was just an example. The actual range depends on the sound card > hardware, but the typical limit is something like -60 dB or -80 dB. Ah, ok, yes i wasnt sure whether or not you were controlling the hardware. Also probably unnecessary for me to say this, but dont forget to preserve the L/R balance when the user reaches top and bottom of the fader's travel, unlike the current Alsamixer. Cheers -- Tim From rlrevell at joe-job.com Sun Nov 6 13:37:42 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Nov 6 13:39:32 2005 Subject: [linux-audio-dev] the big jack bug... > crappy audio on XRUNS In-Reply-To: <436E25DB.2070804@inwind.it> References: <436E25DB.2070804@inwind.it> Message-ID: <1131302264.13599.8.camel@mindpipe> On Sun, 2005-11-06 at 16:48 +0100, federico wrote: > it happens randomly, while I play a soft synth, that jack XRUNs once, > and the audio become crappy, noisy, like a kinda of digital > effect....bit crusher? It's probably a driver bug but could also be a PCI latency issue. Try setpci -d CARD:ID latency_timer=40 where CARD:ID is the PCI id of the card obtained from lspci. Do this immediately after loading the driver and before playing any audio. Lee From dmills at spamblock.demon.co.uk Sun Nov 6 13:58:41 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Sun Nov 6 13:58:49 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <20051106182021.GW12534@orford.org> References: <436DE22D.2090705@superbug.co.uk> <436E1F92.6060002@superbug.co.uk> <20051106182021.GW12534@orford.org> Message-ID: <200511061858.42107.dmills@spamblock.demon.co.uk> On Sunday 06 November 2005 18:20, Tim Orford wrote: > On Sun, Nov 06, 2005 at 03:21:54PM +0000, James Courtier-Dutton wrote: > > It was just an example. The actual range depends on the sound card > > hardware, but the typical limit is something like -60 dB or -80 dB. > > Ah, ok, yes i wasnt sure whether or not you were controlling the > hardware. > > Also probably unnecessary for me to say this, but dont forget to > preserve the L/R balance when the user reaches top and bottom of > the fader's travel, unlike the current Alsamixer. > Also, worth noting is that most pro desks have a fader range that goes up above 0db (typically +10 -> -70 or so) and that the mapping of fader position to db value is not linear! Typically around one third to half the travel covers the +10 -> -10db range with the -10 to -70 range shoehorned into the remainder. Obviously the provision of 'gain' may not make much sense in something that basically controls the soundcard hardware but the fader position to db gain being non linear is a feature worth preserving. IIRC there is a standard curve for midi CC values to gain that might be worth tracking down? Regards, Dan. From tim at orford.org Sun Nov 6 14:24:19 2005 From: tim at orford.org (Tim Orford) Date: Sun Nov 6 14:24:25 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <200511061858.42107.dmills@spamblock.demon.co.uk> References: <436DE22D.2090705@superbug.co.uk> <436E1F92.6060002@superbug.co.uk> <20051106182021.GW12534@orford.org> <200511061858.42107.dmills@spamblock.demon.co.uk> Message-ID: <20051106192419.GY12534@orford.org> On Sun, Nov 06, 2005 at 06:58:41PM +0000, Dan Mills wrote: > [...] but the fader position to db gain > being non linear is a feature worth preserving. for example as shown here for a Penny & Giles PGF8000 100mm fader: http://www.pennyandgiles.com/docGallery/77.PDF cheers -- Tim Orford From jwoithe at physics.adelaide.edu.au Sun Nov 6 18:15:12 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Sun Nov 6 18:15:26 2005 Subject: [linux-audio-dev] jack and setuid In-Reply-To: <200511041557.42839.conrad.berhoerster@gmx.de> from "conrad =?iso-8859-1?q?berh=F6rster?=" at Nov 04, 2005 03:57:41 PM Message-ID: <200511062315.jA6NFCmn023690@auster.physics.adelaide.edu.au> Hi Conrad > > In contrast, using the rtlimits approach can be as simple as grabbing > > set_rtlimits and compiling it (assuming one has a kernel >= 2.6.13 > > installed of course). Configuring userspace is via a single simple text > > file (documented in the source distribution). Using it then boils down to > > doing things like > > > > set_rtlimits -r /usr/local/bin/jackd ... > > set_rtlimits -r /usr/local/bin/ardour > > yes jonathan, in my opinion its easier to set up set_rtlimits than lsm > but i thought, set_rtlimits gives me the same right as a normal user as when i > am root. right? Not quite. Set_rtlimits gives selected programs (as configured in /etc/set_rtlimits.conf) permission to request elevated levels of certain resource limits, but that's all. Running something as root certainly gives you permission to do this too, but it also enables a lot of other things which are arguably not appropriate for audio-related software. :) > But on my system, when i started jackd as normal user as you wrote above. > in the config file i only changed the username into soundroom > ------------------------ > soundroom@funnjoy:~/src$ set_rtlimits -r /usr/local/bin/jackd -R -dalsa > jackd 0.100.0 > [..] JACK compiled with System V SHM support. > cannot lock down memory for jackd (Cannot allocate memory) > loading driver .. > creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit > control device hw:0 > ALSA: Cannot open PCM device alsa_pcm for capture. Falling back to > playback-only mode > configuring for 48000Hz, period = 1024 frames, buffer = 2 periods > nperiods = 2 for playback > JACK: unable to mlock() port buffers: Cannot allocate memory > jack main caught signal 2 > no message buffer overruns The issues you're having here have nothing to do with set_rtlimits. In fact, the lack of any messages associated with realtime priorities indicates that set_rtlimits is doing exactly what it's meant to do. The problems are related to permissions of other things. The "cannot lock down memory for jackd" message tells you that jackd (or more generally the user running jackd) doesn't have sufficient permission to lock into memory the amount being requested by jackd. This is configured using the standard resource limit mechanism provided by your system (although for convenience the next set_rtlimits release will include support for this resource limit too). Look for the "locked-in-memory address space" limit, or words to that effect. If your system uses PAM it's configured from PAM's configuration file (I can't provide further details here since I don't use PAM). If not (eg: you run Slackware) /etc/limits (man limits) is your friend. From memory I think I found 20MB sufficient for most of my needs, but your mileage may vary. The "Cannot open PCM device" means the user running jackd can't open the ALSA device files under /dev/. You will need to arrange for permissions/ownership of these device files to be set sufficient to allow the jackd user to open them read-write. Many people set the group owner of the device files to a new group which they create for the purpose ("audio" for example) and then allow group rw access. There are many other ways, however. Feel free to contact me off-list for further details. Regards jonathan From loki.davison at gmail.com Sun Nov 6 19:43:43 2005 From: loki.davison at gmail.com (Loki Davison) Date: Sun Nov 6 19:43:48 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: <20051106192419.GY12534@orford.org> References: <436DE22D.2090705@superbug.co.uk> <436E1F92.6060002@superbug.co.uk> <20051106182021.GW12534@orford.org> <200511061858.42107.dmills@spamblock.demon.co.uk> <20051106192419.GY12534@orford.org> Message-ID: On 11/7/05, Tim Orford wrote: > On Sun, Nov 06, 2005 at 06:58:41PM +0000, Dan Mills wrote: > > [...] but the fader position to db gain > > being non linear is a feature worth preserving. > > for example as shown here for a Penny & Giles PGF8000 100mm fader: > > http://www.pennyandgiles.com/docGallery/77.PDF > > > cheers > -- > Tim Orford > My mixer (Ecler HAK320) has selectable curve on all faders, but option i use is nonlinear, log style which is a very nice feature to preserve. It's got mute switches as well, but i never use them. Loki From jens.andreasen at chello.se Sun Nov 6 20:45:53 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Nov 6 20:45:58 2005 Subject: [linux-audio-dev] Mixer controls In-Reply-To: <20051106134402.GC4767@linux-1> References: <436DE22D.2090705@superbug.co.uk> <20051106124926.GA4767@linux-1> <436DF54A.5090100@superbug.co.uk> <20051106134402.GC4767@linux-1> Message-ID: <1131327954.15835.2.camel@c80-216-124-251.cm-upc.chello.se> On Sun, 2005-11-06 at 14:44 +0100, fons adriaensen wrote: > On Sun, Nov 06, 2005 at 12:21:30PM +0000, James Courtier-Dutton wrote: > > > The problem I have is what should I > > display for the 0.0 gain_multiplier setting. I.e. When it effectively > > mutes the sound output at it's minimal slider setting. > > "Off" ??? -inf -- From dmills at spamblock.demon.co.uk Sun Nov 6 21:54:43 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Sun Nov 6 21:54:48 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: References: <436DE22D.2090705@superbug.co.uk> <20051106192419.GY12534@orford.org> Message-ID: <200511070254.44120.dmills@spamblock.demon.co.uk> On Monday 07 November 2005 00:43, Loki Davison wrote: > > My mixer (Ecler HAK320) has selectable curve on all faders, but option > i use is nonlinear, log style which is a very nice feature to > preserve. It's got mute switches as well, but i never use them. > I don't know it, but how do you handle a reasonably busy show without mutes? Almost the most basic form of desk automation is the mute group and I find it very difficult to live without once you get beyond 16 inputs or so. Don't forget the mutes will take out the pre fade sends as well, which just pulling the fader down doesn't. Just curious how anyone can mix without mutes? Regards, Dan. From loki.davison at gmail.com Sun Nov 6 23:05:06 2005 From: loki.davison at gmail.com (Loki Davison) Date: Sun Nov 6 23:05:15 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: <200511070254.44120.dmills@spamblock.demon.co.uk> References: <436DE22D.2090705@superbug.co.uk> <20051106192419.GY12534@orford.org> <200511070254.44120.dmills@spamblock.demon.co.uk> Message-ID: On 11/7/05, Dan Mills wrote: > On Monday 07 November 2005 00:43, Loki Davison wrote: > > > > My mixer (Ecler HAK320) has selectable curve on all faders, but option > > i use is nonlinear, log style which is a very nice feature to > > preserve. It's got mute switches as well, but i never use them. > > > > I don't know it, but how do you handle a reasonably busy show without mutes? > > Almost the most basic form of desk automation is the mute group and I find > it > very difficult to live without once you get beyond 16 inputs or so. > > Don't forget the mutes will take out the pre fade sends as well, which just > > pulling the fader down doesn't. > > Just curious how anyone can mix without mutes? > > Regards, Dan. > I was just adding my opinion from a very different understanding of mixers/mixing. Desk automation vs live dj / turntablist style mixing. Check out http://www.ecler.es/download/img_general_hak320.jpg if you want a pic of it. Notice the curve adjust knobs on the front, one of the interesting points behind me mentioning it. Not that i ever use alsa mixer for this kind of thing ;-) This also explains how i cope without mute groups! 16 inputs would be quite confusing, 3 turntables at once + effects is enough to keep me quite confused/busy ;-) Loki From artemio at kdemail.net Mon Nov 7 06:20:48 2005 From: artemio at kdemail.net (Artemiy Pavlov) Date: Mon Nov 7 06:16:19 2005 Subject: [linux-audio-dev] Juno6 GPL sources Message-ID: <200511071320.48609.artemio@kdemail.net> Dear friends, I have managed to contact the guy (Sebastian Gottschall, brainslayer/at/braincontrol/dot/org) who is converting the UltraMaster Juno6 synth to windows VST format and I got the original sources from them. According to his saying, the original authors allowed him to publish the sources as GPL so there should be no worrying even though each and every file in there contains the old restricting license notice. You will find the sources at my web site: http://artemio.net/projects/juno6/download/source/juno-1.0.1.tar.bz2 I have made an attempt to build Juno6, but AFAIK it is based on glibc 1.x and many C expressions they have are obsolete. But I believe that with some little tweaks the code will compile, though I myself won't be able to help. What I want to ask, is someone interested in resurrecting this nice synthie? First step would be to make it compile with the current feature set. Then see if it's possible to add ALSA MIDI and audio support, and so on (maybe add DSSI too, etc.). I would assist in providing a dedicated web site and hosting for it, no probs. Again, it's a very nice synth with fat and warm sound, I think it really is worth the work. With best wishes, Artemiy. From fredg at salemradiolabs.com Mon Nov 7 08:37:22 2005 From: fredg at salemradiolabs.com (Fred Gleason) Date: Mon Nov 7 08:37:34 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: <200511070254.44120.dmills@spamblock.demon.co.uk> References: <436DE22D.2090705@superbug.co.uk> <200511070254.44120.dmills@spamblock.demon.co.uk> Message-ID: <200511070837.23515.fredg@salemradiolabs.com> On Sunday 06 November 2005 21:54, Dan Mills wrote: > I don't know it, but how do you handle a reasonably busy show without > mutes? Almost the most basic form of desk automation is the mute group and > I find it very difficult to live without once you get beyond 16 inputs or > so. This seems to be one of the differences between regular 'pro-audio/recording' boards and those targeted for use in radio broadcast environments. Similarly, it seems that virtually no 'recording' style board sports a cue buss, while the very thought of trying to run a radio operation without such a buss is enough to induce anxiety in this old 'master control' operator. These are all special features for the broadcasting folks -- available, but unfortunately you usually end up paying a premium for them. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Director of Broadcast Software Development | | | Salem Radio Labs | |-------------------------------------------------------------------------| | A government that is big enough to give you all you want is big enough | | to take it all away. | | -- Barry Goldwater | |-------------------------------------------------------------------------| From pcoccoli at gmail.com Mon Nov 7 12:57:58 2005 From: pcoccoli at gmail.com (Paul Coccoli) Date: Mon Nov 7 12:58:04 2005 Subject: [linux-audio-dev] Juno6 GPL sources In-Reply-To: <200511071320.48609.artemio@kdemail.net> References: <200511071320.48609.artemio@kdemail.net> Message-ID: <8d27a0610511070957q6e55799ej8f08242134c01c7b@mail.gmail.com> On 11/7/05, Artemiy Pavlov wrote: > Dear friends, > > I have managed to contact the guy (Sebastian Gottschall, > brainslayer/at/braincontrol/dot/org) who is converting the UltraMaster Juno6 > synth to windows VST format and I got the original sources from them. > > According to his saying, the original authors allowed him to publish the > sources as GPL so there should be no worrying even though each and every file > in there contains the old restricting license notice. > The original ultramaster source needed a few small fixes to compile with a newer g++, but nothing major. The brainslayer-modified VST sources are hacked beyond repair,in my opinion. I have my doubts about the original code actually being GPL. I wish the ultramaster guys would have released it and their rs-101 as open-source. The rs-101 v2 was a really cool program. > You will find the sources at my web site: > http://artemio.net/projects/juno6/download/source/juno-1.0.1.tar.bz2 > > I have made an attempt to build Juno6, but AFAIK it is based on glibc 1.x and > many C expressions they have are obsolete. But I believe that with some > little tweaks the code will compile, though I myself won't be able to help. > > What I want to ask, is someone interested in resurrecting this nice synthie? > First step would be to make it compile with the current feature set. Then see > if it's possible to add ALSA MIDI and audio support, and so on (maybe add > DSSI too, etc.). I would assist in providing a dedicated web site and hosting > for it, no probs. > I modified my copy of the sources to work with the ALSA sequencer API. It's pretty easy. It also runs fine with jacklaunch. I don't have any interest in maintaining it, but I could send you the ALSA midi patch. > Again, it's a very nice synth with fat and warm sound, I think it really is > worth the work. > > > With best wishes, > Artemiy. > From rlrevell at joe-job.com Mon Nov 7 13:11:02 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Nov 7 13:12:51 2005 Subject: [linux-audio-dev] jack_callback <-> rest of the world In-Reply-To: <20051031014445.37d530fa@mango.fruits.de> References: <4af8d6ff0510291542n29a79db3p@mail.gmail.com> <1130641420.2785.10.camel@localhost.localdomain> <20051030121118.213f6863@mango.fruits.de> <20051030123641.GB4959@linux-1> <20051030135348.79d64d5b@mango.fruits.de> <20051030131419.GC4959@linux-1> <20051031014445.37d530fa@mango.fruits.de> Message-ID: <1131387062.8383.78.camel@mindpipe> On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote: > Btw: i just discovered that pthread mutexes and condvars can have a > "process shared" flag which makes it possiblo to synchronize threads > across processes as it seems. Could be useful for jack, no? > > pthread_condvar_setpshared() > pthread_mutexattr_setpshared() > > Or do i misread that manpage? What manpage? Got a link? These are completely undocumented on my Ubuntu 5.10 system. As a matter of fact, there is no documentation whatsoever for NPTL - all the pthread man pages say "LinuxThreads" at the bottom. I'm really getting sick of the half-assed pthread support on Debian based systems. Anyone got a recommendation for a better distro? Lee From dmills at spamblock.demon.co.uk Mon Nov 7 14:17:10 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Mon Nov 7 14:17:30 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: References: <436DE22D.2090705@superbug.co.uk> <200511070254.44120.dmills@spamblock.demon.co.uk> Message-ID: <200511071917.10243.dmills@spamblock.demon.co.uk> On Monday 07 November 2005 04:05, Loki Davison wrote: > I was just adding my opinion from a very different understanding of > mixers/mixing. Desk automation vs live dj / turntablist style mixing. > Check out http://www.ecler.es/download/img_general_hak320.jpg if you > want a pic of it. Notice the curve adjust knobs on the front, one of > the interesting points behind me mentioning it. Not that i ever use > alsa mixer for this kind of thing ;-) > > This also explains how i cope without mute groups! 16 inputs would be > quite confusing, 3 turntables at once + effects is enough to keep me > quite confused/busy ;-) Ahh, a DJ desk, right that makes more sense now. Actually 16 inputs is a small live desk, 40+ is not uncommon, and if you are working in theatre with lots of radio mics then the mute automation is not optional! Probably the finest example of this sort of thing is a Cadac J type or a DigiCo D5T (Both ?150K++, options). Regards, Dan (And no, I wouldn't use the alsa mixer for this kind of thing either!). From dmills at spamblock.demon.co.uk Mon Nov 7 14:26:17 2005 From: dmills at spamblock.demon.co.uk (Dan Mills) Date: Mon Nov 7 14:26:38 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: <200511070837.23515.fredg@salemradiolabs.com> References: <436DE22D.2090705@superbug.co.uk> <200511070254.44120.dmills@spamblock.demon.co.uk> <200511070837.23515.fredg@salemradiolabs.com> Message-ID: <200511071926.17571.dmills@spamblock.demon.co.uk> On Monday 07 November 2005 13:37, Fred Gleason wrote: > This seems to be one of the differences between regular > 'pro-audio/recording' boards and those targeted for use in radio broadcast > environments. Most serious live sound consoles have half way decent mute automation, and some get very sophisticated about it, see the Cadac J type or even the Yamaha PM5-D for some decent examples. > Similarly, it seems that virtually no 'recording' style board > sports a cue buss, while the very thought of trying to run a radio > operation without such a buss is enough to induce anxiety in this old > 'master control' operator. This might be a specific leftpondia thing, how does the semantics of a 'cue' bus differ from a 'pfl' bus as found on a live sound console? > These are all special features for the > broadcasting folks -- available, but unfortunately you usually end up > paying a premium for them. Actually, I tend to feel that the broadcast specific stuff is more on the lines of removing most of the routing flexibility and eq, and adding some fader start logic (possibly tied into the mute automation)... And yes, you do pay a heavy 'small market' premium! Regards, Dan. From khremeviuc at yahoo.com Mon Nov 7 20:33:15 2005 From: khremeviuc at yahoo.com (Kevin Hremeviuc) Date: Mon Nov 7 20:33:18 2005 Subject: [linux-audio-dev] Juno6 GPL sources In-Reply-To: <8d27a0610511070957q6e55799ej8f08242134c01c7b@mail.gmail.com> Message-ID: <20051108013315.94186.qmail@web60713.mail.yahoo.com> Hi Paul, Can you please put your patches into an email. I got everything to compile after a couple of mods but when I run it I get a seg fault so I just want to see what you modified. Kev --- Paul Coccoli wrote: > On 11/7/05, Artemiy Pavlov > wrote: > > Dear friends, > > > > I have managed to contact the guy (Sebastian > Gottschall, > > brainslayer/at/braincontrol/dot/org) who is > converting the UltraMaster Juno6 > > synth to windows VST format and I got the original > sources from them. > > > > According to his saying, the original authors > allowed him to publish the > > sources as GPL so there should be no worrying even > though each and every file > > in there contains the old restricting license > notice. > > > > The original ultramaster source needed a few small > fixes to compile > with a newer g++, but nothing major. The > brainslayer-modified VST > sources are hacked beyond repair,in my opinion. > > I have my doubts about the original code actually > being GPL. I wish > the ultramaster guys would have released it and > their rs-101 as > open-source. The rs-101 v2 was a really cool > program. > > > You will find the sources at my web site: > > > http://artemio.net/projects/juno6/download/source/juno-1.0.1.tar.bz2 > > > > I have made an attempt to build Juno6, but AFAIK > it is based on glibc 1.x and > > many C expressions they have are obsolete. But I > believe that with some > > little tweaks the code will compile, though I > myself won't be able to help. > > > > What I want to ask, is someone interested in > resurrecting this nice synthie? > > First step would be to make it compile with the > current feature set. Then see > > if it's possible to add ALSA MIDI and audio > support, and so on (maybe add > > DSSI too, etc.). I would assist in providing a > dedicated web site and hosting > > for it, no probs. > > > > I modified my copy of the sources to work with the > ALSA sequencer API. > It's pretty easy. It also runs fine with > jacklaunch. I don't have > any interest in maintaining it, but I could send you > the ALSA midi > patch. > > > Again, it's a very nice synth with fat and warm > sound, I think it really is > > worth the work. > > > > > > With best wishes, > > Artemiy. > > > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From pcoccoli at gmail.com Mon Nov 7 21:32:51 2005 From: pcoccoli at gmail.com (Paul Coccoli) Date: Mon Nov 7 21:33:00 2005 Subject: [linux-audio-dev] Juno6 GPL sources In-Reply-To: <20051108013315.94186.qmail@web60713.mail.yahoo.com> References: <8d27a0610511070957q6e55799ej8f08242134c01c7b@mail.gmail.com> <20051108013315.94186.qmail@web60713.mail.yahoo.com> Message-ID: <8d27a0610511071832o7a2f0d95s5b8bf48207845688@mail.gmail.com> The patch is below. WARNING: I did not test the patch itself. The sources from which it was made have been lying around on my disk for years, so they've almost certainly been altered by the little gremlins that live in my machine and flip bits while I sleep at night. It probably won't apply, and if it does, it will probably cause your computer to explode. You have been warned! It's all an ugly hack by the way, not meant for distribution. Much of it deals with the move from g++-2 to g++-3, the rest is the alsa_seq stuff. It looks like I wrapped my changes in #ifdef USE_ALSA_SEQ but i don't know if I define that in any of the Makefiles. I may have set it on the command line (I'm lazy like that). If I could think of any more disclaimers, I would include them. Perhaps a real Linux audio developer will pick this up, add proper jack support, etc. diff -Naur juno-1.0.1/gmoog/Makefile juno-1.0.1-alsa/gmoog/Makefile --- juno-1.0.1/gmoog/Makefile 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/gmoog/Makefile 2005-11-07 21:46:33.000000000 -0500 @@ -45,7 +45,7 @@ .depend: Makefile touch .depend - makedepend -f .depend $(INCLUDE_DIRS) -I/usr/include/g++-2 $(shell gtk-config --cflags) *.C *.c + makedepend -f .depend $(INCLUDE_DIRS) -I/usr/include/g++-3 $(shell gtk-config --cflags) *.C *.c .PHONY: objs diff -Naur juno-1.0.1/gmoog/Scope.C juno-1.0.1-alsa/gmoog/Scope.C --- juno-1.0.1/gmoog/Scope.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/gmoog/Scope.C 2005-11-07 21:46:33.000000000 -0500 @@ -34,8 +34,8 @@ Scope::Scope() { - addInput( "sync", NULL ); - addInput( "sig", NULL ); + addInput( "sync", (moog_callback_t)NULL ); + addInput( "sig", (moog_callback_t)NULL ); showing = 0; mainWindow = NULL; diff -Naur juno-1.0.1/juno6/juno_synth.C juno-1.0.1-alsa/juno6/juno_synth.C --- juno-1.0.1/juno6/juno_synth.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/juno6/juno_synth.C 2005-11-07 21:46:33.000000000 -0500 @@ -210,7 +210,8 @@ void turnOnArpeggio(bool on) { - MoogObject *target = (on) ? arpeggio : junoControl; + // MoogObject *target = (on) ? arpeggio : junoControl; + MoogObject *target = (MoogObject*)(on) ? (MoogObject*)arpeggio : (MoogObject*)junoControl; if (voice0) voice0->attachVoice(target); diff -Naur juno-1.0.1/juno6/juno_wrappers.C juno-1.0.1-alsa/juno6/juno_wrappers.C --- juno-1.0.1/juno6/juno_wrappers.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/juno6/juno_wrappers.C 2005-11-07 21:46:33.000000000 -0500 @@ -94,7 +94,7 @@ if (midiInput) { - addInput(tmp2, NULL); + addInput(tmp2, (moog_callback_t)NULL); PATCH(midiInput, tmp1, this, tmp2); } pitchOutputs[i] = junoControl->getOutput(tmp2); diff -Naur juno-1.0.1/juno6/Makefile juno-1.0.1-alsa/juno6/Makefile --- juno-1.0.1/juno6/Makefile 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/juno6/Makefile 2005-11-07 21:46:33.000000000 -0500 @@ -3,7 +3,8 @@ GTK_CFLAGS=$(shell gtk-config --cflags) INCLUDE_PATH=-I.. -Iumg/base/include $(GTK_CFLAGS) CPPFLAGS=$(INCLUDE_PATH) $(GTK_CFLAGS) -Wall $(OPTIMIZE) $(DEBUG) $(PROFILE) -LDFLAGS= -L../moog -L../gmoog -L../util -L/usr/local/lib -lgmoog -lmoog -lmoogutil $(shell gtk-config --libs) -lgthread +LDFLAGS= -L../moog -L../gmoog -L../util -L/usr/local/lib -lgmoog -lmoog -lmoogutil $(shell gtk-config --libs) -lgthread -lasound + PROGS=juno6 list_patches copy_patch @@ -37,6 +38,6 @@ .depend: Makefile touch .depend - makedepend -f .depend $(INCLUDE_PATH) -I/usr/include/g++-2 *.C *.c + makedepend -f .depend $(INCLUDE_PATH) -I/usr/include/g++-3 *.C *.c include .depend diff -Naur juno-1.0.1/libgmoog/Makefile juno-1.0.1-alsa/libgmoog/Makefile --- juno-1.0.1/libgmoog/Makefile 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/libgmoog/Makefile 2005-11-07 21:46:33.000000000 -0500 @@ -45,7 +45,7 @@ .depend: Makefile touch .depend - makedepend -f .depend $(INCLUDE_DIRS) -I/usr/include/g++-2 $(shell gtk-config --cflags) *.C *.c + makedepend -f .depend $(INCLUDE_DIRS) -I/usr/include/g++-3 $(shell gtk-config --cflags) *.C *.c .PHONY: objs diff -Naur juno-1.0.1/libgmoog/Scope.C juno-1.0.1-alsa/libgmoog/Scope.C --- juno-1.0.1/libgmoog/Scope.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/libgmoog/Scope.C 2005-11-07 21:46:33.000000000 -0500 @@ -34,8 +34,8 @@ Scope::Scope() { - addInput( "sync", NULL ); - addInput( "sig", NULL ); + addInput( "sync", (moog_callback_t)NULL ); + addInput( "sig", (moog_callback_t)NULL ); showing = 0; mainWindow = NULL; diff -Naur juno-1.0.1/libmoog/IIR2.C juno-1.0.1-alsa/libmoog/IIR2.C --- juno-1.0.1/libmoog/IIR2.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/libmoog/IIR2.C 2005-11-07 21:46:33.000000000 -0500 @@ -25,7 +25,7 @@ cx[0] = cx[1] = cy[0] = cy[1] = 0; x[0] = x[1] = y[0] = y[1] = 0; - addInput("sig", NULL); + addInput("sig", (moog_callback_t)NULL); addOutput("sig", true); output = getOutput(0); diff -Naur juno-1.0.1/libmoog/Makefile juno-1.0.1-alsa/libmoog/Makefile --- juno-1.0.1/libmoog/Makefile 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/libmoog/Makefile 2005-11-07 21:46:33.000000000 -0500 @@ -76,7 +76,7 @@ .depend: Makefile touch .depend - makedepend -f .depend $(INCLUDE_DIRS) -I/usr/include/g++-2 *.C *.c + makedepend -f .depend $(INCLUDE_DIRS) -I/usr/include/g++-3 *.C *.c .PHONY: objs depend diff -Naur juno-1.0.1/libmoog/MidiInput.C juno-1.0.1-alsa/libmoog/MidiInput.C --- juno-1.0.1/libmoog/MidiInput.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/libmoog/MidiInput.C 2005-11-07 21:46:33.000000000 -0500 @@ -26,6 +26,32 @@ #include "Scheduler.h" #include "pitch.h" +#define USE_ALSA_SEQ +#ifdef USE_ALSA_SEQ +#include +snd_seq_t *hseq; + +snd_seq_t *open_seq() { + + snd_seq_t *seq_handle; + int portid; + + if (snd_seq_open(&seq_handle, "hw", SND_SEQ_OPEN_DUPLEX, 0) < 0) { + fprintf(stderr, "Error opening ALSA sequencer.\n"); + exit(1); + } + snd_seq_set_client_name(seq_handle, "j6"); + if ((portid = snd_seq_create_simple_port(seq_handle, "j6", + SND_SEQ_PORT_CAP_WRITE|SND_SEQ_PORT_CAP_SUBS_WRITE, + SND_SEQ_PORT_TYPE_APPLICATION)) < 0) { + fprintf(stderr, "Error creating sequencer port.\n"); + exit(1); + } + return(seq_handle); +} + +#else + #define READ1 if ( !inCommand )\ {\ read( midiFd, &data[ 0 ], 1 );\ @@ -41,6 +67,8 @@ read( midiFd, &data[ 1 ], 1 );\ }\ +#endif + void* midi_input_run( void* data ) { return(((MidiInput *)data)->run()); @@ -56,8 +84,14 @@ pthread_mutex_init(&startStopLock, NULL); lastNote = -1; +#ifndef USE_ALSA_SEQ if ( openDevice( device, MIDI_READ ) < 0 ) return; +#else + if (!(hseq = open_seq())) + return; + midiFd = 99; +#endif addOutput( "bend", false ); @@ -112,6 +146,7 @@ { running = 1; pthread_create( &midiThread, NULL, midi_input_run, this ); + debug(DEBUG_APPMSG1, "Midi thread started"); } pthread_mutex_unlock(&startStopLock); } @@ -129,6 +164,7 @@ pthread_mutex_unlock(&startStopLock); } +#ifndef USE_ALSA_SEQ void* MidiInput::run() { @@ -161,9 +197,9 @@ channel = tmp & 0x0F; inCommand = 0; } - + switch( cmd ) - { + { case MIDI_NOTEOFF: //0x80 READ2; doNoteOff( channel, data[0], data[1] ); @@ -234,6 +270,79 @@ /* not reached */ return( NULL ); } +#else +void* +MidiInput::run() +{ + char ctlName[ 10 ]; //format is "ctl00-000" + + snd_seq_event_t *ev; + + while( running ) + { + snd_seq_event_input(hseq, &ev); + + switch( ev->type ) + { + case SND_SEQ_EVENT_NOTEOFF: //0x80 + doNoteOff( ev->data.control.channel, ev->data.note.note, 0 ); + break; + + case SND_SEQ_EVENT_NOTEON: //0x90 +// debug( DEBUG_APPMSG1, "NOTEON ch=%d note=%d vel=%d\n", ev->data.control.channel, ev->data.note.note, ev->data.note.velocity); + if ( ev->data.note.velocity == 0 ) + { + doNoteOff( ev->data.control.channel, ev->data.note.note, 0 ); + } + else + { + doNoteOn( ev->data.control.channel, ev->data.note.note, + ev->data.note.velocity ); + } + break; + + case SND_SEQ_EVENT_KEYPRESS: //0xA0 +// debug( DEBUG_STATUS, "KEY PRESSURE ch=%d note=%d amount=%d\n", +// channel, cmd, data[ 0 ] ); + break; + + case SND_SEQ_EVENT_CONTROLLER: //0xB0 +// debug( DEBUG_APPMSG1, "CTL ch=%d ctl=%d val=%d\n", ev->data.control.channel, ev->data.control.param, ev->data.control.value); + sprintf( ctlName, "ctl%d-%d", ev->data.control.channel, + ev->data.control.param ); + { + Output* out; + out = MoogObject::getOutput( ctlName ); + if ( out != NULL ) + out->setData( ev->data.control.value / 127.0); + } + + break; + + case SND_SEQ_EVENT_PGMCHANGE: //0xC0 +// debug( DEBUG_STATUS, "PGM_CHANGE %d %d\n", channel, data[ 0 ] ); + break; + + case SND_SEQ_EVENT_CHANPRESS: //0xD0 +// debug( DEBUG_STATUS, "CHN_PRESSURE %d %d\n", channel, data[ 0 ] ); + break; + + case SND_SEQ_EVENT_PITCHBEND: //0xE0 + doPitchBend( ev->data.control.value ); //FIXME: channel? + break; + + default: + //debug( DEBUG_STATUS, "[%d]\n", cmd ); + break; + } + } + + pthread_exit(0); + + /* not reached */ + return( NULL ); +} +#endif void MidiInput::doNoteOn( unsigned int c, unsigned int n, unsigned int v ) diff -Naur juno-1.0.1/libmoog/MoogObject.C juno-1.0.1-alsa/libmoog/MoogObject.C --- juno-1.0.1/libmoog/MoogObject.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/libmoog/MoogObject.C 2005-11-07 21:46:33.000000000 -0500 @@ -53,7 +53,8 @@ if (io == OUTPUT) { - bool continuousOutput = va_arg(va, bool); + //PC bool continuousOutput = va_arg(va, bool); + bool continuousOutput = va_arg(va, int); addOutput(name, continuousOutput); } else diff -Naur juno-1.0.1/libmoog/Oscillator.C juno-1.0.1-alsa/libmoog/Oscillator.C --- juno-1.0.1/libmoog/Oscillator.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/libmoog/Oscillator.C 2005-11-07 21:46:33.000000000 -0500 @@ -46,7 +46,7 @@ init( w ); } -Oscillator::Oscillator( DataBlock* w, double frq, double amp = 1, double zro = 0 ) +Oscillator::Oscillator( DataBlock* w, double frq, double amp, double zro) { init( w ); set( I_OSC_FRQ, frq ); diff -Naur juno-1.0.1/libmoogutil/String.C juno-1.0.1-alsa/libmoogutil/String.C --- juno-1.0.1/libmoogutil/String.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/libmoogutil/String.C 2005-11-07 21:46:33.000000000 -0500 @@ -346,7 +346,8 @@ case 'c': maxlen += 1; - (void)va_arg(ap, char); + //PC (void)va_arg(ap, char); + (void)va_arg(ap, int); break; case 's': diff -Naur juno-1.0.1/Makefile.include juno-1.0.1-alsa/Makefile.include --- juno-1.0.1/Makefile.include 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/Makefile.include 2005-11-07 21:46:33.000000000 -0500 @@ -8,17 +8,18 @@ PROFILE=-pg endif -ifeq ($(USE_DEBUG), n) -DEBUG= -else +#ifeq ($(USE_DEBUG), n) +#DEBUG= +#else DEBUG=-g -endif +#endif -ifeq ($(USE_OPTIMIZE), max) -OPTIMIZE=-O6 -fomit-frame-pointer -m486 -ffast-math -else -OPTIMIZE=-O2 -endif +#ifeq ($(USE_OPTIMIZE), max) +#OPTIMIZE=-O6 -fomit-frame-pointer -m486 -ffast-math +#else +#OPTIMIZE=-O2 +#endif +OPTIMIZE=-O0 CC=gcc diff -Naur juno-1.0.1/moog/IIR2.C juno-1.0.1-alsa/moog/IIR2.C --- juno-1.0.1/moog/IIR2.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/moog/IIR2.C 2005-11-07 21:46:33.000000000 -0500 @@ -25,7 +25,7 @@ cx[0] = cx[1] = cy[0] = cy[1] = 0; x[0] = x[1] = y[0] = y[1] = 0; - addInput("sig", NULL); + addInput("sig", (moog_callback_t)NULL); addOutput("sig", true); output = getOutput(0); diff -Naur juno-1.0.1/moog/Makefile juno-1.0.1-alsa/moog/Makefile --- juno-1.0.1/moog/Makefile 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/moog/Makefile 2005-11-07 21:46:33.000000000 -0500 @@ -76,7 +76,7 @@ .depend: Makefile touch .depend - makedepend -f .depend $(INCLUDE_DIRS) -I/usr/include/g++-2 *.C *.c + makedepend -f .depend $(INCLUDE_DIRS) -I/usr/include/g++-3 *.C *.c .PHONY: objs depend diff -Naur juno-1.0.1/moog/MidiInput.C juno-1.0.1-alsa/moog/MidiInput.C --- juno-1.0.1/moog/MidiInput.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/moog/MidiInput.C 2005-11-07 21:46:33.000000000 -0500 @@ -26,6 +26,32 @@ #include "Scheduler.h" #include "pitch.h" +#define USE_ALSA_SEQ +#ifdef USE_ALSA_SEQ +#include +snd_seq_t *hseq; + +snd_seq_t *open_seq() { + + snd_seq_t *seq_handle; + int portid; + + if (snd_seq_open(&seq_handle, "hw", SND_SEQ_OPEN_DUPLEX, 0) < 0) { + fprintf(stderr, "Error opening ALSA sequencer.\n"); + exit(1); + } + snd_seq_set_client_name(seq_handle, "j6"); + if ((portid = snd_seq_create_simple_port(seq_handle, "j6", + SND_SEQ_PORT_CAP_WRITE|SND_SEQ_PORT_CAP_SUBS_WRITE, + SND_SEQ_PORT_TYPE_APPLICATION)) < 0) { + fprintf(stderr, "Error creating sequencer port.\n"); + exit(1); + } + return(seq_handle); +} + +#else + #define READ1 if ( !inCommand )\ {\ read( midiFd, &data[ 0 ], 1 );\ @@ -41,6 +67,8 @@ read( midiFd, &data[ 1 ], 1 );\ }\ +#endif + void* midi_input_run( void* data ) { return(((MidiInput *)data)->run()); @@ -56,8 +84,14 @@ pthread_mutex_init(&startStopLock, NULL); lastNote = -1; +#ifndef USE_ALSA_SEQ if ( openDevice( device, MIDI_READ ) < 0 ) return; +#else + if (!(hseq = open_seq())) + return; + midiFd = 99; +#endif addOutput( "bend", false ); @@ -112,6 +146,7 @@ { running = 1; pthread_create( &midiThread, NULL, midi_input_run, this ); + debug(DEBUG_APPMSG1, "Midi thread started"); } pthread_mutex_unlock(&startStopLock); } @@ -129,6 +164,7 @@ pthread_mutex_unlock(&startStopLock); } +#ifndef USE_ALSA_SEQ void* MidiInput::run() { @@ -161,9 +197,9 @@ channel = tmp & 0x0F; inCommand = 0; } - + switch( cmd ) - { + { case MIDI_NOTEOFF: //0x80 READ2; doNoteOff( channel, data[0], data[1] ); @@ -234,6 +270,79 @@ /* not reached */ return( NULL ); } +#else +void* +MidiInput::run() +{ + char ctlName[ 10 ]; //format is "ctl00-000" + + snd_seq_event_t *ev; + + while( running ) + { + snd_seq_event_input(hseq, &ev); + + switch( ev->type ) + { + case SND_SEQ_EVENT_NOTEOFF: //0x80 + doNoteOff( ev->data.control.channel, ev->data.note.note, 0 ); + break; + + case SND_SEQ_EVENT_NOTEON: //0x90 +// debug( DEBUG_APPMSG1, "NOTEON ch=%d note=%d vel=%d\n", ev->data.control.channel, ev->data.note.note, ev->data.note.velocity); + if ( ev->data.note.velocity == 0 ) + { + doNoteOff( ev->data.control.channel, ev->data.note.note, 0 ); + } + else + { + doNoteOn( ev->data.control.channel, ev->data.note.note, + ev->data.note.velocity ); + } + break; + + case SND_SEQ_EVENT_KEYPRESS: //0xA0 +// debug( DEBUG_STATUS, "KEY PRESSURE ch=%d note=%d amount=%d\n", +// channel, cmd, data[ 0 ] ); + break; + + case SND_SEQ_EVENT_CONTROLLER: //0xB0 +// debug( DEBUG_APPMSG1, "CTL ch=%d ctl=%d val=%d\n", ev->data.control.channel, ev->data.control.param, ev->data.control.value); + sprintf( ctlName, "ctl%d-%d", ev->data.control.channel, + ev->data.control.param ); + { + Output* out; + out = MoogObject::getOutput( ctlName ); + if ( out != NULL ) + out->setData( ev->data.control.value / 127.0); + } + + break; + + case SND_SEQ_EVENT_PGMCHANGE: //0xC0 +// debug( DEBUG_STATUS, "PGM_CHANGE %d %d\n", channel, data[ 0 ] ); + break; + + case SND_SEQ_EVENT_CHANPRESS: //0xD0 +// debug( DEBUG_STATUS, "CHN_PRESSURE %d %d\n", channel, data[ 0 ] ); + break; + + case SND_SEQ_EVENT_PITCHBEND: //0xE0 + doPitchBend( ev->data.control.value ); //FIXME: channel? + break; + + default: + //debug( DEBUG_STATUS, "[%d]\n", cmd ); + break; + } + } + + pthread_exit(0); + + /* not reached */ + return( NULL ); +} +#endif void MidiInput::doNoteOn( unsigned int c, unsigned int n, unsigned int v ) diff -Naur juno-1.0.1/moog/MoogObject.C juno-1.0.1-alsa/moog/MoogObject.C --- juno-1.0.1/moog/MoogObject.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/moog/MoogObject.C 2005-11-07 21:46:33.000000000 -0500 @@ -53,7 +53,8 @@ if (io == OUTPUT) { - bool continuousOutput = va_arg(va, bool); + //PC bool continuousOutput = va_arg(va, bool); + bool continuousOutput = va_arg(va, int); addOutput(name, continuousOutput); } else diff -Naur juno-1.0.1/moog/Oscillator.C juno-1.0.1-alsa/moog/Oscillator.C --- juno-1.0.1/moog/Oscillator.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/moog/Oscillator.C 2005-11-07 21:46:33.000000000 -0500 @@ -46,7 +46,7 @@ init( w ); } -Oscillator::Oscillator( DataBlock* w, double frq, double amp = 1, double zro = 0 ) +Oscillator::Oscillator( DataBlock* w, double frq, double amp, double zro) { init( w ); set( I_OSC_FRQ, frq ); diff -Naur juno-1.0.1/util/String.C juno-1.0.1-alsa/util/String.C --- juno-1.0.1/util/String.C 2005-11-07 21:46:51.000000000 -0500 +++ juno-1.0.1-alsa/util/String.C 2005-11-07 21:46:33.000000000 -0500 @@ -346,7 +346,8 @@ case 'c': maxlen += 1; - (void)va_arg(ap, char); + //PC (void)va_arg(ap, char); + (void)va_arg(ap, int); break; case 's': From seablade at softhome.net Mon Nov 7 23:48:21 2005 From: seablade at softhome.net (seablade@softhome.net) Date: Mon Nov 7 23:48:27 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: <200511071917.10243.dmills@spamblock.demon.co.uk> References: <436DE22D.2090705@superbug.co.uk> <200511070254.44120.dmills@spamblock.demon.co.uk> <200511071917.10243.dmills@spamblock.demon.co.uk> Message-ID: Apologies for coming in late, but I havent had much time lately;) The main difference I have noticed between broadcast boards and live mix boards is really the lack of output routing in the broadcast board. There is some, but believe me, live mix boards you get a LOT more for the same size board;) VCA style mixing tends to be with live mix consoles, while VCAs themselves I dont think are limited to just them. Mute Groups however are DEFINITLY things you find on upper range Live show consoles, I say upper range to denote that range above Mackie's and lower end soundcrafts or A&H and similar boards. Those same upper range consoles are where you will find the Matrixes and VCA groups that are SO useful in their applications. You can also find some automation capabilities depending on the board as well, digital boards usually but also mute automation on analog. Also I cant remember if the broadcast board I have worked with had an onboard EQ or not, I would almost lean towards no but I cant remember to be honest, it has been a while and I didnt work with it much(A couple of months and that was about it, off and on). And whoever said Mute Groups were a requirement in Larger Live theater shows REALLY wasnt far off. I can get away with matrixes and properly set up groups usually though(32-40 Channel Boards, 20 wireless Mics and a variety of area, sweet spot, etc as well) Seablade From khremeviuc at yahoo.com Tue Nov 8 00:24:02 2005 From: khremeviuc at yahoo.com (Kevin Hremeviuc) Date: Tue Nov 8 00:24:07 2005 Subject: [linux-audio-dev] Juno6 GPL sources In-Reply-To: <8d27a0610511071832o7a2f0d95s5b8bf48207845688@mail.gmail.com> Message-ID: <20051108052402.5581.qmail@web60719.mail.yahoo.com> Hi Paul, Thanks! I was only given 2 errors when compiling which I fixed so it was interesting to see what you had to do. I had a look at the vst version and got that compiling and running a while ago. I think the juno6 will be a nice consolidation project for my newly acquired c++ skills after my exams (c++ this Saturday afternoon) and wife permitting. I've played with the alsa seq thing before so your code will be a nice short cut mechanism. Jack I have yet to really play with properly. Thanks again! Kev --- Paul Coccoli wrote: > The patch is below. > > WARNING: I did not test the patch itself. The > sources from which it > was made have been lying around on my disk for > years, so they've > almost certainly been altered by the little gremlins > that live in my > machine and flip bits while I sleep at night. > > It probably won't apply, and if it does, it will > probably cause your > computer to explode. > > You have been warned! > > It's all an ugly hack by the way, not meant for > distribution. Much of > it deals with the move from g++-2 to g++-3, the rest > is the alsa_seq > stuff. It looks like I wrapped my changes in #ifdef > USE_ALSA_SEQ but > i don't know if I define that in any of the > Makefiles. I may have set > it on the command line (I'm lazy like that). > > If I could think of any more disclaimers, I would > include them. > Perhaps a real Linux audio developer will pick this > up, add proper > jack support, etc. > > diff -Naur juno-1.0.1/gmoog/Makefile > juno-1.0.1-alsa/gmoog/Makefile > --- juno-1.0.1/gmoog/Makefile 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/gmoog/Makefile 2005-11-07 > 21:46:33.000000000 -0500 > @@ -45,7 +45,7 @@ > > .depend: Makefile > touch .depend > - makedepend -f .depend $(INCLUDE_DIRS) > -I/usr/include/g++-2 $(shell > gtk-config --cflags) *.C *.c > + makedepend -f .depend $(INCLUDE_DIRS) > -I/usr/include/g++-3 $(shell > gtk-config --cflags) *.C *.c > > .PHONY: objs > > diff -Naur juno-1.0.1/gmoog/Scope.C > juno-1.0.1-alsa/gmoog/Scope.C > --- juno-1.0.1/gmoog/Scope.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/gmoog/Scope.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -34,8 +34,8 @@ > > Scope::Scope() > { > - addInput( "sync", NULL ); > - addInput( "sig", NULL ); > + addInput( "sync", (moog_callback_t)NULL ); > + addInput( "sig", (moog_callback_t)NULL ); > > showing = 0; > mainWindow = NULL; > diff -Naur juno-1.0.1/juno6/juno_synth.C > juno-1.0.1-alsa/juno6/juno_synth.C > --- juno-1.0.1/juno6/juno_synth.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/juno6/juno_synth.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -210,7 +210,8 @@ > > void turnOnArpeggio(bool on) > { > - MoogObject *target = (on) ? arpeggio : > junoControl; > + // MoogObject *target = (on) ? arpeggio : > junoControl; > + MoogObject *target = (MoogObject*)(on) ? > (MoogObject*)arpeggio : > (MoogObject*)junoControl; > > if (voice0) > voice0->attachVoice(target); > diff -Naur juno-1.0.1/juno6/juno_wrappers.C > juno-1.0.1-alsa/juno6/juno_wrappers.C > --- juno-1.0.1/juno6/juno_wrappers.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/juno6/juno_wrappers.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -94,7 +94,7 @@ > > if (midiInput) > { > - addInput(tmp2, NULL); > + addInput(tmp2, (moog_callback_t)NULL); > PATCH(midiInput, tmp1, this, tmp2); > } > pitchOutputs[i] = junoControl->getOutput(tmp2); > diff -Naur juno-1.0.1/juno6/Makefile > juno-1.0.1-alsa/juno6/Makefile > --- juno-1.0.1/juno6/Makefile 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/juno6/Makefile 2005-11-07 > 21:46:33.000000000 -0500 > @@ -3,7 +3,8 @@ > GTK_CFLAGS=$(shell gtk-config --cflags) > INCLUDE_PATH=-I.. -Iumg/base/include $(GTK_CFLAGS) > CPPFLAGS=$(INCLUDE_PATH) $(GTK_CFLAGS) -Wall > $(OPTIMIZE) $(DEBUG) $(PROFILE) > -LDFLAGS= -L../moog -L../gmoog -L../util > -L/usr/local/lib -lgmoog > -lmoog -lmoogutil $(shell gtk-config --libs) > -lgthread > +LDFLAGS= -L../moog -L../gmoog -L../util > -L/usr/local/lib -lgmoog > -lmoog -lmoogutil $(shell gtk-config --libs) > -lgthread -lasound > + > > PROGS=juno6 list_patches copy_patch > > @@ -37,6 +38,6 @@ > > .depend: Makefile > touch .depend > - makedepend -f .depend $(INCLUDE_PATH) > -I/usr/include/g++-2 *.C *.c > + makedepend -f .depend $(INCLUDE_PATH) > -I/usr/include/g++-3 *.C *.c > > include .depend > diff -Naur juno-1.0.1/libgmoog/Makefile > juno-1.0.1-alsa/libgmoog/Makefile > --- juno-1.0.1/libgmoog/Makefile 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/libgmoog/Makefile 2005-11-07 > 21:46:33.000000000 -0500 > @@ -45,7 +45,7 @@ > > .depend: Makefile > touch .depend > - makedepend -f .depend $(INCLUDE_DIRS) > -I/usr/include/g++-2 $(shell > gtk-config --cflags) *.C *.c > + makedepend -f .depend $(INCLUDE_DIRS) > -I/usr/include/g++-3 $(shell > gtk-config --cflags) *.C *.c > > .PHONY: objs > > diff -Naur juno-1.0.1/libgmoog/Scope.C > juno-1.0.1-alsa/libgmoog/Scope.C > --- juno-1.0.1/libgmoog/Scope.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/libgmoog/Scope.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -34,8 +34,8 @@ > > Scope::Scope() > { > - addInput( "sync", NULL ); > - addInput( "sig", NULL ); > + addInput( "sync", (moog_callback_t)NULL ); > + addInput( "sig", (moog_callback_t)NULL ); > > showing = 0; > mainWindow = NULL; > diff -Naur juno-1.0.1/libmoog/IIR2.C > juno-1.0.1-alsa/libmoog/IIR2.C > --- juno-1.0.1/libmoog/IIR2.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/libmoog/IIR2.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -25,7 +25,7 @@ > cx[0] = cx[1] = cy[0] = cy[1] = 0; > x[0] = x[1] = y[0] = y[1] = 0; > > - addInput("sig", NULL); > + addInput("sig", (moog_callback_t)NULL); > addOutput("sig", true); > > output = getOutput(0); > diff -Naur juno-1.0.1/libmoog/Makefile > juno-1.0.1-alsa/libmoog/Makefile > --- juno-1.0.1/libmoog/Makefile 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/libmoog/Makefile 2005-11-07 > 21:46:33.000000000 -0500 > @@ -76,7 +76,7 @@ > > .depend: Makefile > touch .depend > - makedepend -f .depend $(INCLUDE_DIRS) > -I/usr/include/g++-2 *.C *.c > + makedepend -f .depend $(INCLUDE_DIRS) > -I/usr/include/g++-3 *.C *.c > > > .PHONY: objs depend > diff -Naur juno-1.0.1/libmoog/MidiInput.C > juno-1.0.1-alsa/libmoog/MidiInput.C > --- juno-1.0.1/libmoog/MidiInput.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/libmoog/MidiInput.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -26,6 +26,32 @@ > #include "Scheduler.h" > #include "pitch.h" > > +#define USE_ALSA_SEQ > +#ifdef USE_ALSA_SEQ > +#include > +snd_seq_t *hseq; > + > +snd_seq_t *open_seq() { > + > + snd_seq_t *seq_handle; > + int portid; > + > + if (snd_seq_open(&seq_handle, "hw", > SND_SEQ_OPEN_DUPLEX, 0) < 0) { > + fprintf(stderr, "Error opening ALSA > sequencer.\n"); > + exit(1); > + } > + snd_seq_set_client_name(seq_handle, "j6"); > + if ((portid = > snd_seq_create_simple_port(seq_handle, "j6", > + > SND_SEQ_PORT_CAP_WRITE|SND_SEQ_PORT_CAP_SUBS_WRITE, > + SND_SEQ_PORT_TYPE_APPLICATION)) < 0) { > + fprintf(stderr, "Error creating sequencer > port.\n"); > + exit(1); > + } > + return(seq_handle); > +} > + > +#else > + > #define READ1 if ( !inCommand )\ > {\ > read( midiFd, &data[ 0 ], 1 );\ > @@ -41,6 +67,8 @@ > read( midiFd, &data[ 1 ], 1 );\ > }\ > > +#endif > + > void* midi_input_run( void* data ) > { > return(((MidiInput *)data)->run()); > @@ -56,8 +84,14 @@ > pthread_mutex_init(&startStopLock, NULL); > lastNote = -1; > > +#ifndef USE_ALSA_SEQ > if ( openDevice( device, MIDI_READ ) < 0 ) > return; > +#else > + if (!(hseq = open_seq())) > + return; > + midiFd = 99; > +#endif > > addOutput( "bend", false ); > > @@ -112,6 +146,7 @@ > { > running = 1; > pthread_create( &midiThread, NULL, midi_input_run, > this ); > + debug(DEBUG_APPMSG1, "Midi thread started"); > } > pthread_mutex_unlock(&startStopLock); > } > @@ -129,6 +164,7 @@ > pthread_mutex_unlock(&startStopLock); > } > > +#ifndef USE_ALSA_SEQ > void* > MidiInput::run() > { > @@ -161,9 +197,9 @@ > channel = tmp & 0x0F; > inCommand = 0; > } > - > + > switch( cmd ) > - { > + { > case MIDI_NOTEOFF: //0x80 > READ2; > doNoteOff( channel, data[0], data[1] ); > @@ -234,6 +270,79 @@ > /* not reached */ > return( NULL ); > } > +#else > +void* > +MidiInput::run() > +{ > + char ctlName[ 10 ]; //format is "ctl00-000" > + > + snd_seq_event_t *ev; > + > + while( running ) > + { > + snd_seq_event_input(hseq, &ev); > + > + switch( ev->type ) > + { > + case SND_SEQ_EVENT_NOTEOFF: //0x80 > + doNoteOff( ev->data.control.channel, > ev->data.note.note, 0 ); > + break; > + > + case SND_SEQ_EVENT_NOTEON: //0x90 > +// debug( DEBUG_APPMSG1, "NOTEON ch=%d > note=%d vel=%d\n", > ev->data.control.channel, ev->data.note.note, > ev->data.note.velocity); > + if ( ev->data.note.velocity == 0 ) > + { > + doNoteOff( ev->data.control.channel, > ev->data.note.note, 0 ); > + } > + else > + { > + doNoteOn( ev->data.control.channel, > ev->data.note.note, > + ev->data.note.velocity ); > + } > + break; > + > + case SND_SEQ_EVENT_KEYPRESS: //0xA0 > +// debug( DEBUG_STATUS, "KEY PRESSURE ch=%d > note=%d amount=%d\n", > +// channel, cmd, data[ 0 ] ); > + break; > + > + case SND_SEQ_EVENT_CONTROLLER: //0xB0 > +// debug( DEBUG_APPMSG1, "CTL ch=%d ctl=%d > val=%d\n", > ev->data.control.channel, ev->data.control.param, > ev->data.control.value); > + sprintf( ctlName, "ctl%d-%d", > ev->data.control.channel, > + ev->data.control.param ); > + { > + Output* out; > + out = MoogObject::getOutput( ctlName ); > + if ( out != NULL ) > + out->setData( > ev->data.control.value / 127.0); > + } > + > + break; > + > + case SND_SEQ_EVENT_PGMCHANGE: //0xC0 > +// debug( DEBUG_STATUS, "PGM_CHANGE %d %d\n", > channel, data[ 0 ] ); > + break; > + > + case SND_SEQ_EVENT_CHANPRESS: //0xD0 > +// debug( DEBUG_STATUS, "CHN_PRESSURE %d %d\n", > channel, data[ 0 ] ); > + break; > + > + case SND_SEQ_EVENT_PITCHBEND: //0xE0 > + doPitchBend( ev->data.control.value ); > //FIXME: channel? > + break; > + > + default: > + //debug( DEBUG_STATUS, "[%d]\n", cmd ); > + break; > + } > + } > + > + pthread_exit(0); > + > + /* not reached */ > + return( NULL ); > +} > +#endif > > void > MidiInput::doNoteOn( unsigned int c, unsigned int > n, unsigned int v ) > diff -Naur juno-1.0.1/libmoog/MoogObject.C > juno-1.0.1-alsa/libmoog/MoogObject.C > --- juno-1.0.1/libmoog/MoogObject.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/libmoog/MoogObject.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -53,7 +53,8 @@ > > if (io == OUTPUT) > { > - bool continuousOutput = va_arg(va, bool); > + //PC bool continuousOutput = va_arg(va, > bool); > + bool continuousOutput = va_arg(va, int); > addOutput(name, continuousOutput); > } > else > diff -Naur juno-1.0.1/libmoog/Oscillator.C > juno-1.0.1-alsa/libmoog/Oscillator.C > --- juno-1.0.1/libmoog/Oscillator.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/libmoog/Oscillator.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -46,7 +46,7 @@ > init( w ); > } > > -Oscillator::Oscillator( DataBlock* w, double frq, > double amp = 1, > double zro = 0 ) > +Oscillator::Oscillator( DataBlock* w, double frq, > double amp, double zro) > { > init( w ); > set( I_OSC_FRQ, frq ); > diff -Naur juno-1.0.1/libmoogutil/String.C > juno-1.0.1-alsa/libmoogutil/String.C > --- juno-1.0.1/libmoogutil/String.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/libmoogutil/String.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -346,7 +346,8 @@ > > case 'c': > maxlen += 1; > - (void)va_arg(ap, char); > + //PC (void)va_arg(ap, char); > + (void)va_arg(ap, int); > break; > > case 's': > diff -Naur juno-1.0.1/Makefile.include > juno-1.0.1-alsa/Makefile.include > --- juno-1.0.1/Makefile.include 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/Makefile.include 2005-11-07 > 21:46:33.000000000 -0500 > @@ -8,17 +8,18 @@ > PROFILE=-pg > endif > > -ifeq ($(USE_DEBUG), n) > -DEBUG= > -else > +#ifeq ($(USE_DEBUG), n) > +#DEBUG= > +#else > DEBUG=-g > -endif > +#endif > > -ifeq ($(USE_OPTIMIZE), max) > -OPTIMIZE=-O6 -fomit-frame-pointer -m486 -ffast-math > -else > -OPTIMIZE=-O2 > -endif > +#ifeq ($(USE_OPTIMIZE), max) > +#OPTIMIZE=-O6 -fomit-frame-pointer -m486 > -ffast-math > +#else > +#OPTIMIZE=-O2 > +#endif > +OPTIMIZE=-O0 > > > CC=gcc > diff -Naur juno-1.0.1/moog/IIR2.C > juno-1.0.1-alsa/moog/IIR2.C > --- juno-1.0.1/moog/IIR2.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/moog/IIR2.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -25,7 +25,7 @@ > cx[0] = cx[1] = cy[0] = cy[1] = 0; > x[0] = x[1] = y[0] = y[1] = 0; > > - addInput("sig", NULL); > + addInput("sig", (moog_callback_t)NULL); > addOutput("sig", true); > > output = getOutput(0); > diff -Naur juno-1.0.1/moog/Makefile > juno-1.0.1-alsa/moog/Makefile > --- juno-1.0.1/moog/Makefile 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/moog/Makefile 2005-11-07 > 21:46:33.000000000 -0500 > @@ -76,7 +76,7 @@ > > .depend: Makefile > touch .depend > - makedepend -f .depend $(INCLUDE_DIRS) > -I/usr/include/g++-2 *.C *.c > + makedepend -f .depend $(INCLUDE_DIRS) > -I/usr/include/g++-3 *.C *.c > > > .PHONY: objs depend > diff -Naur juno-1.0.1/moog/MidiInput.C > juno-1.0.1-alsa/moog/MidiInput.C > --- juno-1.0.1/moog/MidiInput.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/moog/MidiInput.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -26,6 +26,32 @@ > #include "Scheduler.h" > #include "pitch.h" > > +#define USE_ALSA_SEQ > +#ifdef USE_ALSA_SEQ > +#include > +snd_seq_t *hseq; > + > +snd_seq_t *open_seq() { > + > + snd_seq_t *seq_handle; > + int portid; > + > + if (snd_seq_open(&seq_handle, "hw", > SND_SEQ_OPEN_DUPLEX, 0) < 0) { > + fprintf(stderr, "Error opening ALSA > sequencer.\n"); > + exit(1); > + } > + snd_seq_set_client_name(seq_handle, "j6"); > + if ((portid = > snd_seq_create_simple_port(seq_handle, "j6", > + > SND_SEQ_PORT_CAP_WRITE|SND_SEQ_PORT_CAP_SUBS_WRITE, > + SND_SEQ_PORT_TYPE_APPLICATION)) < 0) { > + fprintf(stderr, "Error creating sequencer > port.\n"); > + exit(1); > + } > + return(seq_handle); > +} > + > +#else > + > #define READ1 if ( !inCommand )\ > {\ > read( midiFd, &data[ 0 ], 1 );\ > @@ -41,6 +67,8 @@ > read( midiFd, &data[ 1 ], 1 );\ > }\ > > +#endif > + > void* midi_input_run( void* data ) > { > return(((MidiInput *)data)->run()); > @@ -56,8 +84,14 @@ > pthread_mutex_init(&startStopLock, NULL); > lastNote = -1; > > +#ifndef USE_ALSA_SEQ > if ( openDevice( device, MIDI_READ ) < 0 ) > return; > +#else > + if (!(hseq = open_seq())) > + return; > + midiFd = 99; > +#endif > > addOutput( "bend", false ); > > @@ -112,6 +146,7 @@ > { > running = 1; > pthread_create( &midiThread, NULL, midi_input_run, > this ); > + debug(DEBUG_APPMSG1, "Midi thread started"); > } > pthread_mutex_unlock(&startStopLock); > } > @@ -129,6 +164,7 @@ > pthread_mutex_unlock(&startStopLock); > } > > +#ifndef USE_ALSA_SEQ > void* > MidiInput::run() > { > @@ -161,9 +197,9 @@ > channel = tmp & 0x0F; > inCommand = 0; > } > - > + > switch( cmd ) > - { > + { > case MIDI_NOTEOFF: //0x80 > READ2; > doNoteOff( channel, data[0], data[1] ); > @@ -234,6 +270,79 @@ > /* not reached */ > return( NULL ); > } > +#else > +void* > +MidiInput::run() > +{ > + char ctlName[ 10 ]; //format is "ctl00-000" > + > + snd_seq_event_t *ev; > + > + while( running ) > + { > + snd_seq_event_input(hseq, &ev); > + > + switch( ev->type ) > + { > + case SND_SEQ_EVENT_NOTEOFF: //0x80 > + doNoteOff( ev->data.control.channel, > ev->data.note.note, 0 ); > + break; > + > + case SND_SEQ_EVENT_NOTEON: //0x90 > +// debug( DEBUG_APPMSG1, "NOTEON ch=%d > note=%d vel=%d\n", > ev->data.control.channel, ev->data.note.note, > ev->data.note.velocity); > + if ( ev->data.note.velocity == 0 ) > + { > + doNoteOff( ev->data.control.channel, > ev->data.note.note, 0 ); > + } > + else > + { > + doNoteOn( ev->data.control.channel, > ev->data.note.note, > + ev->data.note.velocity ); > + } > + break; > + > + case SND_SEQ_EVENT_KEYPRESS: //0xA0 > +// debug( DEBUG_STATUS, "KEY PRESSURE ch=%d > note=%d amount=%d\n", > +// channel, cmd, data[ 0 ] ); > + break; > + > + case SND_SEQ_EVENT_CONTROLLER: //0xB0 > +// debug( DEBUG_APPMSG1, "CTL ch=%d ctl=%d > val=%d\n", > ev->data.control.channel, ev->data.control.param, > ev->data.control.value); > + sprintf( ctlName, "ctl%d-%d", > ev->data.control.channel, > + ev->data.control.param ); > + { > + Output* out; > + out = MoogObject::getOutput( ctlName ); > + if ( out != NULL ) > + out->setData( > ev->data.control.value / 127.0); > + } > + > + break; > + > + case SND_SEQ_EVENT_PGMCHANGE: //0xC0 > +// debug( DEBUG_STATUS, "PGM_CHANGE %d %d\n", > channel, data[ 0 ] ); > + break; > + > + case SND_SEQ_EVENT_CHANPRESS: //0xD0 > +// debug( DEBUG_STATUS, "CHN_PRESSURE %d %d\n", > channel, data[ 0 ] ); > + break; > + > + case SND_SEQ_EVENT_PITCHBEND: //0xE0 > + doPitchBend( ev->data.control.value ); > //FIXME: channel? > + break; > + > + default: > + //debug( DEBUG_STATUS, "[%d]\n", cmd ); > + break; > + } > + } > + > + pthread_exit(0); > + > + /* not reached */ > + return( NULL ); > +} > +#endif > > void > MidiInput::doNoteOn( unsigned int c, unsigned int > n, unsigned int v ) > diff -Naur juno-1.0.1/moog/MoogObject.C > juno-1.0.1-alsa/moog/MoogObject.C > --- juno-1.0.1/moog/MoogObject.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/moog/MoogObject.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -53,7 +53,8 @@ > > if (io == OUTPUT) > { > - bool continuousOutput = va_arg(va, bool); > + //PC bool continuousOutput = va_arg(va, > bool); > + bool continuousOutput = va_arg(va, int); > addOutput(name, continuousOutput); > } > else > diff -Naur juno-1.0.1/moog/Oscillator.C > juno-1.0.1-alsa/moog/Oscillator.C > --- juno-1.0.1/moog/Oscillator.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/moog/Oscillator.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -46,7 +46,7 @@ > init( w ); > } > > -Oscillator::Oscillator( DataBlock* w, double frq, > double amp = 1, > double zro = 0 ) > +Oscillator::Oscillator( DataBlock* w, double frq, > double amp, double zro) > { > init( w ); > set( I_OSC_FRQ, frq ); > diff -Naur juno-1.0.1/util/String.C > juno-1.0.1-alsa/util/String.C > --- juno-1.0.1/util/String.C 2005-11-07 > 21:46:51.000000000 -0500 > +++ juno-1.0.1-alsa/util/String.C 2005-11-07 > 21:46:33.000000000 -0500 > @@ -346,7 +346,8 @@ > > case 'c': > maxlen += 1; > - (void)va_arg(ap, char); > + //PC (void)va_arg(ap, char); > + (void)va_arg(ap, int); > break; > > case 's': > > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From artemio at kdemail.net Wed Nov 9 02:43:27 2005 From: artemio at kdemail.net (Artemiy Pavlov) Date: Tue Nov 8 02:39:04 2005 Subject: [linux-audio-dev] Juno6 GPL sources In-Reply-To: <20051108052402.5581.qmail@web60719.mail.yahoo.com> References: <20051108052402.5581.qmail@web60719.mail.yahoo.com> Message-ID: <200511090943.27330.artemio@kdemail.net> Hey guys! I am very glad to hear this! The fact that Paul has already added ALSA seq support is really cool. Kevin, could you please mail me the sources so I can try them out? I really miss the Juno6, the binary version will segfault on new distros. Thanks a lot! My plans are to clean up Juno6 as much as possible to make it compilable on most systems, then I'd create a totally new and killer patch bank for it and we could release juno6-2.0 to the public. BTW, as about the VST version, what's neat in it is that it has SysEx support compatible with the original Junos - could you guys have a look at the sources and see if this can be taken? If Juno6 would understand Juno6/60/106 SysEx dumps, that would be fantastic. Thanks to all! Artemiy. From fons.adriaensen at alcatel.be Tue Nov 8 06:35:42 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Tue Nov 8 06:35:50 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: <200511070837.23515.fredg@salemradiolabs.com> References: <436DE22D.2090705@superbug.co.uk> <200511070254.44120.dmills@spamblock.demon.co.uk> <200511070837.23515.fredg@salemradiolabs.com> Message-ID: <20051108113542.GE13682@bth05w.ABSp.alcatel.be> On Mon, Nov 07, 2005 at 08:37:22AM -0500, Fred Gleason wrote: > Similarly, it seems that virtually no 'recording' style board sports a cue > buss, while the very thought of trying to run a radio operation without such > a buss is enough to induce anxiety in this old 'master control' operator. > These are all special features for the broadcasting folks -- available, but > unfortunately you usually end up paying a premium for them. Broadcast consoles have some special features that you would't find on typical music consoles. For broadcast, you will want to be able to listen to something before it goes on air (pfl), while for recording a post-fader solo is much more useful. Another feature you will not find on standard mixers is an N-1 feed (main mix minus one channel), for example to send back over a telephone line, or to a outside broadcast location. On a digital desk all of this *should* just be a matter of configuration. But of course, manufacturers make you pay just for a code that enables the second half of a 1GB memory that was there from the start (Agilent, signal generator). -- FA From seablade at softhome.net Tue Nov 8 07:27:16 2005 From: seablade at softhome.net (seablade@softhome.net) Date: Tue Nov 8 07:27:18 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: <20051108113542.GE13682@bth05w.ABSp.alcatel.be> References: <436DE22D.2090705@superbug.co.uk> <200511070254.44120.dmills@spamblock.demon.co.uk> <200511070837.23515.fredg@salemradiolabs.com> <20051108113542.GE13682@bth05w.ABSp.alcatel.be> Message-ID: Alfons Adriaensen writes: > Broadcast consoles have some special features that you would't > find on typical music consoles. For broadcast, you will want > to be able to listen to something before it goes on air (pfl), > while for recording a post-fader solo is much more useful. > Another feature you will not find on standard mixers is an > N-1 feed (main mix minus one channel), for example to send > back over a telephone line, or to a outside broadcast location. Err live boards do have both pre-fade and post-fade solo/cue busses depending on the board. IN fact it is very useful to pre-cue things as needed or ensure that something is working correctly. The N-1 feature I didnt know about though and is not something I have come across on any live board though. Seablade From fredg at salemradiolabs.com Tue Nov 8 08:14:12 2005 From: fredg at salemradiolabs.com (Fred Gleason) Date: Tue Nov 8 08:14:24 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: <200511071926.17571.dmills@spamblock.demon.co.uk> References: <436DE22D.2090705@superbug.co.uk> <200511070837.23515.fredg@salemradiolabs.com> <200511071926.17571.dmills@spamblock.demon.co.uk> Message-ID: <200511080814.12958.fredg@salemradiolabs.com> On Monday 07 November 2005 14:26, Dan Mills wrote: > This might be a specific leftpondia thing, how does the semantics of a > 'cue' bus differ from a 'pfl' bus as found on a live sound console? A lot of it is in the little ergonomic details: dedent position at fader bottom routes to cue, separate cue audio output, things like that. The separate audio output is important so the mandatory crappy-quality Radio Shack amp can be used with a two inch speaker. This actually serves a real purpose: cruddy sounding audio is immediately recognized as being 'in cue', not part of the air mix. > Actually, I tend to feel that the broadcast specific stuff is more on the > lines of removing most of the routing flexibility and eq, and adding some > fader start logic (possibly tied into the mute automation)... You're dead right about that. The problem with using most production boards for radio control is that they have WWAAAYYYY too many controls. Channel ON/OFF, a fader and some basic buss routing is all most control room boards need or want on for each input channel, and even then I always try automate and bury as much of the buss assignment stuff (e.g. mix-minus generation) as possible. Per-input EQ is another notorious problem area -- there should be *none*, otherwise every source ends up sounding different! All of this, of course, applies mainly to control room boards. The production room is a different story, but there you usually have operators who have at least a clue about what all the little knobs do. :) Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Director of Broadcast Software Development | | | Salem Radio Labs | |-------------------------------------------------------------------------| | "You see, wire telegraph is a kind of very, very long cat. You pull | | his tail in New York and his head is meowing in Los Angeles. Do you | | understand this? And radio operates exactly the same way: you send | | signals here, they receive them there. The only difference is that | | there is no cat." | | | | -- Albert Einstein, upon being asked to describe radio | |-------------------------------------------------------------------------| From aamehl at actcom.net.il Tue Nov 8 17:51:58 2005 From: aamehl at actcom.net.il (Aaron) Date: Tue Nov 8 16:39:29 2005 Subject: [linux-audio-dev] alsa help Message-ID: <1131490318.15610.3.camel@localhost.localdomain> Hi all, Denemo is really lacking alsa support. Unfortunatly Denemo has only one coder who is working a full time job. Is there a kind soul out there who could help implement ALSA support for Denemo. And if you live nearby I would gladly buy you a beer of your choice :) thats if you drink beer... Thanks Aaron From ce at christeck.de Tue Nov 8 18:00:48 2005 From: ce at christeck.de (Christoph Eckert) Date: Tue Nov 8 18:00:46 2005 Subject: [linux-audio-dev] alsa help In-Reply-To: <1131490318.15610.3.camel@localhost.localdomain> References: <1131490318.15610.3.camel@localhost.localdomain> Message-ID: <200511090000.48430.ce@christeck.de> > Denemo is really lacking alsa support. Unfortunatly Denemo has only > one coder who is working a full time job. Is there a kind soul out > there who could help implement ALSA support for Denemo. ?And if you > live nearby I would gladly buy you a beer of your choice :) thats if > you drink beer... maybe http://www.music.mcgill.ca/~gary/rtmidi/ is the right thing for you. Best regards ce From aamehl at actcom.net.il Wed Nov 9 01:41:36 2005 From: aamehl at actcom.net.il (Aaron) Date: Wed Nov 9 00:29:28 2005 Subject: [linux-audio-dev] alsa help In-Reply-To: <200511090000.48430.ce@christeck.de> References: <1131490318.15610.3.camel@localhost.localdomain> <200511090000.48430.ce@christeck.de> Message-ID: <1131518496.3952.3.camel@localhost.localdomain> Thanks Aaron On Wed, 2005-11-09 at 00:00 +0100, Christoph Eckert wrote: > > Denemo is really lacking alsa support. Unfortunatly Denemo has only > > one coder who is working a full time job. Is there a kind soul out > > there who could help implement ALSA support for Denemo. And if you > > live nearby I would gladly buy you a beer of your choice :) thats if > > you drink beer... > > maybe > > http://www.music.mcgill.ca/~gary/rtmidi/ > > is the right thing for you. > > > Best regards > > > ce > > From ce at christeck.de Wed Nov 9 12:15:11 2005 From: ce at christeck.de (Christoph Eckert) Date: Wed Nov 9 12:15:12 2005 Subject: [linux-audio-dev] alsa help In-Reply-To: <1131518496.3952.3.camel@localhost.localdomain> References: <1131490318.15610.3.camel@localhost.localdomain> <200511090000.48430.ce@christeck.de> <1131518496.3952.3.camel@localhost.localdomain> Message-ID: <200511091815.11398.ce@christeck.de> Hi, > > maybe > > > > http://www.music.mcgill.ca/~gary/rtmidi/ > > > > is the right thing for you. please note that it is not GPL; if you want to include it into a GPL application I guess you have to contact the author first. Best regards ce From kouhia at nic.funet.fi Thu Nov 10 09:24:25 2005 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Thu Nov 10 09:24:32 2005 Subject: [linux-audio-dev] Re: Mixer controls Message-ID: >From: James Courtier-Dutton > >It was just an example. The actual range depends on the sound card >hardware, but the typical limit is something like -60 dB or -80 dB. Do you process each channel with audio software prior mixing? If yes, then I would suggest to fix the hardware levels to the optimum level, and use gains only in software. As FA wrote, soundcards most likely do not have click-free mutes and smooth gains. When the hardware is fixed, you may do faded mutes in software with good quality. Fixing the hardware input and output levels makes sense to me. The input devices all have fixed SNR -- it does not help to crank up the soundcard input level as it brings the noise up. The output would be fixed for the same reasons. Also, fixing the output prevents you accidentally damage the speakers and your ears. When you crank up the gain in software, you may have a software limiter prior the monitor outputs. Once I watched when a friend mastered CDs. The fades were auditioned by cranking up the level on the mixer desk. A couple of times happened that the level was not set back to normal position when needed. :-| By fixing the hardware (including external mixer desk) in the audio path, you may have full control with the software. Soundcards are not optimal for listening fades. Only software gain allows one to audition the fades. With hardware gain the sound can be muddy, but most likely your card cannot make +64 dB gains needed in listening the fades. Cards equipped with an user-programmable dsp chip allows one to move the code from the software to the firmware. I'm in understanding that in SB Live all hardware gains are actually software gains. I.e., they have fixed the hardware. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From fons.adriaensen at alcatel.be Thu Nov 10 12:01:39 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Thu Nov 10 12:01:43 2005 Subject: [linux-audio-dev] Re: Mixer controls In-Reply-To: References: Message-ID: <20051110170139.GC15427@bth05w.ABSp.alcatel.be> On Thu, Nov 10, 2005 at 04:24:25PM +0200, Juhana Sadeharju wrote: > Fixing the hardware input and output levels makes sense to me. > The input devices all have fixed SNR -- it does not help to > crank up the soundcard input level as it brings the noise up. > The output would be fixed for the same reasons. It depends a bit on what your sound card is connected to, but I'd say in most cases the card's gain settings should be fixed. The only exceptions maybe are recording a mic or instrument connected directly to the sound card. Once you have an external preamp / mixer or some such, you'll do the gain settings there rather than on the card, and you'll want the card's gain to be calibrated. In my case, I have 8 analog ins and outs from my Terratec, and these are connected to the multitrack tape interface of an external mixing desk. Card levels are fixed and calibrated against the mixer's metering. As it turned out, I just had to set all faders in envy24control to 0dB, as the designers at Terratec had taken care to have standard levels (+4 dBu) in that case. I never touch these settings, and probably even don't have envy24control installed ATM. -- FA From artemio at kdemail.net Thu Nov 10 15:23:06 2005 From: artemio at kdemail.net (Artemiy Pavlov) Date: Thu Nov 10 15:18:41 2005 Subject: [linux-audio-dev] [OT] ALSA Modular can't open ALSA device Message-ID: <200511102223.06603.artemio@kdemail.net> Hello all! Please excuse me for a little off-topic post. I've just upgraded my Mandriva distro from 2005 to 2006, and now AMS won't start: [artemio@localhost ams-1.8.7]$ ams QMultiInputContext::changeInputMethod(): index=0, slave=xim LADSPA_PATH: /usr/lib/ladspa/ loadPath: /home/artemio/audio/patches/AMS/, savePath: /home/artemio/audio/patches/AMS/ Alsa_driver: detected more than 1024 playback channnels, reset to 2. ALSA lib pcm_mmap.c:368:(snd_pcm_mmap) mmap failed: Invalid argument Alsa_driver: can't set playback hardware parameters. Can't connect to ALSA What can this mean? Other audio apps making use of ALSA work just fine (Hydrogen, ZynAddSubFx, etc.). Thanks for any help, Artemiy. From cp_singh at faith.co.jp Thu Nov 10 21:57:58 2005 From: cp_singh at faith.co.jp (chandrasheakhar singh) Date: Thu Nov 10 21:58:21 2005 Subject: [linux-audio-dev] ALSA configuration help and building help References: <1131490318.15610.3.camel@localhost.localdomain><200511090000.48430.ce@christeck.de> <1131518496.3952.3.camel@localhost.localdomain> Message-ID: <003701c5e66b$b8e08c20$4b13a80a@cpsingh> Hi All, I'm new to this forum and need some help to configure ALSA sound support in linux kernel 2.6.11. I have compiled the kernel for ALSA support with following kernel config marco enabled for ALSA support. CONFIG_SOUND=y # Advance Linux Sound Architecture CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_PCM=y CONFIG_SND_SEQUENCER=y CONFIG_SND_VIRMIDI=y After executing the kernel on OMAP 2420 I got the following devices for ALSA in /dev/snd [controlC0 midiC0D0 midiC0D1 midiC0D2 midiC0D3 seq timer] but the snd device which can play the PCM data is not coming up. Can you suggest me why this snd device is not coming up ? Best Regards chandrasheakhar singh From asbjs at stud.ntnu.no Fri Nov 11 09:07:09 2005 From: asbjs at stud.ntnu.no (Asbjørn Sæbø) Date: Fri Nov 11 09:07:14 2005 Subject: [linux-audio-dev] LDAS 0.1.1 Re: [...] LDAS (Low Delay Audio Streamer) 0.1.0 In-Reply-To: <20051102140333.GB3608@stud.ntnu.no> References: <20051102140333.GB3608@stud.ntnu.no> Message-ID: <20051111140709.GB21924@stud.ntnu.no> On Wed, Nov 02, 2005 at 03:03:33PM +0100, Asbj?rn S?b? wrote: > LDAS (Low Delay Audio Streamer) is software for full-duplex > low-latency transmission of audio over IP. This is the first public > release. A version 0.1.1 is now available: . Version 0.1.1 : --------------- * More correct use of the memory mapped access to the sound card when copying data from the queue to the sound card. The code should now be more generic, and work for more sound cards. Asbj?rn From Jan.Weil at web.de Mon Nov 14 09:50:49 2005 From: Jan.Weil at web.de (Jan Weil) Date: Mon Nov 14 09:50:51 2005 Subject: [linux-audio-dev] the Linux-Powered Korg OASYS Message-ID: <1131979849.5944.37.camel@localhost.localdomain> Cheers Jan From hans at fugal.net Mon Nov 14 13:45:29 2005 From: hans at fugal.net (Hans Fugal) Date: Mon Nov 14 13:45:42 2005 Subject: [linux-audio-dev] Channels and best practice Message-ID: <20051114184529.GA10431@falcon.fugal.net> I'm writing a library in ruby for dealing with audio data, and I'm faced with a design decision. For several reasons, the best thing to use in ruby for numerical data is NArray[1] which is implemented in C for efficiency. So my code is basically a wrapper around NArray which gives some more specific functionality. I want to support multichannel data, and this is where the design decision comes. Most of the time I've seen code that handles multichannel information in an interleaved fashion (each frame is consecutive samples in the array), but I have once or twice seen channels placed end-to-end or in different arrays altogether. It will of course be possible to extract and/or merge channels to deal with libraries (e.g. libsndfile, which I will also be wrapping) or existing code that works one way or the other, but I wonder which should be the internal format to use. What are your thoughts? What is best practice on multichannel audio, or is it always application-specific? For a fluctuating peek (think CVS, although I use darcs) into what I'm doing, check out http://hans.fugal.net/src/ruby-audio 1. http://www.ir.isas.ac.jp/~masa/ruby/index-e.html -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051114/5e993caa/attachment.bin From jens.andreasen at chello.se Mon Nov 14 17:05:01 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Nov 14 17:05:08 2005 Subject: [linux-audio-dev] Help? In-Reply-To: <1131979849.5944.37.camel@localhost.localdomain> References: <1131979849.5944.37.camel@localhost.localdomain> Message-ID: <1132005901.27925.48.camel@c80-216-124-251.cm-upc.chello.se> Subject says 'help', this is targetted only at swedish persons, preferably from Stockholm. I have of today been notified that the shitheads living cheaply in my apartement never bothered to pay the electricity bill. The consequence for me being: * No Telephone * No Internet * No Electricity * No Nothing I am *not* asking for money (shit, I'm rich enough), ... only your support that you believe I'm basically a good guy, albeit stupid enough to have been had. :( Oh well, if you are from Stockholm; call kronfogdemyndigheten: 08 458 33 20 and my case is number 108 209-04, and tell them that you do not believe (as far as you know me from the internet) that I would ever have refused to pay my debts! And after that, call Intrum and tell them likewise ... Oh and call Fortum and tell them that the money is coming .. And then? And then you call _me_ and say: Welcome home! ;) And again, it is not the money as such, it is just some corporate principles ... -- mvh // Jens M Andreasen (running out of time, asking for help) From jens.andreasen at chello.se Mon Nov 14 18:34:53 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Mon Nov 14 18:34:58 2005 Subject: [linux-audio-dev] Help? In-Reply-To: <1132005901.27925.48.camel@c80-216-124-251.cm-upc.chello.se> References: <1131979849.5944.37.camel@localhost.localdomain> <1132005901.27925.48.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <1132011293.27925.64.camel@c80-216-124-251.cm-upc.chello.se> On Mon, 2005-11-14 at 23:05 +0100, Jens M Andreasen wrote: > And again, it is not the money as such, it is just some corporate > principles ... ... But since I used to work for banks and the likes, this situation is not a joke for me. Tell me: What bank would hire a guy with apparent debts that he is (apparently) not even trying to pay off? > Now I understand why I can't get a job, but i'm not laughing > -- > mvh // Jens M Andreasen (running out of time, asking for help) My time is running out while you are eating breakfast. > > -- From jamesmichaelmcdermott at gmail.com Tue Nov 15 06:58:46 2005 From: jamesmichaelmcdermott at gmail.com (James McDermott) Date: Tue Nov 15 06:58:50 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <20051114184529.GA10431@falcon.fugal.net> References: <20051114184529.GA10431@falcon.fugal.net> Message-ID: > What are your thoughts? What is best practice on multichannel audio, or > is it always application-specific? According to my experience and understanding: -non-interleaved (multiple channels in separate arrays) is a bit easier to code, but -interleaved could give better performance (because the data you need "now" is all close together in memory). -libsndfile uses interleaved. -plugins (DSSI, LADSPA) use separate arrays. I'm not qualified to talk about best practice, so take with a pinch of salt... From paul at linuxaudiosystems.com Tue Nov 15 07:24:13 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Tue Nov 15 07:21:55 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: References: <20051114184529.GA10431@falcon.fugal.net> Message-ID: <1132057453.9531.88.camel@localhost.localdomain> On Tue, 2005-11-15 at 11:58 +0000, James McDermott wrote: > > What are your thoughts? What is best practice on multichannel audio, or > > is it always application-specific? > > According to my experience and understanding: > > -non-interleaved (multiple channels in separate arrays) is a bit > easier to code, but > -interleaved could give better performance (because the data you need > "now" is all close together in memory). > -libsndfile uses interleaved. > -plugins (DSSI, LADSPA) use separate arrays. it depends whether playback + recording is the only goal, or editing is in the potential workflow. editing interleaved data, especially if there are unrelated signals in different channels that will be treated differently, is really, really hard. if all you do is playback and record, interleaved is marginally more efficient. From jens.andreasen at chello.se Tue Nov 15 08:12:55 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Tue Nov 15 08:13:00 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: References: <20051114184529.GA10431@falcon.fugal.net> Message-ID: <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> On a related subject: How is level one cache replaced with new data, should one (or ones compiler) decide to use some of the prefetch instructions available from Intel PII and up? It would make sense to fetch the next dataset while doing what has to be done "now". On the other hand, overwriting the current dataset is somewhat counter productive. The layout of the data would influence these decisions, no? mvh // Jens M Andreasen On Tue, 2005-11-15 at 11:58 +0000, James McDermott wrote: > > What are your thoughts? What is best practice on multichannel audio, or > > is it always application-specific? > > According to my experience and understanding: > > -non-interleaved (multiple channels in separate arrays) is a bit > easier to code, but > -interleaved could give better performance (because the data you need > "now" is all close together in memory). > -libsndfile uses interleaved. > -plugins (DSSI, LADSPA) use separate arrays. > > I'm not qualified to talk about best practice, so take with a pinch of salt... > -- From fons.adriaensen at alcatel.be Tue Nov 15 08:49:01 2005 From: fons.adriaensen at alcatel.be (Alfons Adriaensen) Date: Tue Nov 15 08:49:09 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> References: <20051114184529.GA10431@falcon.fugal.net> <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> Message-ID: <20051115134901.GA16907@bth05w.ABSp.alcatel.be> On Tue, Nov 15, 2005 at 02:12:55PM +0100, Jens M Andreasen wrote: (good to see you're back on line :-) > On a related subject: How is level one cache replaced with new data, > should one (or ones compiler) decide to use some of the prefetch > instructions available from Intel PII and up? It would make sense to > fetch the next dataset while doing what has to be done "now". On the > other hand, overwriting the current dataset is somewhat counter > productive. Unless you're hand-coding assembly it's probably wisest to leave this to the compiler. OTOH, I've no idea how smart gcc/g++ is in this respect. It could be quite interesting to -S some familiar DSP code and have a look at the result. The only place where I've seen prefetch used explicitly is in Brutefir's sse and 3dnow routines which I recently modified for use in one of my own projects. > The layout of the data would influence these decisions, no? And conversely, considerations relating to cache use (and possible sse optimisations) may influence your choice of data formats. -- FA From hans at fugal.net Tue Nov 15 08:56:38 2005 From: hans at fugal.net (Hans Fugal) Date: Tue Nov 15 08:57:25 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <1132057453.9531.88.camel@localhost.localdomain> References: <20051114184529.GA10431@falcon.fugal.net> <1132057453.9531.88.camel@localhost.localdomain> Message-ID: <20051115135638.GA20702@falcon.fugal.net> On Tue, 15 Nov 2005 at 07:24 -0500, Paul Davis wrote: > On Tue, 2005-11-15 at 11:58 +0000, James McDermott wrote: > > > What are your thoughts? What is best practice on multichannel audio, or > > > is it always application-specific? > > > > According to my experience and understanding: > > > > -non-interleaved (multiple channels in separate arrays) is a bit > > easier to code, but > > -interleaved could give better performance (because the data you need > > "now" is all close together in memory). > > -libsndfile uses interleaved. > > -plugins (DSSI, LADSPA) use separate arrays. > > it depends whether playback + recording is the only goal, or editing is > in the potential workflow. editing interleaved data, especially if there > are unrelated signals in different channels that will be treated > differently, is really, really hard. if all you do is playback and > record, interleaved is marginally more efficient. So marginally more efficient vs. really really hard, it sounds like for a general-purpose lib you'd want seperate channels, eh? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051115/e892b3c2/attachment.bin From jens.andreasen at chello.se Tue Nov 15 12:06:29 2005 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Tue Nov 15 12:06:34 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <20051115134901.GA16907@bth05w.ABSp.alcatel.be> References: <20051114184529.GA10431@falcon.fugal.net> <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> <20051115134901.GA16907@bth05w.ABSp.alcatel.be> Message-ID: <1132074390.27925.143.camel@c80-216-124-251.cm-upc.chello.se> > > On a related subject: How is level one cache replaced with new data, > > should one (or ones compiler) decide to use some of the prefetch > > instructions available from Intel PII and up? It would make sense to > > fetch the next dataset while doing what has to be done "now". On the > > other hand, overwriting the current dataset is somewhat counter > > productive. > > Unless you're hand-coding assembly it's probably wisest to leave this > to the compiler. OTOH, I've no idea how smart gcc/g++ is in this respect. > It could be quite interesting to -S some familiar DSP code and have a > look at the result. >From what I understand gcc 4.x will recognize float x[n] = float y[n] * float z[n], and do sse as good as the next person. How far it will dive into other goodies in sse/altivec, I dunno. Apple used to have some advice on portable gcc vector programming but I can't find it in the latest revision. There is a general discussion here, well worth reading: http://developer.apple.com/hardware/ve/simd.html I am still on gcc 3.4 though. It will use the sse unit for scalar floats (if you ask politely), more on this later. About prefetch, I can say that this gcc will not recognize a linked list in a doforall loop. Perhaps looping thru an array could help? Hey, and isn't this where all these hot diodes in modern hardware is supposed to look ahead and recognize a pointer being incremented? Speculatively fetching instructions to fill the pipe without also getting the data makes no sense, that would just stall execution. Mmmm ... wait a second. Speculatively fetching a load will eventually get you the data also. OK, so the system works :) I am on a PIII these days, and this one has only a very small window of opportunity where it can shuffle instructions around. Actually it feels more like marketing bull since nothing much happens without interleaving what you are doing right now with what you have (almost) done and what you are about to do next. > The only place where I've seen prefetch used explicitly is in Brutefir's > sse and 3dnow routines which I recently modified for use in one of my own > projects. > > > The layout of the data would influence these decisions, no? > > And conversely, considerations relating to cache use (and possible sse > optimisations) may influence your choice of data formats. > I said more on scalar sse floats later? If you think this code snippet looks funny: if(x == 0.0) x = 0.0; ... then wait untill you take it away from the code attached below, and watch execution time more than double up. (And no, it is not the missing cast to float.) Don't ask! I have no idea how I could dream up that expression ... There is some unfinished work in the function: int set_DAZ_and_FTZ(int on) .. where I do not recognize an (early) AMD k8. Anybody care to enlighten me? mvh // Jens M Andreasen (still fighting the man.) -- -------------- next part -------------- A non-text attachment was scrubbed... Name: junk.c Type: text/x-csrc Size: 2883 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20051115/c62c9ad2/junk.bin From mista.tapas at gmx.net Tue Nov 15 18:05:59 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Nov 15 18:06:12 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <20051115134901.GA16907@bth05w.ABSp.alcatel.be> References: <20051114184529.GA10431@falcon.fugal.net> <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> <20051115134901.GA16907@bth05w.ABSp.alcatel.be> Message-ID: <20051116000559.680790d9@mango.fruits.de> On Tue, 15 Nov 2005 14:49:01 +0100 Alfons Adriaensen wrote: > The only place where I've seen prefetch used explicitly is in Brutefir's > sse and 3dnow routines which I recently modified for use in one of my own > projects. I think libDSP does prefetch and cache alignment, SIMD, yadayada :) http://libdsp.sourceforge.net/overview.html I don't know though to which degree each one of the functions is optimized. Best to ask Jussi himself (CC'ed) :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From luisgarrido at users.sourceforge.net Wed Nov 16 15:40:21 2005 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Wed Nov 16 15:40:24 2005 Subject: [linux-audio-dev] LADSPA, GUIs, OSC and LADSPA_HINT_SAMPLE_RATE Message-ID: Hi! I am working on a GUI designing tool for LADSPA/DSSI around Qt designer. The idea is to extend the DSSI gui concept to LADSPA (OSC control included) and provide a skinnable tool to manually design GUIs. I plan also to include some user interaction enhancements. You can see some fancy concept diagram here http://flam.sourceforge.net/ There is some code behind it, too, but at the moment its structure is fluctuating and no effort of autotoolization/sconification has been done. There is a working skinnable slider and flamwizard is half finished. The skinnability will by provided by means of QStyle plugins. You can have very minimalistic depictions of the UI gadgets or hardware panel simulations. The GUI viewer, called flammer, will allow for loading/saving presets and load alternate GUI layouts for a given plugin at runtime. Now I have a doubt about LADSPA_HINT_SAMPLE_RATE. To effectively incorporate this hinting in the GUI, the host must have some means of letting know the GUI what the current sample rate is. Is there any standard procedure for achieving this? Comments, ideas, please? Cheers, Luis From S.W.Harris at ecs.soton.ac.uk Wed Nov 16 16:07:49 2005 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Wed Nov 16 16:08:16 2005 Subject: [linux-audio-dev] LADSPA, GUIs, OSC and LADSPA_HINT_SAMPLE_RATE In-Reply-To: References: Message-ID: <20051116210748.GE32656@login.ecs.soton.ac.uk> On Wed, Nov 16, 2005 at 09:40:21 +0100, Luis Garrido wrote: > Now I have a doubt about LADSPA_HINT_SAMPLE_RATE. To effectively > incorporate this hinting in the GUI, the host must have some means of > letting know the GUI what the current sample rate is. Is there any > standard procedure for achieving this? No, I dont think there is, and thats a good point. We forgot about that when we designed DSSI. The intnertion was that it would be possible to build generic GUI tools. I guess it should be added to the list of things sent when the UI requests its initial state dump. /sample-rate seems reaonsable. - Steve From drobilla at connect.carleton.ca Wed Nov 16 22:01:57 2005 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Nov 16 22:15:46 2005 Subject: [linux-audio-dev] LADSPA, GUIs, OSC and LADSPA_HINT_SAMPLE_RATE In-Reply-To: References: Message-ID: <1132196517.2956.7.camel@localhost.localdomain> On Wed, 2005-16-11 at 21:40 +0100, Luis Garrido wrote: > Hi! > > I am working on a GUI designing tool for LADSPA/DSSI around Qt > designer. The idea is to extend the DSSI gui concept to LADSPA (OSC > control included) and provide a skinnable tool to manually design > GUIs. I plan also to include some user interaction enhancements. ... you do realize that DSSI pretty much _IS_ OSC using GUIs bolted on to LADSPA plugins, right? :) -DR- From clemens at ladisch.de Thu Nov 17 02:20:40 2005 From: clemens at ladisch.de (Clemens Ladisch) Date: Thu Nov 17 02:21:24 2005 Subject: [linux-audio-dev] ALSA configuration help and building help In-Reply-To: <003701c5e66b$b8e08c20$4b13a80a@cpsingh> References: <1131490318.15610.3.camel@localhost.localdomain> <200511090000.48430.ce@christeck.de> <1131518496.3952.3.camel@localhost.localdomain> <003701c5e66b$b8e08c20$4b13a80a@cpsingh> Message-ID: <1132212040.437c2f48ed187@webmail.uni-halle.de> chandrasheakhar singh wrote: > After executing the kernel on OMAP 2420 I got the following devices for > ALSA in /dev/snd [controlC0 midiC0D0 midiC0D1 midiC0D2 midiC0D3 seq > timer] but the snd > device which can play the PCM data is not coming up. Looks like a bug in the driver (you didn't tell us which one). HTH Clemens From S.W.Harris at ecs.soton.ac.uk Thu Nov 17 02:59:06 2005 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Nov 17 02:59:14 2005 Subject: [linux-audio-dev] LADSPA, GUIs, OSC and LADSPA_HINT_SAMPLE_RATE In-Reply-To: <1132196517.2956.7.camel@localhost.localdomain> References: <1132196517.2956.7.camel@localhost.localdomain> Message-ID: <20051117075906.GA16919@login.ecs.soton.ac.uk> On Thu, Nov 17, 2005 at 02:01:57 +1100, Dave Robillard wrote: > On Wed, 2005-16-11 at 21:40 +0100, Luis Garrido wrote: > > Hi! > > > > I am working on a GUI designing tool for LADSPA/DSSI around Qt > > designer. The idea is to extend the DSSI gui concept to LADSPA (OSC > > control included) and provide a skinnable tool to manually design > > GUIs. I plan also to include some user interaction enhancements. > > ... you do realize that DSSI pretty much _IS_ OSC using GUIs bolted on > to LADSPA plugins, right? :) Right infact several of the DSSI hosts will also host LADSPA plugins with UIs. It was part of my agenda to sneak defacto LADSPA UIs in by the backdoor when we designed DSSI. BTW there is nothing specifically Graphical about the UI spec, it could just as easily be used to write control interfaces that use motories fader boxes, braile terminals, and any other i/o device. Voice controlled effects anyone ;) - Steve From luisgarrido at users.sourceforge.net Thu Nov 17 11:20:01 2005 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Thu Nov 17 11:20:05 2005 Subject: [DSSI] Re: [linux-audio-dev] LADSPA, GUIs, OSC and LADSPA_HINT_SAMPLE_RATE In-Reply-To: <20051116210748.GE32656@login.ecs.soton.ac.uk> References: <20051116210748.GE32656@login.ecs.soton.ac.uk> Message-ID: > I guess it should be added to the list of things sent when the UI > requests its initial state dump. /sample-rate seems reaonsable. > It does. And what about OSC support for a "bypass" toggle button? Luis From conrad.berhoerster at gmx.de Thu Nov 17 13:02:19 2005 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Thu Nov 17 13:06:37 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <20051102183522.437d234b@mango.fruits.de> References: <200511021530.49189.conrad.berhoerster@gmx.de> <20051102183522.437d234b@mango.fruits.de> Message-ID: <200511171902.19965.conrad.berhoerster@gmx.de> Thanks florian, this gave a lot of insight. Am Mittwoch 02 November 2005 18:35 schrieb Florian Schmidt: > > Well, yeah. First of all your question is very unprecise. I will try to > guess the blanks. Sorry for that. your guessing was quiet right. > > 1) you are probably talking about jackd as most other alsa apps don't > even report their xruns ever thought xrun is a jack thing > > 2) you are probably not running a realtime preemption or other low > latency kernel > > 3) you are not running jack with the realtime flag (-R) > ok i have done that. > The reason for an xrun is basically: > > The process consuming/producing audio did not do this fast enough (Audio > is processed in chunks and you have the time equivalent to one chunk of > audio to produce/consume it). > > This can have many reasons: > > - you ask too much of your computer (like the computations involved are > simply too complex). This would produce a constant stream of xruns > though. I suppose you probably see much less then 1 per > periodsize/samplerate sec. > > - this is the more probable reason: Some other process on your system > kept your audio producing/consuming process from doing its thang. > fixed > This second one can be remedied by changing step 2 and 3 above. > > There's two more potential reasons which i can think of right now: > > 4) your jack tmpfs is not mounted on a tmpfs or shmfs filesystem > fixed > 5) NPTL hell (google for this one) > > Have fun, > Flo my app runs quite right, in the normal play mode. then i started adding some effects. after adding 6 x 31 band eqs i have tons of xruns. but the cpu is only at 60% . A friend of mine told me, this can be because of the usage of only one jack buffer. this means - get jack callback - get the buffer from jack - fill the buffer with data - copy it back to jack is there a way to specify more than one buffer with jack ( like direct sound ) or do i need the ringbuffer. maybe someone can give my a link to an example. thanks c~ From rncbc at rncbc.org Sat Nov 19 14:00:07 2005 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Sat Nov 19 13:58:43 2005 Subject: [linux-audio-dev] [ANN] QjackCtl 0.2.19 released! Message-ID: <437F7637.5070307@rncbc.org> Hi, QjackCtl 0.2.19 has been released. The Qt(cutie)-based GUI control panel for the JACK Audio Connection Kit service has come of age. You can grab it right away from the "official" home site: http://qjackctl.sourceforge.net Release notes as taken straight from the change-log: - Connections widget views are now properly refreshed after renaming client/ports (aliases). - Disabled system tray and ALSA sequencer support on configure time, whenever building for MacOSX as default. - Fixed the major issues with selecting an audio interface on Mac OSX; the button the right of the interface combo is now much better looking than it was before; input/output channel counts are also updated automatically now (thanks to Jesse Chappell for the patch). - Prevent the setting of the coreaudio device id on the jackd command line (-n) whenever the default interface is being selected. - The connections and patchbay windows are now allowed to have a wider connection lines frame panel; splitter width sizes are now persistent across application sessions (thanks to Filipe Tom?s for the hint). - Activation toggling feedback on the patchbay widget has been fixed; additionally and as found convenient, the most recently used patchbay definitions can now be loaded immediately by selecting from a drop-down list widget, which replaces the old static patchbay name status text, and adds a lil'icon too :) - All widget captions changed to include proper application title prefix. - Attempt to bring those aging autoconf templates to date; sample SPEC file for RPM build is now being included and generated at configure time. - The current selected device is now shown with a checkmark on the device selection menu(s), while on the settings dialog. - Set to use QApplication::setMainWidget() instead of registering the traditional lastWindowClosed() signal to quit() slot, just to let the -geometry command line argument have some effect on X11. Enjoy, -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From jussi.laako at pp.inet.fi Sat Nov 19 17:23:25 2005 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Sat Nov 19 17:23:34 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <20051116000559.680790d9@mango.fruits.de> References: <20051114184529.GA10431@falcon.fugal.net> <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> <20051115134901.GA16907@bth05w.ABSp.alcatel.be> <20051116000559.680790d9@mango.fruits.de> Message-ID: <1132439005.27947.15.camel@vaarlahti.uworld> On Wed, 2005-11-16 at 00:05 +0100, Florian Schmidt wrote: > I think libDSP does prefetch and cache alignment, SIMD, yadayada :) > > I don't know though to which degree each one of the functions is > optimized. Best to ask Jussi himself (CC'ed) :) Most of the time prefetch is left to compiler (works ok most of the time), though it's done manually for some functions. For x86 there is handwritten SIMD (E3DNow! and SSE2/SSE3) version of these operations, automatically used depending on runtime architecture: - Copy - Add - Multiply - Complex multiply - Multiply-add - Complex multiply-add - Add-multiply - Multiply-accumulate - Min-max - Normalized cross-correlation - i16 -> float, i32 -> float conversion - FIR filter - IIR filter Optimized functions are also used as part of more complex functions. All allocations are aligned to required boundary. There are C, C++ and C++ template APIs. Btw. Intel's compiler can vectorize most of the remaining functions and for some even parallelize. Currently the lib is missing autotools stuff, so it's makefile-configured... -- Jussi Laako From drobilla at connect.carleton.ca Sat Nov 19 20:54:11 2005 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sat Nov 19 20:55:10 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <1132439005.27947.15.camel@vaarlahti.uworld> References: <20051114184529.GA10431@falcon.fugal.net> <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> <20051115134901.GA16907@bth05w.ABSp.alcatel.be> <20051116000559.680790d9@mango.fruits.de> <1132439005.27947.15.camel@vaarlahti.uworld> Message-ID: <1132451651.2891.17.camel@localhost.localdomain> On Sun, 2005-20-11 at 00:23 +0200, Jussi Laako wrote: > On Wed, 2005-11-16 at 00:05 +0100, Florian Schmidt wrote: > > I think libDSP does prefetch and cache alignment, SIMD, yadayada :) > > > > I don't know though to which degree each one of the functions is > > optimized. Best to ask Jussi himself (CC'ed) :) > > Most of the time prefetch is left to compiler (works ok most of the > time), though it's done manually for some functions. > > For x86 there is handwritten SIMD (E3DNow! and SSE2/SSE3) version of > these operations, automatically used depending on runtime architecture: [snip] Out of curiosity, how expensive is this runtime architechture check? -DR- From luisgarrido at users.sourceforge.net Sat Nov 19 22:05:40 2005 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Sat Nov 19 22:05:43 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <1132451651.2891.17.camel@localhost.localdomain> References: <20051114184529.GA10431@falcon.fugal.net> <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> <20051115134901.GA16907@bth05w.ABSp.alcatel.be> <20051116000559.680790d9@mango.fruits.de> <1132439005.27947.15.camel@vaarlahti.uworld> <1132451651.2891.17.camel@localhost.localdomain> Message-ID: > Out of curiosity, how expensive is this runtime architechture check? > I don't think runtime detection is necessary if you compile both library and app for the specific arch. A few ifdef's take care of the selection at compile time. If you want to provide a multiarch binary, I don't know how he does it, but you probably only have to check once when the library is first loaded. You link your app against stub functions and then the detection procedure can point the stubs to the right set of functions (via, i.e., function pointers) and from there on no further check is needed, unless you want to provide support for hot swappable cpu's ;) The penalty in this case is an extra level of indirection (a few stack instructions a jump and a ret) for each call. Well worth the pain, IMO. Luis From jussi.laako at pp.inet.fi Sun Nov 20 05:45:34 2005 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Sun Nov 20 05:45:38 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <1132451651.2891.17.camel@localhost.localdomain> References: <20051114184529.GA10431@falcon.fugal.net> <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> <20051115134901.GA16907@bth05w.ABSp.alcatel.be> <20051116000559.680790d9@mango.fruits.de> <1132439005.27947.15.camel@vaarlahti.uworld> <1132451651.2891.17.camel@localhost.localdomain> Message-ID: <1132483534.27947.19.camel@vaarlahti.uworld> On Sun, 2005-11-20 at 12:54 +1100, Dave Robillard wrote: > Out of curiosity, how expensive is this runtime architechture check? It's done only once at initialization time and even there it's matter of < 100 machine instructions. At runtime the cost is doing integer comparison. -- Jussi Laako From James at superbug.co.uk Sun Nov 20 06:22:29 2005 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sun Nov 20 06:22:32 2005 Subject: [linux-audio-dev] Channels and best practice In-Reply-To: <1132483534.27947.19.camel@vaarlahti.uworld> References: <20051114184529.GA10431@falcon.fugal.net> <1132060376.27925.78.camel@c80-216-124-251.cm-upc.chello.se> <20051115134901.GA16907@bth05w.ABSp.alcatel.be> <20051116000559.680790d9@mango.fruits.de> <1132439005.27947.15.camel@vaarlahti.uworld> <1132451651.2891.17.camel@localhost.localdomain> <1132483534.27947.19.camel@vaarlahti.uworld> Message-ID: <43805C75.8060206@superbug.co.uk> Jussi Laako wrote: > On Sun, 2005-11-20 at 12:54 +1100, Dave Robillard wrote: > >>Out of curiosity, how expensive is this runtime architechture check? > > > It's done only once at initialization time and even there it's matter of > < 100 machine instructions. > > At runtime the cost is doing integer comparison. > > For multimedia applications, one crafts a different entire function per CPU type. One then simply uses function pointers to select the best function at init stage. This therefore results in a jump without a comparison. For example, A resampling routine. There is a CPU specific function to handle a block of samples, so the extra "jump" cost is only used per sample block, and not per SIMD instruction. James From paul at linuxaudiosystems.com Sun Nov 20 08:29:37 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sun Nov 20 07:27:39 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <200511171902.19965.conrad.berhoerster@gmx.de> References: <200511021530.49189.conrad.berhoerster@gmx.de> <20051102183522.437d234b@mango.fruits.de> <200511171902.19965.conrad.berhoerster@gmx.de> Message-ID: <1132493377.4482.46.camel@localhost.localdomain> > my app runs quite right, in the normal play mode. then i started adding some > effects. after adding 6 x 31 band eqs i have tons of xruns. but the cpu is > only at 60% . A friend of mine told me, this can be because of the usage of > only one jack buffer. > this means > - get jack callback > - get the buffer from jack > - fill the buffer with data > - copy it back to jack > > is there a way to specify more than one buffer with jack ( like direct sound ) > or do i need the ringbuffer. maybe someone can give my a link to an example. you friend is wrong. JACK's default configuration (2 software buffers or interrupts per hardware buffer) is the same as ASIO. You can use the -n flag or the equivalent control in the setup dialog of qjackctl to get more, but there are many cards that will only accept specific combinations of software buffer counts and sample rate. you may have to experiment to find the best. however, this is not necessarily the right approach to handling xruns. its worth trying. a better start is to check if the xruns go away or occur less frequently with a larger buffer size. --p From ce at christeck.de Sun Nov 20 07:47:26 2005 From: ce at christeck.de (Christoph Eckert) Date: Sun Nov 20 07:46:52 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <1132493377.4482.46.camel@localhost.localdomain> References: <200511021530.49189.conrad.berhoerster@gmx.de> <200511171902.19965.conrad.berhoerster@gmx.de> <1132493377.4482.46.camel@localhost.localdomain> Message-ID: <200511201347.26826.ce@christeck.de> > its worth trying. a better start is to check if the xruns go away or > occur less frequently with a larger buffer size. I even got good results by disabling some hardware (there have been some shared IRQs on my system). cat /proc/interrupts will show you more details. I disabled the nvidia driver and enabled the x-org nv driver. This did help a lot because the nvidia driver shared interrupt 11 with the USB controller (I'm running JACK on top of a USB soundcard). Best regards ce ?Wer Visionen hat, sollte zum Arzt gehen? (Helmut Schmidt) From fons.adriaensen at skynet.be Sun Nov 20 09:02:26 2005 From: fons.adriaensen at skynet.be (fons adriaensen) Date: Sun Nov 20 09:08:00 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <1132493377.4482.46.camel@localhost.localdomain> References: <200511021530.49189.conrad.berhoerster@gmx.de> <20051102183522.437d234b@mango.fruits.de> <200511171902.19965.conrad.berhoerster@gmx.de> <1132493377.4482.46.camel@localhost.localdomain> Message-ID: <20051120140226.GA4978@linux-1> On Sun, Nov 20, 2005 at 08:29:37AM -0500, Paul Davis wrote: > however, this is not necessarily the right approach to handling xruns. > its worth trying. a better start is to check if the xruns go away or > occur less frequently with a larger buffer size. USB cards often work a lot better (allow much smaller buffer sizes) when used with 3 periods instead of 2 when Fs = 48 kHz. Apparently having a total buffer size that is a multiple of 48 helps. -- FA From ce at christeck.de Sun Nov 20 09:23:59 2005 From: ce at christeck.de (Christoph Eckert) Date: Sun Nov 20 09:23:31 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <20051120140226.GA4978@linux-1> References: <200511021530.49189.conrad.berhoerster@gmx.de> <1132493377.4482.46.camel@localhost.localdomain> <20051120140226.GA4978@linux-1> Message-ID: <200511201523.59401.ce@christeck.de> > USB cards often work a lot better (allow much smaller buffer sizes) > when used with 3 periods instead of 2 when Fs = 48 kHz. Apparently > having a total buffer size that is a multiple of 48 helps. I can confirm that by trial and error experiments. Best regards ce From luisgarrido at users.sourceforge.net Sun Nov 20 09:33:37 2005 From: luisgarrido at users.sourceforge.net (Luis Garrido) Date: Sun Nov 20 09:33:40 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <200511201523.59401.ce@christeck.de> References: <200511021530.49189.conrad.berhoerster@gmx.de> <1132493377.4482.46.camel@localhost.localdomain> <20051120140226.GA4978@linux-1> <200511201523.59401.ce@christeck.de> Message-ID: > > USB cards often work a lot better (allow much smaller buffer sizes) > > when used with 3 periods instead of 2 when Fs = 48 kHz. Apparently > > having a total buffer size that is a multiple of 48 helps. > > I can confirm that by trial and error experiments. > Same here. Somewhere I read ALSA USB works better if the buffer is an integer number of milliseconds long (hence the 48 KHz, n * 48 frames buffers). Gr. Luis From mista.tapas at gmx.net Sun Nov 20 10:32:21 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sun Nov 20 10:32:35 2005 Subject: [linux-audio-dev] LASH and LASH_Terminal client flag problem Message-ID: <20051120163221.2db39dd3@mango.fruits.de> Hi, in the course of LASH'ifying jack_convolve i stumbled across the LASH_Terminal client flag which specifies to LASH that the client wants to be run in its own terminal when the session is restored. The code for this is in liblash/loader.c:121 The problem i see is: when the client in the term exits (either by means of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a bash prompt instead of exiting the terminal. For reference i have included the code in question below. I also wonder why it is necessary to start another bash anyways? I tried to remove the extra bash call and use xterm -e command_buffer directly, but then the program doesn't even start correctly. Any other thought on this? static void loader_exec_program_in_xterm(int argc, char **argv) { size_t command_size; char *command_buffer; char *xterm_argv[6]; command_size = get_command_size(argc, argv); command_buffer = lash_malloc(command_size); create_command(command_buffer, argc, argv); xterm_argv[0] = "xterm"; xterm_argv[1] = "-e"; xterm_argv[2] = "bash"; xterm_argv[3] = "-c"; xterm_argv[4] = command_buffer; xterm_argv[5] = NULL; /* execute it */ execvp("xterm", xterm_argv); ... Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From dan.richert at gmail.com Sun Nov 20 23:29:38 2005 From: dan.richert at gmail.com (Dan Richert) Date: Sun Nov 20 23:29:47 2005 Subject: [linux-audio-dev] SMDITools and ESI4000 Message-ID: <43814D32.9080208@gmail.com> hello. I've been trying to get SMDITools working between linux and an E-Mu ESI4000. My sampler is being detected although on the wrong ID (the sampler is set to 4 and it's being detected at 0 ). Whenver I try to receive from or send to the sampler, I'm getting this: *** Error : Out of range *** as the README suggests, i made a symbolic link to /dev/sga from /dev/scsi/host0/bus0/target4/lun4/generic (i've also got sg0 - sg8 in /dev ... could it be looking at those first? ) the only scsi devices i have on the system is the esi4000 and an iomega zip drive between the computer and sampler. iomega drive is set to id 5 (scsi interface is at 7). also, does anybody know of any linux programs that work with the esi4000 file system? it would be great to be able to generate programs/banks. thanks. -d From perni at lysator.liu.se Mon Nov 21 05:34:54 2005 From: perni at lysator.liu.se (Pelle Nilsson) Date: Mon Nov 21 05:35:46 2005 Subject: [linux-audio-dev] SMDITools and ESI4000 In-Reply-To: <43814D32.9080208@gmail.com> (Dan Richert's message of "Sun, 20 Nov 2005 20:29:38 -0800") References: <43814D32.9080208@gmail.com> Message-ID: <87u0e6l25t.fsf@comhem.se> Hi Dan Richert writes: > I've been trying to get SMDITools working between linux and an E-Mu > ESI4000. Me too, once, though I'm afraid I can not help since I do not remember any details on why it failed. > also, does anybody know of any linux programs that work with the esi4000 > file system? it would be great to be able to generate programs/banks. I had some success running ESIWin in WINE, however I am not sure it allows you to manage programs/banks at a level lower than perhaps moving banks between disk images. I tried to use MIDI sample dump instead (slooow). Last time I checked though I was not able to find any tool to do this and I failed to write my own from the specs. Perhaps there is a useful Linux MIDI sample dump utility available now? There are tools available to create Akai sampler images and the esi can read some such images from cd. I do not remember how far I got trying to use this. I was able to make an Akai cd, but I do not remember how much data I could import from it into my esi. The only way I have successfully used to transfer samples from the sampler is saving to floppies and then opening the floppy as raw sound data in a sound editor... /Pelle From mista.tapas at gmx.net Mon Nov 21 21:13:34 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Mon Nov 21 21:13:41 2005 Subject: [linux-audio-dev] LASH and LASH_Terminal client flag problem In-Reply-To: <20051120163221.2db39dd3@mango.fruits.de> References: <20051120163221.2db39dd3@mango.fruits.de> Message-ID: <20051122031334.4211ae91@mango.fruits.de> On Sun, 20 Nov 2005 16:32:21 +0100 Florian Schmidt wrote: > The problem i see is: when the client in the term exits (either by means > of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a > bash prompt instead of exiting the terminal. Hmm, this line seems to be the culprit (liblash/loader.c): #define XTERM_COMMAND_EXTENSION "&& sh || sh" as this basically makes sure the xterm is not exited. So maybe this is even expected behaviour. Hmm, i simply replaced it with "" and am happy now. Maybe this should be made configurable. Perhaps as an option which can be specified when restoring a session (default should be xterms close after the client in them terminates). Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From drobilla at connect.carleton.ca Mon Nov 21 23:34:14 2005 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Mon Nov 21 23:35:18 2005 Subject: [linux-audio-dev] LASH and LASH_Terminal client flag problem In-Reply-To: <20051122031334.4211ae91@mango.fruits.de> References: <20051120163221.2db39dd3@mango.fruits.de> <20051122031334.4211ae91@mango.fruits.de> Message-ID: <1132634055.4175.0.camel@localhost.localdomain> On Tue, 2005-22-11 at 03:13 +0100, Florian Schmidt wrote: > On Sun, 20 Nov 2005 16:32:21 +0100 > Florian Schmidt wrote: > > > The problem i see is: when the client in the term exits (either by means > > of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a > > bash prompt instead of exiting the terminal. > > Hmm, > > this line seems to be the culprit (liblash/loader.c): > > #define XTERM_COMMAND_EXTENSION "&& sh || sh" > > as this basically makes sure the xterm is not exited. So maybe this is > even expected behaviour. Hmm, i simply replaced it with "" and am happy > now. Maybe this should be made configurable. Perhaps as an option which > can be specified when restoring a session (default should be xterms > close after the client in them terminates). I don't know of anyone else actually using the terminal client stuff anyway, so I might just remove that part if there's no objections... -DR- From rlrevell at joe-job.com Tue Nov 22 00:48:50 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Nov 22 00:49:04 2005 Subject: [linux-audio-dev] /. article and paper Message-ID: <1132638530.18511.8.camel@mindpipe> Linked from this article: http://linux.slashdot.org/article.pl?sid=05/11/20/2255217 I found this paper from MontaVista. In addition to being a good high level overview of how modern Linux kernels achieve low latency they give special credit to the Linux audio developer community and Paul Davis's open letter to the kernel developers for driving the evolution of Linux 2.6 into a viable soft RT platform. http://linuxdevices.com/articles/AT9697872711.html Lee From jwoithe at physics.adelaide.edu.au Tue Nov 22 01:37:21 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Tue Nov 22 01:36:39 2005 Subject: [linux-audio-dev] Jack and NPTL (again?) Message-ID: <200511220637.jAM6bMMx027177@auster.physics.adelaide.edu.au> Hi everyone I've recently moved a system over to Slackware 10.2 which utilises NPTL and I'm aware of the issues NPTL has raised in the past. Based on a comment on the Jack website though I sort of assumed that things were now in hand and that Jack had a workaround in place for the issue. Despite this I have found that jackd itself (when run using set_rtlimits) gives an error (-11, EAGAIN) when "creating realtime thread". I have already confirmed that set_rtlimits does operate correctly in the NPTL environment; it appears that for some reason pthread_create flatly refuses to create the RT thread even though the appropriate priority limits are set for the process. The LD_ASSUME_KERNEL hack does make jackd work; however, it would be nice to know what's going on (or whether in fact the problems are still being worked on). Are there any ideas? Interestingly enough, jack applications (ardour for example) do NOT need the LD_ASSUME_KERNEL hack - they start and operate fine without out. Only jack itself appears to have issues. Glibc is 2.3.5, getconf reports "NPTL 2.3.5" and kernel is 2.6.14 plus 2.6.14-rt13. 2.6.14-rc3-rt4 has the same issues. Oddly enough, it appears that under 2.6.13 things work fine even for jackd, but I need to confirm that tonight. Jack command line (from memory): jackd -R -d alsa -d hw:0 -n 4 -p 512 Jackd compiled against 2.6.14 headers with gcc 3.3.6. Kernel compiled with 3.3.6 also. Regards jonathan From mista.tapas at gmx.net Tue Nov 22 14:01:05 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Nov 22 14:01:11 2005 Subject: [linux-audio-dev] LASH and LASH_Terminal client flag problem In-Reply-To: <1132634055.4175.0.camel@localhost.localdomain> References: <20051120163221.2db39dd3@mango.fruits.de> <20051122031334.4211ae91@mango.fruits.de> <1132634055.4175.0.camel@localhost.localdomain> Message-ID: <20051122200105.60a423db@mango.fruits.de> On Tue, 22 Nov 2005 15:34:14 +1100 Dave Robillard wrote: > > this line seems to be the culprit (liblash/loader.c): > > > > #define XTERM_COMMAND_EXTENSION "&& sh || sh" > I don't know of anyone else actually using the terminal client stuff > anyway, so I might just remove that part if there's no objections... Personally i have no objection to removing the XTERM_COMMAND_EXTENSION. There's another issue though with LASH which again might be due to my limited understanding of it. Imagine starting a lash client where you specify a state file on the commandline (i.e. someone sent you a synth patch and you want to use it in one of your projets now). Ok, so you start your synth as mySynth AwesomePatchStateFile This is the commandline LASH will remember for this client app. Now during the course of the LASH session the user chooses to load a different statefile via the apps menu. Then the user chooses to save the LASH prject and then close it (the synth will then save the current statefile to the dir specified by LASH). Now what happens on restore? Well, the client will be started by LASH with the commandline mySynth AwesomePatchStateFile and right after starting up it will get a Restore_Data_File (or whatever it was called) event from LASH which tells it to use a different statefile (the one from the LASH project dir). So basically the client loads two statefiles right after the other. Which is a waste of cpu cycles and might generally be a nuisance for all kinds of reasons. I ardour i try to hack around this by stripping "offending" commandline options from argv before passing it to lash_init.. If this is the recommended way of solving the problem, i'd suggest the docs should be updated to reflect this. For different app designs the solutions might of course look different, so the docs should at least point out the problem. Any thoughts? Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From mista.tapas at gmx.net Tue Nov 22 14:20:14 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Tue Nov 22 14:20:26 2005 Subject: [linux-audio-dev] LASH and LASH_Terminal client flag problem In-Reply-To: <20051122200105.60a423db@mango.fruits.de> References: <20051120163221.2db39dd3@mango.fruits.de> <20051122031334.4211ae91@mango.fruits.de> <1132634055.4175.0.camel@localhost.localdomain> <20051122200105.60a423db@mango.fruits.de> Message-ID: <20051122202014.20c6408f@mango.fruits.de> On Tue, 22 Nov 2005 20:01:05 +0100 Florian Schmidt wrote: > I ardour i try to hack around this by stripping "offending" commandline > options from argv before passing it to lash_init.. Actually this doesn't work right. > so the docs should at least point out the problem This remains though :) So basically apps who save state to files should ignore state files specified on the commandline when in LASH mode, except for those apps that are unable to change the state file selection lateron upon user demand (i.e. little terminal helper tools, that don't have a GUI or other means to load a different state file). Flo -- Palimm Palimm! http://tapas.affenbande.org From drobilla at connect.carleton.ca Wed Nov 23 00:41:35 2005 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Nov 23 00:42:42 2005 Subject: [linux-audio-dev] LASH and LASH_Terminal client flag problem In-Reply-To: <20051122202014.20c6408f@mango.fruits.de> References: <20051120163221.2db39dd3@mango.fruits.de> <20051122031334.4211ae91@mango.fruits.de> <1132634055.4175.0.camel@localhost.localdomain> <20051122200105.60a423db@mango.fruits.de> <20051122202014.20c6408f@mango.fruits.de> Message-ID: <1132724495.4267.8.camel@localhost.localdomain> On Tue, 2005-22-11 at 20:20 +0100, Florian Schmidt wrote: > On Tue, 22 Nov 2005 20:01:05 +0100 > Florian Schmidt wrote: > > > I ardour i try to hack around this by stripping "offending" commandline > > options from argv before passing it to lash_init.. > > Actually this doesn't work right. > > > so the docs should at least point out the problem > > This remains though :) So basically apps who save state to files should > ignore state files specified on the commandline when in LASH mode, > except for those apps that are unable to change the state file selection > lateron upon user demand (i.e. little terminal helper tools, that don't > have a GUI or other means to load a different state file). If it's specified on the command line, why save it as a key and/or file? Pick one. :) I can put something in the docs, but it's a bit obvious and/or app dependant. Ignoring some command line arguments is an acceptable solution, but so is ignoring the configure key and/or file. -DR- From mista.tapas at gmx.net Wed Nov 23 06:55:12 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Wed Nov 23 06:55:18 2005 Subject: [linux-audio-dev] LASH and LASH_Terminal client flag problem In-Reply-To: <1132724495.4267.8.camel@localhost.localdomain> References: <20051120163221.2db39dd3@mango.fruits.de> <20051122031334.4211ae91@mango.fruits.de> <1132634055.4175.0.camel@localhost.localdomain> <20051122200105.60a423db@mango.fruits.de> <20051122202014.20c6408f@mango.fruits.de> <1132724495.4267.8.camel@localhost.localdomain> Message-ID: <20051123125512.1085e74a@mango.fruits.de> On Wed, 23 Nov 2005 16:41:35 +1100 Dave Robillard wrote: > > This remains though :) So basically apps who save state to files should > > ignore state files specified on the commandline when in LASH mode, > > except for those apps that are unable to change the state file selection > > lateron upon user demand (i.e. little terminal helper tools, that don't > > have a GUI or other means to load a different state file). > > If it's specified on the command line, why save it as a key and/or file? > Pick one. :) No, the issue is that the user might very well invoke the client with a commandline option specifying a file when initially adding it to the session. Lateron he changes his mind and uses the app's menu to load a different one. This is all about apps which can _optionally_ specify a file via commandline (like ermmm, almost every single one) at startup. Then there's conflicting state info in LASH making the app load the one state file via commandline first and the other a moment later via the restore event. > I can put something in the docs, but it's a bit obvious and/or app > dependant. Ignoring some command line arguments is an acceptable > solution, but so is ignoring the configure key and/or file. No, ignoring the state file from LASH is IMHO absolutely not an option as this would then mean the session is not restored in that state which the user saved it in. I'd say apps should rather ignore their commandline option when they made a sucessfull LASH connection right at startup. Example usecase: - add seq24 and om/om_gtk to a LASH session. load stuff via the respective menus of the apps. - add jamin to the LASH session and specify a setup file on the commandline - drats, wrong jamin setup. So user selects a different one from the menu. - user hits LASH session save in lash_panel causing ardour to send its session file to LASH and jamin saves its whole setup file into the LASH specified dir. - user closes LASH session - user restores it at some latter time -> here the jamin setup file which was stored in the lash dir should be the only one getting opened. Ignoring the lash data is not really an option. Ignoring the commandline option in the first place is one. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org From conrad.berhoerster at gmx.de Wed Nov 23 07:15:15 2005 From: conrad.berhoerster at gmx.de (conrad =?utf-8?q?berh=C3=B6rster?=) Date: Wed Nov 23 07:14:54 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <1132493377.4482.46.camel@localhost.localdomain> References: <200511021530.49189.conrad.berhoerster@gmx.de> <200511171902.19965.conrad.berhoerster@gmx.de> <1132493377.4482.46.camel@localhost.localdomain> Message-ID: <200511231315.17001.conrad.berhoerster@gmx.de> Am Sonntag 20 November 2005 14:29 schrieb Paul Davis: > > my app runs quite right, in the normal play mode. then i started adding > > some effects. after adding 6 x 31 band eqs i have tons of xruns. but > > the cpu is only at 60% . A friend of mine told me, this can be because of > > the usage of only one jack buffer. > > this means > > - get jack callback > > - get the buffer from jack > > - fill the buffer with data > > - copy it back to jack > > > > is there a way to specify more than one buffer with jack ( like direct > > sound ) or do i need the ringbuffer. maybe someone can give my a link to > > an example. > > you friend is wrong. JACK's default configuration (2 software buffers or > interrupts per hardware buffer) is the same as ASIO. You can use the -n > flag or the equivalent control in the setup dialog of qjackctl to get > more, but there are many cards that will only accept specific > combinations of software buffer counts and sample rate. you may have to > experiment to find the best. > > however, this is not necessarily the right approach to handling xruns. > its worth trying. a better start is to check if the xruns go away or > occur less frequently with a larger buffer size. > > --p hi Paul, thanks to your reply. I think, i should describe my problem more detailed. For a customer, wrote an app for a 5.1 system. The system is slackware box and this terratec phase 28 card. the kernel is a rt patched 2.6.14 All of the 6 channels need to have a 10 -band EQ, an 31-band EQ, and a reverb. Each effect works well if i only use it alone. But if i try to set them up in a chain, i got tons of xruns. the app is (roughly described) implemented as the example clients . as described above, the app only produces the sound only, if it's needed. my inner voices (oh well, lots of them) tell me, that the app doesn't provide enough sounddata to jack. so jack aka ALSA produces an xrun. right ? what puzzles me, is the fact, that the CPU is only at 60% . so there is enough power, to produce the data . The first idea was, to handle one buffer for each channel. this i would do with APIs like DirectSound. But since JACK only handles 2 buffers as default, the app can provide this buffers and copy the data into the JACK buffer. are there any comments for this disposition. How big should this buffers are. and a word to christoph: i had could be a possibility, but IRQ 10 is only used once - from the soundcard. thanks for comments c~ From conrad.berhoerster at gmx.de Wed Nov 23 07:25:16 2005 From: conrad.berhoerster at gmx.de (conrad =?utf-8?q?berh=C3=B6rster?=) Date: Wed Nov 23 07:24:46 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <1132493377.4482.46.camel@localhost.localdomain> References: <200511021530.49189.conrad.berhoerster@gmx.de> <200511171902.19965.conrad.berhoerster@gmx.de> <1132493377.4482.46.camel@localhost.localdomain> Message-ID: <200511231325.16695.conrad.berhoerster@gmx.de> Am Sonntag 20 November 2005 14:29 schrieb Paul Davis: > > my app runs quite right, in the normal play mode. then i started adding > > some effects. after adding 6 x 31 band eqs i have tons of xruns. but > > the cpu is only at 60% . A friend of mine told me, this can be because of > > the usage of only one jack buffer. > > this means > > - get jack callback > > - get the buffer from jack > > - fill the buffer with data > > - copy it back to jack > > > > is there a way to specify more than one buffer with jack ( like direct > > sound ) or do i need the ringbuffer. maybe someone can give my a link to > > an example. > > you friend is wrong. JACK's default configuration (2 software buffers or > interrupts per hardware buffer) is the same as ASIO. You can use the -n > flag or the equivalent control in the setup dialog of qjackctl to get > more, but there are many cards that will only accept specific > combinations of software buffer counts and sample rate. you may have to > experiment to find the best. > > however, this is not necessarily the right approach to handling xruns. > its worth trying. a better start is to check if the xruns go away or > occur less frequently with a larger buffer size. > > --p hi Paul, thanks to your reply. I think, i should describe my problem more detailed. For a customer, wrote an app for a 5.1 system. The system is slackware box and this terratec phase 28 card. ?the kernel is a rt patched 2.6.14 All of the 6 channels need to have a 10 -band EQ, an 31-band ?EQ, and a reverb. Each effect works well if i only use it alone. ?But if i try to set them up in a chain, i got tons of xruns. the app is (roughly described) implemented as the example clients . as described above, the app only produces the sound only, if it's needed. my inner voices (oh well, lots of them) tell me, that ?the app doesn't provide enough sounddata to jack. so jack aka ALSA produces an xrun. right ? what puzzles me, is the fact, that the CPU is only at 60% . so there is enough power, to produce the data . The first idea was, to handle one buffer for each channel. this i would do with APIs like DirectSound. But since JACK only handles 2 buffers as default, the app can provide this buffers and copy the data into the JACK buffer. are there any comments for this disposition. How big should this buffers are. and a word to christoph: i had could be a possibility, but IRQ 10 is only used once - from the soundcard. thanks for comments c~ From paul at linuxaudiosystems.com Wed Nov 23 08:54:21 2005 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Nov 23 07:52:24 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <200511231325.16695.conrad.berhoerster@gmx.de> References: <200511021530.49189.conrad.berhoerster@gmx.de> <200511171902.19965.conrad.berhoerster@gmx.de> <1132493377.4482.46.camel@localhost.localdomain> <200511231325.16695.conrad.berhoerster@gmx.de> Message-ID: <1132754061.26559.44.camel@localhost.localdomain> On Wed, 2005-11-23 at 13:25 +0100, conrad berh?rster wrote: > thanks to your reply. I think, i should describe my problem more detailed. > For a customer, wrote an app for a 5.1 system. The system is slackware box and > this terratec phase 28 card. the kernel is a rt patched 2.6.14 > All of the 6 channels need to have a 10 -band EQ, an 31-band EQ, and a > reverb. Each effect works well if i only use it alone. But if i try to set > them up in a chain, i got tons of xruns. the app is (roughly described) > implemented as the example clients . as described above, the app only > produces the sound only, if it's needed. > > my inner voices (oh well, lots of them) tell me, that the app doesn't provide > enough sounddata to jack. so jack aka ALSA produces an xrun. right ? > what puzzles me, is the fact, that the CPU is only at 60% . so there is enough > power, to produce the data . > The first idea was, to handle one buffer for each channel. this i would do > with APIs like DirectSound. > But since JACK only handles 2 buffers as default, the app can provide this > buffers and copy the data into the JACK buffer. are there any comments for > this disposition. > How big should this buffers are. i don't think it will be easy to help you until we get some terminology fixed. in the ALSA/JACK world: * "buffer size" is the total size of the buffer used by the hardware (measured in frames) [unnamed in DirectSound/ASIO] * "period size" is the number of frames processed by the h/w between interrupts ["buffer size" in DirectSound/ASIO] the buffer size is the period size multiplied by the number of periods. to increase latency and reduce the chance of xruns, you can increase the period size and/or the number of periods. what period size are you using with JACK, and how many periods are you using (this can all be seen within the setup dialog of qjackctl, or from the command line) ? i have no real idea what you mean by "1 buffer per channel". in JACK, every "channel" is represented by a "port", and in every process cycle, your app is expected to read the data from its input ports and fill its output ports. each port has a "buffer" that you can read/write from/to. where do the effects you are using come from? also, 60% CPU is actually not far from the threshold where xruns start to become predictable. the best measure of how hard your system is working comes from the JACK "DSP load" displayed in qjackctl's status window. From our tests on OS X and Linux, once you get to about 80% DSP load, xruns are just around the corner, because of the variance in response time within a general purpose OS (even one with the kinds of RT performance that modern linux and OS X have). so what kind of DSP load do you see? --p From dlphillips at woh.rr.com Wed Nov 23 10:51:08 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed Nov 23 10:36:48 2005 Subject: [linux-audio-dev] Linux soundapps pages updated Message-ID: <43848FEC.4070501@woh.rr.com> Greetings: Once again, the inevitable update: http://linuxsound.atnet.at (Europe) http://linuxsound.jp (Japan) http://linux-sound.org (US) No Musings column this time. :( Lots of nice New Additions. :) Best, dp From rlrevell at joe-job.com Wed Nov 23 14:56:50 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Wed Nov 23 14:57:00 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <200511231325.16695.conrad.berhoerster@gmx.de> References: <200511021530.49189.conrad.berhoerster@gmx.de> <200511171902.19965.conrad.berhoerster@gmx.de> <1132493377.4482.46.camel@localhost.localdomain> <200511231325.16695.conrad.berhoerster@gmx.de> Message-ID: <1132775811.10453.19.camel@mindpipe> On Wed, 2005-11-23 at 13:25 +0100, conrad berh?rster wrote: > the kernel is a rt patched 2.6.14 Try a newer -rt patch, up to -rt4 or -rt5 had serious bugs, also try 2.6.14 vanilla. Lee From drobilla at connect.carleton.ca Wed Nov 23 21:03:51 2005 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Wed Nov 23 21:04:52 2005 Subject: [linux-audio-dev] LASH and LASH_Terminal client flag problem In-Reply-To: <20051123125512.1085e74a@mango.fruits.de> References: <20051120163221.2db39dd3@mango.fruits.de> <20051122031334.4211ae91@mango.fruits.de> <1132634055.4175.0.camel@localhost.localdomain> <20051122200105.60a423db@mango.fruits.de> <20051122202014.20c6408f@mango.fruits.de> <1132724495.4267.8.camel@localhost.localdomain> <20051123125512.1085e74a@mango.fruits.de> Message-ID: <1132797831.3358.4.camel@localhost.localdomain> On Wed, 2005-23-11 at 12:55 +0100, Florian Schmidt wrote: > On Wed, 23 Nov 2005 16:41:35 +1100 > Dave Robillard wrote: > > > > This remains though :) So basically apps who save state to files should > > > ignore state files specified on the commandline when in LASH mode, > > > except for those apps that are unable to change the state file selection > > > lateron upon user demand (i.e. little terminal helper tools, that don't > > > have a GUI or other means to load a different state file). > > > > If it's specified on the command line, why save it as a key and/or file? > > Pick one. :) > > No, the issue is that the user might very well invoke the client with a > commandline option specifying a file when initially adding it to the > session. Lateron he changes his mind and uses the app's menu to load a > different one. This is all about apps which can _optionally_ specify a > file via commandline (like ermmm, almost every single one) at startup. > > Then there's conflicting state info in LASH making the app load the one > state file via commandline first and the other a moment later via the > restore event. > > > I can put something in the docs, but it's a bit obvious and/or app > > dependant. Ignoring some command line arguments is an acceptable > > solution, but so is ignoring the configure key and/or file. > > No, ignoring the state file from LASH is IMHO absolutely not an option > as this would then mean the session is not restored in that state which > the user saved it in. I'd say apps should rather ignore their > commandline option when they made a sucessfull LASH connection right at > startup. > [snip] Yes, ignoring the command line options is probably going to be the Right Thing in most every case. I think a nice easy function to tell if the app is being restored or not would be handy (that takes argv and argc as parameters). It's come up in a couple other cases as well. The only actual problem with LASH itself here seems to be that sometimes apps just need to do different things based on whether they're being restored, or just freshly launched by the user. Thoughts? -DR- From conrad.berhoerster at gmx.de Thu Nov 24 08:30:25 2005 From: conrad.berhoerster at gmx.de (conrad =?utf-8?q?berh=C3=B6rster?=) Date: Thu Nov 24 08:30:16 2005 Subject: [linux-audio-dev] xruns In-Reply-To: <1132754061.26559.44.camel@localhost.localdomain> References: <200511021530.49189.conrad.berhoerster@gmx.de> <200511231325.16695.conrad.berhoerster@gmx.de> <1132754061.26559.44.camel@localhost.localdomain> Message-ID: <200511241430.26594.conrad.berhoerster@gmx.de> Hallo Paul, Am Mittwoch 23 November 2005 14:54 schrieb Paul Davis: > > > where do the effects you are using come from? also, 60% CPU is actually > not far from the threshold where xruns start to become predictable. the > best measure of how hard your system is working comes from the JACK "DSP > load" displayed in qjackctl's status window. From our tests on OS X and > Linux, once you get to about 80% DSP load, xruns are just around the > corner, because of the variance in response time within a general > purpose OS (even one with the kinds of RT performance that modern linux > and OS X have). so what kind of DSP load do you see? > ok, here is my update. i installed qjackctl. i tried to use the system without qjackctl, because i wanted to implement remote via ssh. is there a possibility to get the CPU time and further info just with the standard tools jack_lsp etc. haven't found that. so far i got my CPU info for the command tool top. With jackctl the CPU with jackd -R -dalsa -dhw:0 -r44100 -p1024 -n2 is around 95 % , thats bad, he! i started playing around with the Framesize up to 4096 , but this doesn't have any effect. than i started varify the SampleRate down to 22050. with that i got a CPU around 55% command was jackd -R -dalsa -dhw:0 -r22050 -p1024 -n2 Also, i got tons of xRUNs. today, i try to install the new RT patches as Lee recommended. and for terminology fixing. is there any difference between the CPU/Processor and the DSP in an standard box (not special boards) sizu c~ From conrad.berhoerster at gmx.de Thu Nov 24 10:49:03 2005 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Thu Nov 24 10:48:50 2005 Subject: [linux-audio-dev] Echo Gina3G Message-ID: <200511241649.05822.conrad.berhoerster@gmx.de> Hello all, sorry for crossposting. Is there any experience with the Echo Gina3G card. link: http://www.echoaudio.com/Products/PCI/Gina3G/ thanks c~ From jwoithe at physics.adelaide.edu.au Thu Nov 24 19:40:05 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Thu Nov 24 19:39:11 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required (was: Jack and NPTL (again?)) Message-ID: <200511250040.jAP0e6ab031268@auster.physics.adelaide.edu.au> Hi On Tues Nov 22 I wrote: > I've recently moved a system over to Slackware 10.2 which utilises NPTL and > I'm aware of the issues NPTL has raised in the past. Based on a comment on > the Jack website though I sort of assumed that things were now in hand and > that Jack had a workaround in place for the issue. > > Despite this I have found that jackd itself (when run using set_rtlimits) > gives an error (-11, EAGAIN) when "creating realtime thread". I have since discovered (thanks to strace) that the problem lies in an mmap2() call which requests a size of around 8MB. It appears to be part of the NPTL pthread_create() function. The error returned by mmap2() (EAGAIN) indicates either a locked file or "too much locked memory" (according to the manpage). Because this is an anonymous map the problem must have been the latter. Increasing the "locked memory" limit from 20MB to 40MB made jackd start without having to resort to the LD_ASSUME_KERNEL hack. Another problem then surfaced: with jackd running under NPTL, jack applications using NPTL (eg: ardour) suddenly started to require all of their memory to be lockable. For ardour with a large session this can get quite large (I saw 130MB at one point last night). So, with jackd running with LD_ASSUME_KERNEL = 2.4.19 and a memlock limit of 20MB everything worked and ardour (with NPTL - ie: without LD_ASSUME_KERNEL) was obviously not trying to lock excessive amounts of memory. With jackd running with NPTL and a large enough memlock limit things work but jack clients appear to require much more memory be locked. One thing I will try next is recompiling ardour; perhaps there's something funny there. In any case though, does any of this ring a bell with anyone? Regards jonathan From mista.tapas at gmx.net Thu Nov 24 19:58:06 2005 From: mista.tapas at gmx.net (Florian Schmidt) Date: Thu Nov 24 19:58:11 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required (was: Jack and NPTL (again?)) In-Reply-To: <200511250040.jAP0e6ab031268@auster.physics.adelaide.edu.au> References: <200511250040.jAP0e6ab031268@auster.physics.adelaide.edu.au> Message-ID: <20051125015806.109b985c@mango.fruits.de> On Fri, 25 Nov 2005 11:10:05 +1030 (CST) Jonathan Woithe wrote: > One thing I will try next is recompiling ardour; perhaps there's something > funny there. In any case though, does any of this ring a bell with anyone? Did you try the --unlock jack switch? Flo -- Palimm Palimm! http://tapas.affenbande.org From jwoithe at physics.adelaide.edu.au Thu Nov 24 20:32:53 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Thu Nov 24 20:32:01 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required In-Reply-To: <20051125015806.109b985c@mango.fruits.de> from "Florian Schmidt" at Nov 25, 2005 01:58:06 AM Message-ID: <200511250132.jAP1WsgS032066@auster.physics.adelaide.edu.au> > On Fri, 25 Nov 2005 11:10:05 +1030 (CST) > Jonathan Woithe wrote: > > > One thing I will try next is recompiling ardour; perhaps there's something > > funny there. In any case though, does any of this ring a bell with anyone? > > Did you try the --unlock jack switch? Um, no. To be honest I didn't know about it until you mentioned it. The description of what it does looks like it might assist - I'll give it a go and let you know. OOI, why wasn't this required when jack was not running under NPTL? Thanks for the suggestion. Regards jonathan -- * Jonathan Woithe jwoithe@physics.adelaide.edu.au * * http://www.physics.adelaide.edu.au/~jwoithe * ***-----------------------------------------------------------------------*** ** "Time is an illusion; lunchtime doubly so" ** * "...you wouldn't recognize a subtle plan if it painted itself purple and * * danced naked on a harpsichord singing 'subtle plans are here again'" * From kjetil at ccrma.stanford.edu Fri Nov 25 03:34:50 2005 From: kjetil at ccrma.stanford.edu (Kjetil S. Matheussen) Date: Fri Nov 25 03:35:09 2005 Subject: [linux-audio-dev] [ANN] jack_capture v0.0.1 Message-ID: http://www.notam02.no/arkiv/src/ ABOUT ----- jack_capture is a small simple program to capture whatever sound is going out to your speakers into a file. This is the program I always wanted to have for jack, but no one made. So here it is. USAGE ----- jack_capture [-f filename] [ -b bitdepth ] [-c channels] [ -B bufsize ] Filename is by default auotogenerated to something like "jack_capture_.wav" Bitdepth is by default FLOAT. Channels is by default 2. Bufsize is by default 262144. ACKNOWLEDGMENT -------------- Mostly based on the jackrec program in the jack distribution made by Paul Davies and Jack O'Quin. Automatic filename generation code taken from the timemachine program by Steve Harries. -- From rlrevell at joe-job.com Fri Nov 25 13:43:36 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Nov 25 13:57:35 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required (was: Jack and NPTL (again?)) In-Reply-To: <200511250040.jAP0e6ab031268@auster.physics.adelaide.edu.au> References: <200511250040.jAP0e6ab031268@auster.physics.adelaide.edu.au> Message-ID: <1132944217.20390.25.camel@mindpipe> On Fri, 2005-11-25 at 11:10 +1030, Jonathan Woithe wrote: > I have since discovered (thanks to strace) that the problem lies in an > mmap2() call which requests a size of around 8MB. It appears to be > part of the NPTL pthread_create() function. The error returned by > mmap2() (EAGAIN) indicates either a locked file or "too much locked > memory" (according to the manpage). Because this is an anonymous map > the problem must have been the latter. Increasing the "locked memory" > limit from 20MB to 40MB made jackd start without having to resort to > the LD_ASSUME_KERNEL hack. > I stumbled across the same problem a few weeks ago working on another project. This is glibc allocating an 8MB (!) stack for each thread. It gets the default thread stack size from getrlimit(). With mlockall() you will go OOM really fast like that. The real fix is for JACK to set a reasonable thread stack size in jack_create_thread. You can work around the problem by appending this line to /etc/security/limits.conf: * hard stack 512 for a 512KB stack. As a bonus this will make the footprint of your other threaded apps like Evolution smaller, though those apps don't care as much as their thread stacks are pageable. Lee From rlrevell at joe-job.com Fri Nov 25 21:30:12 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Fri Nov 25 21:30:29 2005 Subject: [linux-audio-dev] set_rtlimit problem Message-ID: <1132972212.7393.8.camel@mindpipe> Hey, I just noticed that the sys_get_priority_max and _min syscalls do not take the RT priority rlimit into account. Since the watchdog thread runs at the -P setting + 10 then if the rlimit is 50 and the user specifies -P50 the watchdog thread will fail. I believe sched_get_priority_max(SCHED_FIFO) needs to take the rlimit into account - there's no other way to get the upper limit AFAICT. Lee From janina at rednote.net Sat Nov 26 08:19:57 2005 From: janina at rednote.net (Janina Sajka) Date: Sat Nov 26 08:20:58 2005 Subject: [linux-audio-dev] hdsploader not doing it In-Reply-To: <87u0gjenie.fsf@quasar.esben-stien.name> References: <20050906003701.GA5034@rednote.net> <87u0gjenie.fsf@quasar.esben-stien.name> Message-ID: <20051126131957.GA13762@rednote.net> Esben Stien writes: > Janina Sajka writes: > > > Regret to report I am having problems loading firmware for my > > multiface again. > > You still having problems? Hi: Sorry for the slow response. I've been swamped and off lists recently. I found the fix about two weeks ago. It's simple--but think it should be noted, and perhaps documented with the driver. Everything works if I put snd-hdsp in my initrd.img. So, it's that old low memory req again. Now, why didn't I think of that sooner? Janina > > -- > Esben Stien is b0ef@e s a > http://www. s t n m > irc://irc. b - i . e/%23contact > [sip|iax]: e e > jid:b0ef@ n n -- Janina Sajka Phone: +1.240.715.1272 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://www.ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina@freestandards.org http://a11y.org From rncbc at rncbc.org Sun Nov 27 14:59:55 2005 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Sun Nov 27 14:58:05 2005 Subject: [linux-audio-dev] [ANN] QjackCtl 0.2.19a fix released! Message-ID: <438A103B.6060108@rncbc.org> Hi, Just to let you know about this small-fix release on QjackCtl, that only affects the MIDI connections (re)nomenclature: - ALSA sequencer client/port name aliases are functional again; all actual MIDI sequencer client/port numerical identifier prefixes are also back in business. Apparentely, this has been missed for quite a while, almost since 0.2.16. Only noticed this late week, thanks to Domenico Culturato. You can pick it out from the usual place: http://qjackctl.sourceforge.net Enjoy, -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From jwoithe at physics.adelaide.edu.au Sun Nov 27 18:36:57 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Sun Nov 27 18:35:54 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required In-Reply-To: <20051125015806.109b985c@mango.fruits.de> from "Florian Schmidt" at Nov 25, 2005 01:58:06 AM Message-ID: <200511272336.jARNavGa027019@auster.physics.adelaide.edu.au> > On Fri, 25 Nov 2005 11:10:05 +1030 (CST) > Jonathan Woithe wrote: > > > One thing I will try next is recompiling ardour; perhaps there's something > > funny there. In any case though, does any of this ring a bell with anyone? > > Did you try the --unlock jack switch? I tried this over the weekend. It didn't help; with the mlock rlimits reset to 20MB jack couldn't start. With a 40MB mlock limit jack started but then ardour couldn't load projects due to the thread call failing. In other words, this flag has made no practical difference to the situation. Regards jonathan -- * Jonathan Woithe jwoithe@physics.adelaide.edu.au * * http://www.physics.adelaide.edu.au/~jwoithe * ***-----------------------------------------------------------------------*** ** "Time is an illusion; lunchtime doubly so" ** * "...you wouldn't recognize a subtle plan if it painted itself purple and * * danced naked on a harpsichord singing 'subtle plans are here again'" * From jwoithe at physics.adelaide.edu.au Sun Nov 27 18:57:49 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Sun Nov 27 18:56:42 2005 Subject: [linux-audio-dev] set_rtlimit problem Message-ID: <200511272357.jARNvnOO027161@auster.physics.adelaide.edu.au> Hi Lee > I just noticed that the sys_get_priority_max and _min syscalls do not > take the RT priority rlimit into account. Since the watchdog thread > runs at the -P setting + 10 then if the rlimit is 50 and the user > specifies -P50 the watchdog thread will fail. > > I believe sched_get_priority_max(SCHED_FIFO) needs to take the rlimit > into account - there's no other way to get the upper limit AFAICT. I'm not sure what the "set_rtlimit problem" is here - I'm a little confused. In terms of what set_rtlimits does, it seems to me that the watchdog thread issue can be easily dealt with: define the max rtpriority value in /etc/set_rtlimits to be X, knowing that the maximum jackd "-P" option value one can use is X-10. Certainly getrlimit()/setrlimit() (which set_rtlimit uses to do its thing) seem to take the current rtpriority rlimit into account. The former also returns the rlimit hard limit for the process, which I interpret to be the "upper limit" mentioned in the original email. In testing I've done during development, set_rtlimits seems to do the right thing, based on my understanding of what the right thing is. If I've misunderstood something though I'm happy to be corrected. Regards jonathan From rlrevell at joe-job.com Sun Nov 27 19:10:43 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Nov 27 19:10:55 2005 Subject: [linux-audio-dev] set_rtlimit problem In-Reply-To: <200511272357.jARNvnOO027161@auster.physics.adelaide.edu.au> References: <200511272357.jARNvnOO027161@auster.physics.adelaide.edu.au> Message-ID: <1133136644.19505.19.camel@mindpipe> On Mon, 2005-11-28 at 10:27 +1030, Jonathan Woithe wrote: > Hi Lee > > > I just noticed that the sys_get_priority_max and _min syscalls do not > > take the RT priority rlimit into account. Since the watchdog thread > > runs at the -P setting + 10 then if the rlimit is 50 and the user > > specifies -P50 the watchdog thread will fail. > > > > I believe sched_get_priority_max(SCHED_FIFO) needs to take the rlimit > > into account - there's no other way to get the upper limit AFAICT. > > I'm not sure what the "set_rtlimit problem" is here - I'm a little confused. > In terms of what set_rtlimits does, it seems to me that the watchdog thread > issue can be easily dealt with: define the max rtpriority value in > /etc/set_rtlimits to be X, knowing that the maximum jackd "-P" option value > one can use is X-10. > > Certainly getrlimit()/setrlimit() (which set_rtlimit uses to do its thing) > seem to take the current rtpriority rlimit into account. The former > also returns the rlimit hard limit for the process, which I interpret > to be the "upper limit" mentioned in the original email. > > In testing I've done during development, set_rtlimits seems to do the right > thing, based on my understanding of what the right thing is. If I've > misunderstood something though I'm happy to be corrected. Sorry, I should have been clearer. set_rtlimits (and JACK) are doing the right thing, I consider this a kernel bug. Lee From jwoithe at physics.adelaide.edu.au Mon Nov 28 18:12:24 2005 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Mon Nov 28 18:11:16 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required In-Reply-To: <1132944217.20390.25.camel@mindpipe> from "Lee Revell" at Nov 25, 2005 01:43:36 PM Message-ID: <200511282312.jASNCO4q014094@auster.physics.adelaide.edu.au> Lee > On Fri, 2005-11-25 at 11:10 +1030, Jonathan Woithe wrote: > > I have since discovered (thanks to strace) that the problem lies in an > > mmap2() call which requests a size of around 8MB. It appears to be > > part of the NPTL pthread_create() function. The error returned by > > mmap2() (EAGAIN) indicates either a locked file or "too much locked > > memory" (according to the manpage). Because this is an anonymous map > > the problem must have been the latter. Increasing the "locked memory" > > limit from 20MB to 40MB made jackd start without having to resort to > > the LD_ASSUME_KERNEL hack. > > I stumbled across the same problem a few weeks ago working on another > project. This is glibc allocating an 8MB (!) stack for each thread. It > gets the default thread stack size from getrlimit(). With mlockall() > you will go OOM really fast like that. Um, yes. :( > The real fix is for JACK to set a reasonable thread stack size in > jack_create_thread. You can work around the problem by appending this > line to /etc/security/limits.conf: > > * hard stack 512 > > for a 512KB stack. I will try this and see what happens. Do you know if anyone is preparing a fix for JACK? Regards jonathan From rlrevell at joe-job.com Mon Nov 28 19:16:37 2005 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Nov 28 19:16:42 2005 Subject: [linux-audio-dev] NPTL jack+ardour: large memlock required In-Reply-To: <200511282312.jASNCO4q014094@auster.physics.adelaide.edu.au> References: <200511282312.jASNCO4q014094@auster.physics.adelaide.edu.au> Message-ID: <1133223397.4678.11.camel@mindpipe> On Tue, 2005-11-29 at 09:42 +1030, Jonathan Woithe wrote: > I will try this and see what happens. Do you know if anyone is > preparing a > fix for JACK? > I've been meaning to. I'll post one soon. Lee From nettings at folkwang-hochschule.de Wed Nov 30 12:18:11 2005 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Wed Nov 30 12:18:20 2005 Subject: [linux-audio-dev] [admin] attention gmail users: please fix your message format! Message-ID: <438DDED3.5030402@folkwang-hochschule.de> hi everyone! lately there are a number of gmail users filling up the moderation queues with "message has a suspicious header" bounces. this is almost always due to people trying to send non-text/plain content, which for a number of very good reasons is banned on linux-audio-*. it seems that gmail has an unfortunate default setting that some people are not aware of... gmail users, please fix your settings! best, j?rn