From fons.adriaensen at skynet.be Fri Dec 1 15:02:12 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Fri Dec 1 14:59:54 2006 Subject: [linux-audio-dev] Website moving - please update your links Message-ID: <20061201200212.GA6007@linux-1.site> Hello all, Since I'm preparing to move abroad, I've transferred my website to a host that's independent of my local ISP. The new site is www.kokkinizita.net/linuxaudio 'Kokkini Zita' means 'red zeta' - the Greek letter, and all the 'i' are pronounced as English 'ee', not 'y'. It's also my 'project name' at the Linux Audio Consortium. In time you will also see the red zeta appear in the GUI of any new software. The main page has been restyled a bit, and the rest will follow as I have time. Please let me know if you have any problems with the new layout and colors. The old site will remain on-line for some months, but any new stuff and updates will go to the new one only. My new e-mail address will be fons-at-kokkinizita.net, but please don't use that until you see it appear on the lists. Enjoy ! -- FA Lascia la spina, cogli la rosa. From ico at vt.edu Fri Dec 1 18:41:20 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Fri Dec 1 18:44:25 2006 Subject: [linux-audio-dev] Linuxaudio.org site problems Message-ID: <008201c715a2$347c8710$0202a8c0@64BitBadass> Just to let everyone know, we are experiencing some problems with the Linuxaudio.org server. As a result, we will have a downtime over the weekend and possibly a good portion of Monday. My sincere apologies if this unfortunate development has caused you any inconvenience. Your patience and understanding in this matter is most appreciated! Should you happen to have any additional questions and/or concerns, please do not hesitate to contact me. Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology, CCTAD, and CHCI Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico@vt.edu http://www.music.vt.edu/people/faculty/bukvic/ From ico at vt.edu Sat Dec 2 00:13:42 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Sat Dec 2 00:14:09 2006 Subject: [linux-audio-dev] RE: [linux-audio-user] where are the "made in linux "logo's now ? In-Reply-To: <200612021259.57317.songshop@bizmedia.com.au> Message-ID: <008701c715d0$a2c52b40$0202a8c0@64BitBadass> See: http://lists.agnula.org/pipermail/consortium/2006-November/000781.html BTW, anyone has any idea why the listserv is not forwarding posts to its membership, yet it still adds new posts to the archive without any problems? I checked the admin settings for the listserv and there is nothing that would suggest any problems. Alas, I do not have ssh access to the listserv server so I am unable to dig though the logs... Very bizarre week to say the least. First the listserv breaks, and now the linuxaudio.org server is experiencing problems as well... Ico > -----Original Message----- > From: linux-audio-user-bounces@music.columbia.edu [mailto:linux-audio- > user-bounces@music.columbia.edu] On Behalf Of Geoff Beasley > Sent: Friday, December 01, 2006 9:00 PM > To: linux-audio-user@music.columbia.edu > Subject: [linux-audio-user] where are the "made in linux "logo's now ? > > can't find them anywhere > > g. From ico at vt.edu Sat Dec 2 12:50:51 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Sat Dec 2 12:53:58 2006 Subject: [linux-audio-dev] Consortium "Made in Linux" cover idea Message-ID: <001201c7163a$688e02c0$0202a8c0@64BitBadass> Apologies for the cross-posting -- the consortium listserv that is hosted by Agnula server continues to refuse forwarding e-mail to its members... Apropos CD covers for the vol.1, how about taking the image from the http://lau.linuxaudio.org/faq/ ? IMHO it best portrays the idea of "Tux Power" without even having to explicitly state the subtitle. So, we could have the subtitle on the side and the back but perhaps not on the front side of the cover? Or if we do have it on the front, perhaps making it intentional small and inconspicuous? Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology, CCTAD, and CHCI Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico@vt.edu http://www.music.vt.edu/people/faculty/bukvic/ From ico at vt.edu Sat Dec 2 13:24:24 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Sat Dec 2 13:26:37 2006 Subject: [linux-audio-dev] Listserve back up Message-ID: <001a01c7163f$188e05e0$0202a8c0@64BitBadass> Curiously, shortly following the changing of the network card adapter which brought the consortium Web server back up, the consortium lists are now back as well. It appears that there is some kind of "umbilical cord" :-P that my mental radar failed to notice between the two and therefore the listserve has been for some reason bogged down due to network issues we've been experiencing on the Web server (which is a rather curious thing since the Web server has mail service disabled... go figure!). Well, I am glad that got resolved, sort of :-) Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology, CCTAD, and CHCI Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico@vt.edu http://www.music.vt.edu/people/faculty/bukvic/ From James at superbug.co.uk Mon Dec 4 06:26:39 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Mon Dec 4 06:28:01 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. Message-ID: <457405EF.4070206@superbug.co.uk> Hi, I have not yet found a laptop with good misc-in sound quality. Do any exist? It is a pain to have to use PCMCIA cards or USB devices. James From dlphillips at woh.rr.com Mon Dec 4 11:12:39 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Mon Dec 4 11:05:25 2006 Subject: [linux-audio-dev] Re: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates) In-Reply-To: References: <003401c711d5$39da9100$0202a8c0@64BitBadass> Message-ID: <457448F7.1000507@woh.rr.com> Dan Easley wrote: > i think two promising options for docs.*, both bandied around a bit on > various lists, are > > 1. setting up a wiki, a la > (though there are > security concerns - twice now i've removed spam from this page) and > > 2. community development of a new edition of dave's book. was there > any resolution as to the possibility of doing this? i believe dave > ran it past his publisher but i can't remember the results. i haven't > seen his book but am planning to buy it as soon as i start bringing in > the full-time wage - would it be a good idea to use it as a base for > our documentation (not word-for-word but structurally)? or would that > incur a property rights liability? Responding to option 2: I've terminated the book project, at least my involvement in it is over. My publisher and the contributors have known this for a few months, I apologize for not announcing the fact earlier, but as you can see from my updates to http://linux-sound.org I've not exactly been keeping up. Various reasons prompted my decision, family concerns being the most influential. Re: book structure: As far as I'm concerned, go ahead, use it, it's just a chapter succession. Lots of new headings should be added anyway. By the way, I'm fairly certain that all my stuff published by LJ and O'Reilly still belongs to me. They're pretty decent about it, all rights revert to the author after a certain period, a nice nod from publishers towards reusability. Anyway, again as far as I'm concerned the community can assemble and revise that stuff as it sees fit. And let's face it, folks, http://linux-sound.org and its mirrors are doomed. I'm so tired of the maintenance that I'm just not doing any at all. I'd like to see the community take over the lists and perhaps use them as bases for a wiki catalog of Linux sound and music software. Meanwhile I plan for one more update this month, then I'm unlikely to continue working with it any longer. I'm sorry but too many other important factors in my life require my attention now. Writing another book and maintaining linux-sound.org are unfortunately excluded. I'm not disappearing, I just can't manage those particular projects. Best regards, dp From brad at sonaural.com Mon Dec 4 11:15:51 2006 From: brad at sonaural.com (Brad Fuller) Date: Mon Dec 4 11:16:36 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates) In-Reply-To: <457448F7.1000507@woh.rr.com> References: <003401c711d5$39da9100$0202a8c0@64BitBadass> <457448F7.1000507@woh.rr.com> Message-ID: <457449B7.8090007@sonaural.com> Dave Phillips wrote: > Dan Easley wrote: > >> i think two promising options for docs.*, both bandied around a bit on >> various lists, are >> >> 1. setting up a wiki, a la >> (though there are >> security concerns - twice now i've removed spam from this page) and >> >> 2. community development of a new edition of dave's book. was there >> any resolution as to the possibility of doing this? i believe dave >> ran it past his publisher but i can't remember the results. i haven't >> seen his book but am planning to buy it as soon as i start bringing in >> the full-time wage - would it be a good idea to use it as a base for >> our documentation (not word-for-word but structurally)? or would that >> incur a property rights liability? > > Responding to option 2: > > I've terminated the book project, at least my involvement in it is over. > My publisher and the contributors have known this for a few months, I > apologize for not announcing the fact earlier, but as you can see from > my updates to http://linux-sound.org I've not exactly been keeping up. > Various reasons prompted my decision, family concerns being the most > influential. > > Re: book structure: As far as I'm concerned, go ahead, use it, it's just > a chapter succession. Lots of new headings should be added anyway. > > By the way, I'm fairly certain that all my stuff published by LJ and > O'Reilly still belongs to me. They're pretty decent about it, all rights > revert to the author after a certain period, a nice nod from publishers > towards reusability. Anyway, again as far as I'm concerned the community > can assemble and revise that stuff as it sees fit. > > And let's face it, folks, http://linux-sound.org and its mirrors are > doomed. I'm so tired of the maintenance that I'm just not doing any at > all. I'd like to see the community take over the lists and perhaps use > them as bases for a wiki catalog of Linux sound and music software. > Meanwhile I plan for one more update this month, then I'm unlikely to > continue working with it any longer. > > I'm sorry but too many other important factors in my life require my > attention now. Writing another book and maintaining linux-sound.org are > unfortunately excluded. I'm not disappearing, I just can't manage those > particular projects. > > Best regards, > > dp > > I believe everyone would join in and raise their glass to you Dave, for your contributions to Linux Audio! Thank You. Cheers! -- brad fuller sonaural: www.sonaural.com From ico at vt.edu Mon Dec 4 11:24:11 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Mon Dec 4 11:24:28 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. In-Reply-To: <457405EF.4070206@superbug.co.uk> Message-ID: <001301c717c0$a1bbfd40$0202a8c0@64BitBadass> Good built-in audio + laptop = lesson in futility Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of James Courtier-Dutton > Sent: Monday, December 04, 2006 6:27 AM > To: 'The Linux Audio Developers' Mailing List' > Subject: [linux-audio-dev] Laptop mic-input sound quality. > > Hi, > > I have not yet found a laptop with good misc-in sound quality. > Do any exist? > It is a pain to have to use PCMCIA cards or USB devices. > > James From krampenschiesser at freenet.de Mon Dec 4 11:34:27 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Mon Dec 4 11:28:34 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. In-Reply-To: <457405EF.4070206@superbug.co.uk> References: <457405EF.4070206@superbug.co.uk> Message-ID: <20061204173427.a50dc282.krampenschiesser@freenet.de> On Mon, 04 Dec 2006 11:26:39 +0000 James Courtier-Dutton wrote: > > Hi, > > I have not yet found a laptop with good misc-in sound quality. > Do any exist? > It is a pain to have to use PCMCIA cards or USB devices. > > James > Why is it a pain to use USB or PCMCIA? I'm planning to buy such a device in the near future. Can you give me any hints? -- If the future isn't what it used to be, does that mean that the past is subject to change in times to come? From mobarre at gmail.com Mon Dec 4 11:39:04 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Mon Dec 4 11:39:29 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates) In-Reply-To: <457448F7.1000507@woh.rr.com> References: <003401c711d5$39da9100$0202a8c0@64BitBadass> <457448F7.1000507@woh.rr.com> Message-ID: <3c808a150612040839j7ab797f7j8de74387cfe04a84@mail.gmail.com> > Responding to option 2: > > I've terminated the book project, at least my involvement in it is over. > My publisher and the contributors have known this for a few months, I > apologize for not announcing the fact earlier, but as you can see from > my updates to http://linux-sound.org I've not exactly been keeping up. > Various reasons prompted my decision, family concerns being the most > influential. > > Re: book structure: As far as I'm concerned, go ahead, use it, it's just > a chapter succession. Lots of new headings should be added anyway. > > By the way, I'm fairly certain that all my stuff published by LJ and > O'Reilly still belongs to me. They're pretty decent about it, all rights > revert to the author after a certain period, a nice nod from publishers > towards reusability. Anyway, again as far as I'm concerned the community > can assemble and revise that stuff as it sees fit. > > And let's face it, folks, http://linux-sound.org and its mirrors are > doomed. I'm so tired of the maintenance that I'm just not doing any at > all. I'd like to see the community take over the lists and perhaps use > them as bases for a wiki catalog of Linux sound and music software. > Meanwhile I plan for one more update this month, then I'm unlikely to > continue working with it any longer. > > I'm sorry but too many other important factors in my life require my > attention now. Writing another book and maintaining linux-sound.org are > unfortunately excluded. I'm not disappearing, I just can't manage those > particular projects. > > Best regards, > > dp > I discovered with your mail linux-audio.org. Great site really. if other people volunteer to maintain it, I'll also give a hand. this has to be kept up to date. Adding some content would be one thing, but also give a lifting to the graphics part (I could handle some nice style sheets). -- __________________ Marc-Olivier Barre, Markinoko. From mobarre at gmail.com Mon Dec 4 11:41:05 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Mon Dec 4 11:41:32 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. In-Reply-To: <20061204173427.a50dc282.krampenschiesser@freenet.de> References: <457405EF.4070206@superbug.co.uk> <20061204173427.a50dc282.krampenschiesser@freenet.de> Message-ID: <3c808a150612040841u35a8e36cs32dd70d0322c51e2@mail.gmail.com> On 12/4/06, krampenschiesser@freenet.de wrote: > On Mon, 04 Dec 2006 11:26:39 +0000 > James Courtier-Dutton wrote: > > > > > Hi, > > > > I have not yet found a laptop with good misc-in sound quality. > > Do any exist? > > It is a pain to have to use PCMCIA cards or USB devices. > > > > James > > > Why is it a pain to use USB or PCMCIA? > I'm planning to buy such a device in the near future. > Can you give me any hints? > USB can have some latency issues. I don't see the problem with PCMCIA... -- __________________ Marc-Olivier Barre, Markinoko. From jack.oquin at gmail.com Mon Dec 4 12:46:46 2006 From: jack.oquin at gmail.com (Jack O'Quin) Date: Mon Dec 4 12:47:03 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates) In-Reply-To: <457449B7.8090007@sonaural.com> References: <003401c711d5$39da9100$0202a8c0@64BitBadass> <457448F7.1000507@woh.rr.com> <457449B7.8090007@sonaural.com> Message-ID: On 12/4/06, Brad Fuller wrote: > I believe everyone would join in and raise their glass to you Dave, for > your contributions to Linux Audio! Thank You. ++thanks; -- joq From jack.oquin at gmail.com Mon Dec 4 12:48:06 2006 From: jack.oquin at gmail.com (Jack O'Quin) Date: Mon Dec 4 12:50:34 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. In-Reply-To: <3c808a150612040841u35a8e36cs32dd70d0322c51e2@mail.gmail.com> References: <457405EF.4070206@superbug.co.uk> <20061204173427.a50dc282.krampenschiesser@freenet.de> <3c808a150612040841u35a8e36cs32dd70d0322c51e2@mail.gmail.com> Message-ID: On 12/4/06, Marc-Olivier Barre wrote: > On 12/4/06, krampenschiesser@freenet.de wrote: > > On Mon, 04 Dec 2006 11:26:39 +0000 > > James Courtier-Dutton wrote: > > > > > > > > Hi, > > > > > > I have not yet found a laptop with good misc-in sound quality. > > > Do any exist? > > > It is a pain to have to use PCMCIA cards or USB devices. > > > > > > James > > > > > Why is it a pain to use USB or PCMCIA? > > I'm planning to buy such a device in the near future. > > Can you give me any hints? > > > > USB can have some latency issues. I don't see the problem with PCMCIA... Firewire looks promising these days, thanks to the efforts of the freebob developers. -- joq From James at superbug.co.uk Mon Dec 4 14:03:09 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Mon Dec 4 14:03:17 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. In-Reply-To: <001301c717c0$a1bbfd40$0202a8c0@64BitBadass> References: <001301c717c0$a1bbfd40$0202a8c0@64BitBadass> Message-ID: <457470ED.5050301@superbug.co.uk> Ivica Ico Bukvic wrote: > Good built-in audio + laptop = lesson in futility > > Ico > It is technically possible to get good built-in audio. It is just that laptop manufactures don't bother. For example, The Creative Audigy 2 ZS Notebook is a PCMCIA card that has very good quality audio capture, and that is sitting inside the laptop, so why can't the laptop itself have good quality mic input? Note: I will soon be adding Linux ALSA support for the Audigy 2 ZS Notebook PCMCIA card. Today I managed to get the mic/line-in capture working, but will be a little time before I have anything I can check into the ALSA repository. James From indigo at bitglue.com Mon Dec 4 15:33:24 2006 From: indigo at bitglue.com (Phil Frost) Date: Mon Dec 4 15:44:10 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. In-Reply-To: <457470ED.5050301@superbug.co.uk> References: <001301c717c0$a1bbfd40$0202a8c0@64BitBadass> <457470ED.5050301@superbug.co.uk> Message-ID: <20061204203324.GA10125@unununium.org> On Mon, Dec 04, 2006 at 07:03:09PM +0000, James Courtier-Dutton wrote: > Ivica Ico Bukvic wrote: > >Good built-in audio + laptop = lesson in futility > > > >Ico > > > > It is technically possible to get good built-in audio. It is just that > laptop manufactures don't bother. > For example, The Creative Audigy 2 ZS Notebook is a PCMCIA card that has > very good quality audio capture, and that is sitting inside the laptop, > so why can't the laptop itself have good quality mic input? > > Note: I will soon be adding Linux ALSA support for the Audigy 2 ZS > Notebook PCMCIA card. Today I managed to get the mic/line-in capture > working, but will be a little time before I have anything I can check > into the ALSA repository. > > James Echo makes a couple of professional PCMCIA interfaces that are supported by ALSA (I think the kernel sources lack the driver, but it is included in the official ALSA sources). I have the Indigo IO which is a simple 2 in, 2 out. I haven't used my laptop for music lately, so I might be persuaded to part with it. From ico at vt.edu Mon Dec 4 16:05:37 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Mon Dec 4 16:05:58 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. In-Reply-To: <20061204203324.GA10125@unununium.org> Message-ID: <002a01c717e7$f2c2ded0$0dc652c6@64BitBadass> > > It is technically possible to get good built-in audio. It is just that > > laptop manufactures don't bother. > > For example, The Creative Audigy 2 ZS Notebook is a PCMCIA card that has > > very good quality audio capture, and that is sitting inside the laptop, > > so why can't the laptop itself have good quality mic input? Because PCMCIA != internal soundcard (even if it is physically inserted into the laptop's body). Namely, it is enclosed in its own metal casing, not to mention PCMCIA enclosure both of which allow for a much better R/F shielding than bunch of exposed chips and connectors on the motherboard. Best wishes, Ico From fons at kokkinizita.net Mon Dec 4 18:21:01 2006 From: fons at kokkinizita.net (Fons Adriaensen) Date: Mon Dec 4 18:18:18 2006 Subject: [linux-audio-dev] Laptop mic-input sound quality. In-Reply-To: <002a01c717e7$f2c2ded0$0dc652c6@64BitBadass> References: <20061204203324.GA10125@unununium.org> <002a01c717e7$f2c2ded0$0dc652c6@64BitBadass> Message-ID: <20061204232101.GD13645@linux-1.site> On Mon, Dec 04, 2006 at 04:05:37PM -0500, Ivica Ico Bukvic wrote: > Because PCMCIA != internal soundcard (even if it is physically inserted into > the laptop's body). Namely, it is enclosed in its own metal casing, not to > mention PCMCIA enclosure both of which allow for a much better R/F shielding > than bunch of exposed chips and connectors on the motherboard. One other aspect to consider: there is a good reason why the typical 'pro' microphone cable is about 5 times as thick and 25 times heavier than anything that will fit in a mini-jack. There is just no space on a laptop or on anything that can be inserted into a laptop for decent connectors, nor are they mechanically fit to take the strain of even a few meters of good mic cable. -- FA Lascia la spina, cogli la rosa. From nando at ccrma.Stanford.EDU Mon Dec 4 21:16:08 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon Dec 4 21:16:34 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates) In-Reply-To: References: <003401c711d5$39da9100$0202a8c0@64BitBadass> <457448F7.1000507@woh.rr.com> <457449B7.8090007@sonaural.com> Message-ID: <1165284968.30537.70.camel@cmn3.stanford.edu> On Mon, 2006-12-04 at 11:46 -0600, Jack O'Quin wrote: > On 12/4/06, Brad Fuller wrote: > > I believe everyone would join in and raise their glass to you Dave, for > > your contributions to Linux Audio! Thank You. > > ++thanks; (incf thanks) Thanks Dave, your musings will be sorely missed... -- Fernando "I still like Lisp" From ico at vt.edu Mon Dec 4 21:18:23 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Mon Dec 4 21:19:44 2006 Subject: [linux-audio-dev] RE: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates) In-Reply-To: <457448F7.1000507@woh.rr.com> Message-ID: <000d01c71813$a3fde840$0202a8c0@64BitBadass> > Responding to option 2: I am deeply sorry to hear that Dave! > I'm sorry but too many other important factors in my life require my > attention now. Writing another book and maintaining linux-sound.org are > unfortunately excluded. I'm not disappearing, I just can't manage those > particular projects. Totally understandable. Please allow me to express my deepest gratitude and respect for all you've done to build the Linux audio community from nothing into a formidable platform by providing an invaluable resource for all to use. For that matter, instead of a pint, we all ought to raise an entire keg! ;-) Hope you can still participate in the Linuxaudio.org matters. We sure could use your wisdom and insight! Best wishes, Ico From ico at vt.edu Mon Dec 4 21:23:32 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Mon Dec 4 21:23:59 2006 Subject: [linux-audio-dev] RE: linux audio wiki In-Reply-To: <87d56z9jrd.fsf@arnaudov.name> Message-ID: <000f01c71814$5c7a4d00$0202a8c0@64BitBadass> Hi Nedko, A while ago I proposed merging documentation efforts of the community, spearheaded by Dave's now unfortunately cancelled 2nd edition of his venerable book. Linuxaudio.org is already trying to head in this direction and we are currently in the process of assembling a team to utilize presently empty sub-domain docs.linuxaudio.org which ought to be perfect for this purpose (rather than hijacking lau faq site which has its own specific purpose). One possible scenario (which FWIW I very much favor) is to have a Wiki page that would sum up all of the projects listed on Dave's site as well as those that are also relevant but have not yet made it there. Using a similar template format we should provide a continuously updated consolidated resource for all Linux audio users, and more importantly all Linux distributions to reference. As such, we are also hoping to attract various distros to contribute to the same documentation project. So far goto10 guys (dyne creators) have expressed interest in the idea... Best wishes, Ico > -----Original Message----- > From: Nedko Arnaudov [mailto:nedko@arnaudov.name] > Sent: Monday, December 04, 2006 9:09 PM > To: ico@linuxaudio.org > Subject: linux audio wiki > > There was a talk in #lad and there is idea to have general purpose wiki > for linux audio. http://lau.linuxaudio.org/faq looks perfect except that > it is "user" faq oriented. What you think about having "lau faq" > category with all current lau faq pages in it and using the mediawiki > installation as general purpose linux audio wiki. Such wiki will include > user and developer oriented pages. It will include also information > about belonging of software to groups like lv2, dssi, jack, alsa midi, > jack midi, jack audio, sequencer, host, etc. Something similar (software > categorization/grouping) is made at http://linux-sound.org/ and > http://lawiki.fugal.net/linuxaudio/show/HomePage > > -- > Nedko Arnaudov From smcameron at yahoo.com Tue Dec 5 02:09:55 2006 From: smcameron at yahoo.com (Stephen Cameron) Date: Tue Dec 5 02:10:39 2006 Subject: [linux-audio-dev] Recording ADAT inputs on RME hammerfall 9636/52 In-Reply-To: <20060623043429.58173.qmail@web33010.mail.mud.yahoo.com> Message-ID: <20061205070955.51436.qmail@web33006.mail.mud.yahoo.com> (In case anyone remembers this, or digs it up via google or something) Well, I have _finally_ got my RME Hammerfall lite working, and yes, I am indeed an idiot. This whole time (almost 6 months) I've had the Mac EPROM plugged into the thing instead of the Windows EPROM. Upon describing my troubles (garbled sound and 48dB loss in volume) to RME support, they instantly diagnosed the problem. (I hadn't contacted them before because I know they do not officially support linux. Only after trying the board in a Windows box known to work with a HDSP board and finding my board still not working did I contact RME.) So, now, with the right EPROM chip, it's working, even with 50-foot ADAT cables. -- steve --- Stephen Cameron wrote (About 6 months ago, what's below): > > Well, mixed results tonight. > > I was able to get some sound to go across the ADAT > cables from the PC to the AW4416. But not good sound. > > On the bright side, I think I more or less understand > connecting things up with jack, ecasound, and so on. > On the bad side, so far it's not working too well. > > I monitored things with "jackmeter" and this meter > registered peaks near 0dB for the stuff I was playing > with ecasound, and pretty high levels for the most part. > > On the AW4416, the levels were registering between -30dB > and -48dB. I guess I don't understand how ADAT works. > I was under the impression the signal going across the > cables was digital -- and so to get a reduction in levels > like that, I would expect some digital numbers would have > to go from being big numbers to being small numbers, which > seems unlikely thing to happen to numbers encoded as pulses > going down a cable. So I conclude I don't know how ADAT > works, except it's not as I imagined it did. > > Oh, and besides a drastic loss of signal level, the signal > was distorted strangely. Hard to describe. This may be > due to xruns... I haven't got things to work without xruns > yet, but that shouldn't cause a drop in levels, right? Just > kind of choppiness, dropouts, crappy sound, right? > > Transfering from the AW4416 to the PC did not work at all. > on capture_1 and capture_2, I got very low level white noise > apparently. Are those the s/pdif ports? On the other > channels input was dead silence. > > I tried both ADAT ports on the RME board, with similar results > on each. I tried swapping the two ADAT cables in case one of > the cables was bad... this did not seem to make a difference. > Maybe the RME just transmits harder than the Yamaha, so it's > signal makes it across (just barely, crossing the finish > line at -48dB) while the yamaha's signal dies. > > I did change the RME's frequency to 44.1kHz in qjackctl's > setup window. > > > Maybe there are some clues in here: > [root@zuul R15]# cat /proc/asound/R15/rme9652 > RME Digi9636 (Rev 1.5) (Card #2) > Buffers: capture f6a00000 playback f6400000 > IRQ: 10 Registers bus: 0xea000000 VM: 0xf88a2000 > Control register: 48029 > > Latency: 1024 samples (2 periods of 4096 bytes) > Hardware pointer (frames): 1024 > Passthru: no > Clock mode: autosync > Pref. sync source: ADAT1 > > ADAT1 Input source: ADAT1 optical > > IEC958 input: Internal > IEC958 output: Coaxial only > IEC958 quality: Consumer > IEC958 emphasis: off > IEC958 Dolby: off > IEC958 sample rate: error flag set > > ADAT Sample rate: 44100Hz > ADAT1: No Lock > ADAT2: Sync > ADAT3: No Lock > > Timecode signal: no > Punch Status: > > 1: off 2: off 3: off 4: off 5: off 6: off 7: off 8: off > 9: off 10: off 11: off 12: off 13: off 14: off 15: off 16: off > 17: off 18: off > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From cp_singh at faith.co.jp Mon Dec 4 21:33:12 2006 From: cp_singh at faith.co.jp (chandrashekhar singh) Date: Tue Dec 5 05:31:07 2006 Subject: [linux-audio-dev] RE: Linux Documentation (was Re: [Consortium] Re:Linuxaudio.org staff updates) References: <000d01c71813$a3fde840$0202a8c0@64BitBadass> Message-ID: <005f01c71815$b68ad480$5811a80a@cpsingh> > I'm sorry but too many other important factors in my life require my > attention now. Writing another book and maintaining linux-sound.org are > unfortunately excluded. I'm not disappearing, I just can't manage those > particular projects. It's a bad news for us before X'mas. Please accept my gratitude. Wish you all the best and good luck for new front coming in your life. Best Wishes chaddrashekhar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061205/b32006a0/attachment.html From dlphillips at woh.rr.com Tue Dec 5 10:08:45 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue Dec 5 10:01:08 2006 Subject: [linux-audio-dev] M$/SuSE/ALSA ? In-Reply-To: <45548AE4.2080208@woh.rr.com> References: <45548AE4.2080208@woh.rr.com> Message-ID: <45758B7D.7020702@woh.rr.com> Greetings: Just a belated "Thanks!" to all who responded. Subsequent news reported on /. and elsewhere seems to indicate that the partnership is perhaps not so well-defined as its participants originally thought. Best, dp From dlphillips at woh.rr.com Tue Dec 5 10:15:23 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue Dec 5 10:07:46 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates) In-Reply-To: <1165284968.30537.70.camel@cmn3.stanford.edu> References: <003401c711d5$39da9100$0202a8c0@64BitBadass> <457448F7.1000507@woh.rr.com> <457449B7.8090007@sonaural.com> <1165284968.30537.70.camel@cmn3.stanford.edu> Message-ID: <45758D0B.2090006@woh.rr.com> Fernando Lopez-Lezcano wrote: >(incf thanks) > >Thanks Dave, your musings will be sorely missed... > Well, I'm still maintaining my Linux audio blog for the Linux Journal. I write two entries per month there, another part of "what keeps Dave busy". Best, dp From pw_lists at slinkp.com Tue Dec 5 10:15:13 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Tue Dec 5 10:16:09 2006 Subject: [linux-audio-dev] Re: Linux Documentation (was Re: [Consortium] Re: Linuxaudio.org staff updates) In-Reply-To: <457448F7.1000507@woh.rr.com> References: <003401c711d5$39da9100$0202a8c0@64BitBadass> <457448F7.1000507@woh.rr.com> Message-ID: <20061205151513.GB7349@slinkp.com> On Mon, Dec 04, 2006 at 11:12:39AM -0500, Dave Phillips wrote: > And let's face it, folks, http://linux-sound.org and its mirrors are > doomed. I'm so tired of the maintenance that I'm just not doing any at > all. I'd like to see the community take over the lists and perhaps use > them as bases for a wiki catalog of Linux sound and music software. > Meanwhile I plan for one more update this month, then I'm unlikely to > continue working with it any longer. A heartfelt thanks for many years of an invaluable community service, Dave. I'm probably not alone in saying your site is what led me to be here. A toast to the host who brought the most! For my part, I apologize that I several times proposed an interactive replacement to the static site and never delivered anything. Sometimes I miss being underemployed :-) -- Paul Winkler http://www.slinkp.com From simon at schampijer.de Wed Dec 6 08:53:44 2006 From: simon at schampijer.de (Simon Schampijer) Date: Wed Dec 6 08:53:35 2006 Subject: [linux-audio-dev] Reminder::Linux Audio Conference #5 (LAC2007): Call for Papers - Music Message-ID: <4576CB68.6000507@schampijer.de> Dear all, this is the second call for papers for the 5th Linux Audio Developers Conference (LAC2007). This is a reminder since some people might not have received the last call or might just have forgotten about the deadlines by now (08 Jan 2007 : Deadline for submission of papers, worshops, tutorials, demos, hands on demos and music). The conference is organized by the TU-Berlin in cooperation with people of the Linux Audio Developers mailing list, the music festival Inventionen 2007 and the Humboldt University of Berlin. The LAC2007 is taking place at the TU-Berlin, Germany from the 22nd - 25th of March 2007. We have introduced some new tracks. Besides the category for papers, demos and workshops, calls for tutorials and hands on demos have been added. The tutorials aim is to give new (potential) users an overview of the possibilities of Linux Audio Software and how to get started. The LAC2007 provides a computer pool (LA Pool) where developers can give an introduction to their software and where participants can try out Linux Audio Software during the conference. This has been combined in the call hands on demos. Since the TU-Berlin is installing a new Wave Field Synthesis (WFS) system the call for music has been extended by a call for compositions for this system. Music that can be used for radio airplay can be submitted, and will after acceptance by the Campusradio of the TU Berlin, be played during the conference. More detailed Information can be found in the 'Call for Papers' attached to this email or on the website at: www.lac.tu-berlin.de We are looking forward to many interesting submissions for the Linux Audio Conference 2007 and hope to see you in Berlin in 2007! Please feel free to forward this email to anybody who is interested. On behalf of the LAC2007 organisation team, Marije Baalman and Simon Schampijer -------------- next part -------------- Call for the Linux Audio Conference 2007 - 22nd - 25th of March 2007 taking place at the Technische Universit?t Berlin in cooperation with Inventionen 2007 and the Humboldt University of Berlin This call includes: Call for Papers Call for Demos Call for Hands On Demos Call for Workshops Call for Tutorials Call for Music (categories: Concert, Club, Radio and Wave Field Synthesis) ----------------------------- 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. 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 a PC with a pdf viewer How to submit File format is PDF, formatted for A4 paper. Make use of the templates for paper formatting available at: http://www.kgw.tu-berlin.de/~lac2007/download/templates-lac2007.tar.gz See our check list to ensure that you do not forget to enclose all necessary information. Send your paper and all necessary information by 8 Jan 2007 via email to this address: lac2007 AT robin.kgw.tu-berlin.de You will be notified by 05 Feb 2007 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 1, 2007. Important Dates 08 Jan 2007: Paper submission deadline 05 Feb 2007: Notification of acceptance 01 Mar 2007: Final version deadline 22 - 25 March 2007: Conference ----------------------------- Call for Demos 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. ----------------------------- Call for Hands On Demos A new item of the LAC 2007 is LA Pool: a pool with Linux audio computers, on which programs can be demonstrated. To give a "hands on" demo you can reserve LA Pool for 1 hour, of which ca. 20 minutes can be used as a general introduction and the rest should be free for participants to try out the program and ask questions. A Hands On demo can be held in addition to a Paper Presentation or as the presentation for the Demo, so you need to either submit a paper or an abstract as mentioned above. Additionally, you need to give us a version of your software, with clear installation instructions and requirements, so that we can install the software on the Pool before the conference. How to submit See our check list to ensure that you do not forget to enclose all necessary information. Send your abstract and all necessary information by 8 Jan 2007 via email to this address: lac2007 AT robin.kgw.tu-berlin.de Deadline for submissions is 08 Jan 2007. You will be notified by 05 Feb 2007 whether your submission has been accepted. ----------------------------- 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 TU Lichthof. Depending on the location, attendance might be limited to ca 10 people. 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. Send an abstract (ca. 50-100 words) and all necessary information via email to this address: lac2007 AT robin.kgw.tu-berlin.de The abstract will be published on the conference website once the workshop has been accepted (not before 01 March 2007 though). Submission deadline is 05 Feb 2007. You will be notified by 01 March 2007 whether your submission has been accepted. ----------------------------- Call for Tutorials New in this edition of the Linux Audio Conference will be a Tutorial track for new users. This Tutorial track will be hosted by the Media Science Department of the Humboldt University of Berlin. Proposals for additions to this Tutorial program are welcome. The aim of this Tutorial track is to give new (potential) users an overview of the possibilities of Linux Audio Software and how to get started. The difference to workshops is that the tutorials are given in a lecture environment and should focus on how to make music with Linux, more than going into specifics of certain programs. The tutorial track is supported by the LA Pool facility as attendants can try out the software themselves with hands on support. Send a short description of your proposed Tutorial topic (ca. 50-100 words), via email to this address: lac2007 AT robin.kgw.tu-berlin.de Submission deadline is 08 Jan 2007. You will be notified by 05 Feb 2007 whether your submission has been accepted. Criteria will be based upon creating a full fledged Tutorial program for Linux Audio. ----------------------------- Call for Music The conference will include several concerts. We are looking for music that has been produced completely or mostly under Linux and/or with open source software: Serious compositions, Electronica, Chill-Out, Ambient etc. Indicate whether you want to have your piece played in a concert like environment or a club like environment. Additionally you can submit Radio music (see below) and Wave Field Synthesis music (see also below). 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: LAC2007 - Call for Music Institute of Communications Research Sekretariat EN 8 Einsteinufer 17 D-10587 Berlin Germany Make use of one of the following media formats: Media: Audio-CD, DVD, DVD-R or CD-R File formats: aiff or wav Channels: mono, stereo, multi-channel and multi-mono (8 channels is no problem, more than 8 must be discussed). Samplerate: 44.1 or 48 kHz Resolution: 16 or 24 bit Include the following items with your submission (in English): A filled-out and signed printout of the form available here: http://www.kgw.tu-berlin.de/~lac2007/download/musicagreement.pdf For the printed program 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 2007. 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 composers themselves will generally have more chances to get included. If we get more pieces than we can include in the program, 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 the organizer. The material I send to the TU Berlin will not be returned. Additionally to this Call for Music, during the late night concerts there will be an open stage: "Plug & Chill - The Linux Jam Nights" where attendants of the conference are invited to perform their pieces in a more club-like 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 lac2007 AT robin.kgw.tu-berlin.de and include a description of your equipment and a short characterization 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 the TU Berlin where people can meet during the conference and rehearse for "Plug & Chill". ----------------------------- Radio Music A new category in the Music call is the call for music that can be used for radio airplay. In cooperation with the Campusradio (http://www.campusradio-online.de) of the TU Berlin, who will do a live report on the conference, we invite composers, musicians and producers of Music made or recorded and mastered with Open Source tools, to submit their works. If you want to participate, send an email to: lac2007-radio AT robin.kgw.tu-berlin.de with a link to your audio files. Alternately, send your music to the address above, with the addition: LAC2007 - Call for Music Radio Make use of one of the following media formats: Media: Audio-CD, DVD, DVD-R or CD-R File formats: aiff or wav or ogg Channels: mono or stereo Samplerate: 44.1 or 48 kHz Resolution: 16 or 24 bit Include the following items with your submission (in English): A filled-out and signed printout of the form available here (sent by mail, or by fax to: +49 30 31421143): http://www.kgw.tu-berlin.de/~lac2007/download/musicagreement.pdf Deadline for submissions is 05 Feb 2007. The choice of which pieces are played is in the hands of the Campusradio crew. A program listing will be on their website http://www.campusradio-online.de shortly before the conference. ----------------------------- Wave Field Synthesis Music Shortly before the conference, a new Wave Field Synthesis (WFS) system will be installed in one of the lecture halls of the TU Berlin. We are looking for composers who are interested in creating a composition for this system or who have already written pieces for WFS, which could be played on the system. The WFS system will be based on the sWONDER software (http://swonder.sourceforge.net), and can be controlled by OSC. For more information, please contact us at lac2007 AT robin.kgw.tu-berlin.de As there is no standard format for WFS material yet, we ask for a elaborate description of the piece and some examples of previous works. To prepare the piece for performance, it will be necessary for the composer to be present a few days before the conference. We will support efforts to get funding for this from external organizations (such as DAAD). Send your material to this address: LAC2007 - Call for WFS Music Institute of Communications Research Sekretariat EN 8 Einsteinufer 17 D-10587 Berlin Germany Make use of one of the following media formats: Media: Audio-CD, DVD, DVD-R or CD-R File formats: aiff or wav Channels: mono, stereo, multi-channel and multi-mono (8 channels is no problem, more than 8 must be discussed). Samplerate: 44.1 or 48 kHz Resolution: 16 or 24 bit Include the following items with your submission (in English): A filled-out and signed printout of the form available on: http://www.kgw.tu-berlin.de/~lac2007/download/musicagreement.pdf For the printed program 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 2007. 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 the organizer. The material I send to the TU Berlin will not be returned. From dlphillips at woh.rr.com Wed Dec 6 17:31:25 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed Dec 6 17:24:25 2006 Subject: [linux-audio-dev] Linux soundapps site final update Message-ID: <457744BD.1050402@woh.rr.com> Greetings: As I announced on the LAD/LAU mail lists I will soon put a new edition of linux-sound.org online. This one will be the last edition for the foreseeable future. I hope to see the community take over the site and its maintenance, but for this last publication I have a request for all developers: If you have any software listed on http://linux-sound.org please take a look to see if your preferred URL is listed. If you have software you would like to see listed there, send me its URL as soon as possible. Ditto for logos. I'm going through every page on the site, culling dead links and correcting bad addresses. It takes time, so I'll be putting up the corrected pages over the next week or so. The latest New Additions is already up, and I've already corrected some pages (dsp.html took all day today), but I'll delay an official announcement until all pages have been emended. The site will remain online and unmaintained until it's replaced by something better or I just get tired of looking at it. So, send corrections, logos, etc. to me directly at dlphillips@woh.rr.com if you'd like your stuff listed so people might actually find it. :) Best, dp From cuse at users.sourceforge.net Fri Dec 8 07:28:23 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Fri Dec 8 07:30:56 2006 Subject: [linux-audio-dev] MIDI bank select MSB + LSB Message-ID: <200612081328.23645.cuse@users.sourceforge.net> Hi everybody! I wonder what's the common behavior for a synth/sampler regarding MIDI bank select messages. You might know that MIDI has splitted bank indeces into two values MSB (coarse) and LSB (fine) value. So the "optimal" behavior would be a device / sequencer to send a MSB and a LSB bank select message to change the current bank. But many older keyboards for example won't do that. I've heard most of them only send MSB bank selects, while few others send only LSB bank selects. Is that true? If yes, how should you handle that on synth/sampler side? Because you know, using just MSB messages would only allow to switch between the following set of banks: { 0, 128, 256, ... , 16256 } while using just LSB messages would only allow to switch between the following set of banks: { 0, 1, 2, ... , 127 } So should a synth stick with that behavior or should it detect if a device either only sends MSB bank selects or only sends LSB bank selects and then actually remap MSB-only selects to a set of: { 0, 1, 2, ... , 127 } CU Christian From jens.andreasen at chello.se Fri Dec 8 14:45:34 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Dec 8 14:45:52 2006 Subject: [linux-audio-dev] MIDI bank select MSB + LSB In-Reply-To: <200612081328.23645.cuse@users.sourceforge.net> References: <200612081328.23645.cuse@users.sourceforge.net> Message-ID: <1165607134.11331.14.camel@c80-216-124-251.bredband.comhem.se> On Fri, 2006-12-08 at 13:28 +0100, Christian Schoenebeck wrote: > Hi everybody! > > I wonder what's the common behavior for a synth/sampler regarding MIDI bank > select messages. You might know that MIDI has splitted bank indeces into two > values MSB (coarse) and LSB (fine) value. I am only aware of the original program-select message (0 -127) and the newish(?) special controller 0 msg "bank select" (also 0 - 127) Older gear are unaware of control zero and will ignore on reception and most likely not be able to configure themselves to send it. Older midi-mergers may detect it as an error and discard. MIDI bank was introduced as a way of having both a userspace freely programmable area as well as a set (or several) well thought out patches. Default is bank zero. From alex at caoua.org Fri Dec 8 21:01:49 2006 From: alex at caoua.org (Alexandre Ratchov) Date: Fri Dec 8 21:02:37 2006 Subject: [linux-audio-dev] MIDI bank select MSB + LSB In-Reply-To: <200612081328.23645.cuse@users.sourceforge.net> References: <200612081328.23645.cuse@users.sourceforge.net> Message-ID: <20061209020149.GI31116@moule.localdomain> On Fri, Dec 08, 2006 at 01:28:23PM +0100, Christian Schoenebeck wrote: > Hi everybody! > > I wonder what's the common behavior for a synth/sampler regarding MIDI bank > select messages. You might know that MIDI has splitted bank indeces into two > values MSB (coarse) and LSB (fine) value. So the "optimal" behavior would be > a device / sequencer to send a MSB and a LSB bank select message to change > the current bank. But many older keyboards for example won't do that. I've > heard most of them only send MSB bank selects, while few others send only LSB > bank selects. Is that true? > hello, i haven't seen such a keyboard sice around 1995. I dont think that any recent midi keyboard uses MSB only (or LSB only) bank controllers. > If yes, how should you handle that on synth/sampler side? Because you know, > using just MSB messages would only allow to switch between the following set > of banks: > > { 0, 128, 256, ... , 16256 } > > while using just LSB messages would only allow to switch between the following > set of banks: > > { 0, 1, 2, ... , 127 } > > So should a synth stick with that behavior or should it detect if a device > either only sends MSB bank selects or only sends LSB bank selects and then > actually remap MSB-only selects to a set of: > > { 0, 1, 2, ... , 127 } > Keyboards that only support "MSB only" mode (or "LSB only" mode) are just too limited and there is no workaround that will "just work" with both modes. AFAIK, there is no standard way to detect if a device will use MSB, LSB or both. According to midi standard the bank number is (LSB + 128 * MSB), so the "Both" mode is the correct one to use. That's also what most users would expect. cheers, -- Alexandre From kouhia at nic.funet.fi Sat Dec 9 05:38:57 2006 From: kouhia at nic.funet.fi (Juhana Sadeharju) Date: Sat Dec 9 05:39:36 2006 Subject: [linux-audio-dev] Open source development sites? Message-ID: Hello. What other sites than SourceForge hosts open source projects? Audio and graphics projects. I'm attempting to build some kind of developer's meta catalog of all open source projects. Also, do people need yet another site for open source development? Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software From jens.andreasen at chello.se Sat Dec 9 07:30:56 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Dec 9 07:31:35 2006 Subject: [linux-audio-dev] MIDI bank select MSB + LSB In-Reply-To: <20061209020149.GI31116@moule.localdomain> References: <200612081328.23645.cuse@users.sourceforge.net> <20061209020149.GI31116@moule.localdomain> Message-ID: <1165667456.11331.57.camel@c80-216-124-251.bredband.comhem.se> Ahh ... sorry! I missed that ctrl 0 (MSB) is mirrored as ctrl 32 (LSB), perhaps because I get by with 8 sounds (or something ...) when I doodle at home. Who needs such a vast sample library? I can see the usefulness of having various dogs, cats, craws, crickets, seagulls or traffic-jams to set the the tone of a scene filmed off-site. but 127^3 is kind of a huge number. Is it even implemented on the receiving side? Inquiring minds wants to know :-) On Sat, 2006-12-09 at 03:01 +0100, Alexandre Ratchov wrote: > On Fri, Dec 08, 2006 at 01:28:23PM +0100, Christian Schoenebeck wrote: > > Hi everybody! > > > > I wonder what's the common behavior for a synth/sampler regarding MIDI bank > > select messages. You might know that MIDI has splitted bank indeces into two > > values MSB (coarse) and LSB (fine) value. So the "optimal" behavior would be > > a device / sequencer to send a MSB and a LSB bank select message to change > > the current bank. But many older keyboards for example won't do that. I've > > heard most of them only send MSB bank selects, while few others send only LSB > > bank selects. Is that true? > > > > hello, > > i haven't seen such a keyboard sice around 1995. I dont think that > any recent midi keyboard uses MSB only (or LSB only) bank > controllers. > > > If yes, how should you handle that on synth/sampler side? Because you know, > > using just MSB messages would only allow to switch between the following set > > of banks: > > > > { 0, 128, 256, ... , 16256 } > > > > while using just LSB messages would only allow to switch between the following > > set of banks: > > > > { 0, 1, 2, ... , 127 } > > > > So should a synth stick with that behavior or should it detect if a device > > either only sends MSB bank selects or only sends LSB bank selects and then > > actually remap MSB-only selects to a set of: > > > > { 0, 1, 2, ... , 127 } > > > > Keyboards that only support "MSB only" mode (or "LSB only" mode) > are just too limited and there is no workaround that will "just > work" with both modes. AFAIK, there is no standard way to detect if > a device will use MSB, LSB or both. According to midi standard the > bank number is (LSB + 128 * MSB), so the "Both" mode is the correct > one to use. That's also what most users would expect. > > cheers, > > -- Alexandre -- From cuse at users.sourceforge.net Sat Dec 9 11:04:16 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Sat Dec 9 11:05:39 2006 Subject: [linux-audio-dev] MIDI bank select MSB + LSB In-Reply-To: <20061209020149.GI31116@moule.localdomain> References: <200612081328.23645.cuse@users.sourceforge.net> <20061209020149.GI31116@moule.localdomain> Message-ID: <200612091704.16480.cuse@users.sourceforge.net> Am Samstag, 9. Dezember 2006 03:01 schrieb Alexandre Ratchov: > Keyboards that only support "MSB only" mode (or "LSB only" mode) > are just too limited and there is no workaround that will "just > work" with both modes. AFAIK, there is no standard way to detect if > a device will use MSB, LSB or both. According to midi standard the > bank number is (LSB + 128 * MSB), so the "Both" mode is the correct > one to use. That's also what most users would expect. Of course there is no real way to detect if a keyboard sends MSB-only or LSB-only bank selects, but there would be a workaround at least. I guess I will implement it similar as suggested by Grigor and Rui: "Normally, the instrument is only changed effectively when, and only when, a program change is received? Check. So, let's try having two int placeholders per MIDI channel for bank selection in linuxsampler, one as MSB and another as LSB, initialized to -1. If a bank MSB arrives, it will override the corresponding variable. Same as LSB, but independently. Then, if the LSB variable has the -1 value then, most probably, the sending device does not support the conjugated bank selection method, and in that case the MSB value will function as LSB alone, but iif the stored LSB value is -1, meaning that it was untuoched by the sending device. Once the program change is done, just reset both values to -1 and we're back in business ;)" At least I can't see a drawback of this workaround. Am Samstag, 9. Dezember 2006 13:30 schrieb Jens M Andreasen: > Who needs such a vast sample library? I can see the usefulness of having > various dogs, cats, craws, crickets, seagulls or traffic-jams to set the > the tone of a scene filmed off-site. but 127^3 is kind of a huge number. We'll see. ;) The point is that it doesn't make much of a difference to me in regards of the effort to implement it either with 127 or 127^2 banks, beside that little overhead of writing to this mailing list probably. ;) > Is it even implemented on the receiving side? > Inquiring minds wants to know :-) Yes, it is implemented on LS CVS HEAD: http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#anchor14 But as you can see you have to map the respective sounds by yourself, i.e. by QSampler's new MIDI map editor or by manually placing the map commands in a LSCP script file. For each entry you can indiidually define if the respective sound should be loaded on demand or preloaded ("persistent"). But I'm currently working to extend this mapping feature a bit: ATM you can only manage one single, global map which is used by all sampler channels. Within the next days however you can add an arbitrary amount of individual maps and define which sampler channel should be associated with which map. That way you can i.e. at least create two maps: one for "normal" instruments and one for drumkits and in contrast to the common GM behavior you could assign such a drumkit map to other MIDI channels beside MIDI channel 10 and/or you can define a 2nd drumkit map or whatever. CU Christian From alex at caoua.org Sat Dec 9 14:21:20 2006 From: alex at caoua.org (Alexandre Ratchov) Date: Sat Dec 9 14:21:52 2006 Subject: [linux-audio-dev] MIDI bank select MSB + LSB In-Reply-To: <200612091704.16480.cuse@users.sourceforge.net> References: <200612081328.23645.cuse@users.sourceforge.net> <20061209020149.GI31116@moule.localdomain> <200612091704.16480.cuse@users.sourceforge.net> Message-ID: <20061209192120.GA3591@moule.localdomain> On Sat, Dec 09, 2006 at 05:04:16PM +0100, Christian Schoenebeck wrote: > Am Samstag, 9. Dezember 2006 03:01 schrieb Alexandre Ratchov: > > Keyboards that only support "MSB only" mode (or "LSB only" mode) > > are just too limited and there is no workaround that will "just > > work" with both modes. AFAIK, there is no standard way to detect if > > a device will use MSB, LSB or both. According to midi standard the > > bank number is (LSB + 128 * MSB), so the "Both" mode is the correct > > one to use. That's also what most users would expect. > > Of course there is no real way to detect if a keyboard sends MSB-only or > LSB-only bank selects, but there would be a workaround at least. I guess I > will implement it similar as suggested by Grigor and Rui: > > "Normally, the instrument is only changed effectively when, and only when, a > program change is received? Check. So, let's try having two int placeholders > per MIDI channel for bank selection in linuxsampler, one as MSB and another > as LSB, initialized to -1. If a bank MSB arrives, it will override the > corresponding variable. Same as LSB, but independently. Then, if the LSB > variable has the -1 value then, most probably, the sending device does not > support the conjugated bank selection method, and in that case the MSB value > will function as LSB alone, but iif the stored LSB value is -1, meaning that > it was untuoched by the sending device. Once the program change is done, just > reset both values to -1 and we're back in business ;)" > > At least I can't see a drawback of this workaround. > hmm... MIDI spec says that if only MSB (or LSB) is received, then the last value of LSB (or MSB) will be used. If the default bank is 0 then if bank MSB (or LSB) has never been received 0 will be used as "last value". AFAIK a device that uses both LSB and MSB is allowed to transmit the following messages: bank_msb 1 # set bank to 128 prog_change 2 # load patch 2 from bank 128 or the following: bank_msb 10 # set bank to 1280 bank_lsb 1 # set bank to 1281 prog_change 2 # load prog 2 from bank 1281 bank_msb 0 # set bank to 1 prog_change 3 # load prog 3 from bank 1 This is unlikely to happen with a MIDI keyboard in real-life, however a MIDI sequencer that keeps state of already transmitted messages may transmit messages like the above. cheers, -- Alexandre From James at superbug.co.uk Sun Dec 10 07:35:13 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sun Dec 10 07:50:12 2006 Subject: [linux-audio-dev] Audio sampling and fft accuracy. Message-ID: <457BFF01.2020408@superbug.co.uk> Hi, If I have a sample 2kHz sine wave signal at 50% peak. I then add a white noise signal at 20%. I then do a FFT transform. If I design the FFT so that 2kHz is at the center of one of the FFT buckets, how close will the FFT figure be to the 50% sine wave input. Obviously, there will be a variation due to the amount of noise. So the output of the FFT buckets will be 50+-error. Will this variation as a result of noise decrease as I use more and more samples per fft block? I.e.Will the +-error value decrease? I would think it should decrease, as a result of the general averaging the fft routine will make to the noise signal. I would think that as the noise was random, it should average out to zero over time. I.e. 20% noise samples. Average each sample, the average should be zero as one reaches infinity number of samples. So, if my reasoning above is correct. I can draw the following conclusion: A 2kHz signal sampled at 8kHz and then FFTed, the 2kHz bucket will be less accurate than a 2kHz signal sampled at 16kHz and then FFTed. Now, I just need to work out how much more accurate it would be. James From fons at kokkinizita.net Sun Dec 10 10:11:18 2006 From: fons at kokkinizita.net (Fons Adriaensen) Date: Sun Dec 10 10:08:17 2006 Subject: [linux-audio-dev] Audio sampling and fft accuracy. In-Reply-To: <457BFF01.2020408@superbug.co.uk> References: <457BFF01.2020408@superbug.co.uk> Message-ID: <20061210151118.GA5920@linux-1.site> On Sun, Dec 10, 2006 at 12:35:13PM +0000, James Courtier-Dutton wrote: > If I have a sample 2kHz sine wave signal at 50% peak. > I then add a white noise signal at 20%. This is rather ambiguous. What do you mean by 'at 20%' ? Most noise signals do not have a clearly defined peak amplitude. Gaussian noise, even with finite power, has an infinite peak amplitude ! So you should always use the RMS value to indicate a noise level. > I then do a FFT transform. > If I design the FFT so that 2kHz is at the center of one of the FFT > buckets, how close will the FFT figure be to the 50% sine wave input. > Obviously, there will be a variation due to the amount of noise. So the > output of the FFT buckets will be 50+-error. Not exactly. The error will not be symmetric around the sine amplitude as the average power of the noise is not zero. When you convert the complex FFT output to a real value by x*x+y*y, you effectively measure power. Even if you take the square root of this afterwards, it's still power, expressed in amplitude units. The value in the signal bin is the signal power plus the noise power in that bin, which will fluctuate around its mean value, and that mean value is not zero. > Will this variation as a result of noise decrease as I use more and more > samples per fft block? I.e.Will the +-error value decrease? Yes. Assuming the noise is white, its power will on average be divided evenly over all the FFT bins. So the more bins, the less noise there will be in each of them. But you never reach zero, as that would require an infinite length FFT. > I would think it should decrease, as a result of the general averaging > the fft routine will make to the noise signal. I would think that as the > noise was random, it should average out to zero over time. No. It's average power is not zero. It decreases because there are more bins, and the sum of the powers in all bins must be the power of the signal. If you average the powers measured by a number of shorter FFTs (each one using 'new' noise of course), then the noise power in each bin will converge to P / (N / 2), where P is the total noise power and N the FFT length. Subtract this from the power in the bin where your signal is, and you get the exact signal power. -- FA Lascia la spina, cogli la rosa. From dlphillips at woh.rr.com Sun Dec 10 13:19:34 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sun Dec 10 13:11:57 2006 Subject: [linux-audio-dev] rebuilding the linux soundapps site Message-ID: <457C4FB6.90205@woh.rr.com> Greetings: I've received a few notes that indicate people are interested in revising the look & feel of the site at linux-sound.org. If you're currently working on such a project *please* make your intentions public. There are at least two projects working towards the same end, and this is truly one wheel that does not need reinvention. Better that folks work together on it. Best, dp From robin at gareus.org Sun Dec 10 14:55:23 2006 From: robin at gareus.org (Robin Gareus) Date: Sun Dec 10 14:55:40 2006 Subject: [linux-audio-dev] rebuilding the linux soundapps site In-Reply-To: <457C4FB6.90205@woh.rr.com> References: <457C4FB6.90205@woh.rr.com> Message-ID: <457C65E8.5050604@gareus.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Phillips wrote: > Greetings: > > I've received a few notes that indicate people are interested in > revising the look & feel of the site at linux-sound.org. not [only] the look&feel, but management of the content. > If you're currently working on such a project *please* make your > intentions public. There are at least two projects working towards the > same end, and this is truly one wheel that does not need reinvention. > Better that folks work together on it. I started working on a dokuwiki project that I will announce soon. my intentions are to combine a useful application with fun coding time, while learning more about dokuwiki. influenced by reading [linux-audio-dev] Re: Linux Documentation - I remembered how I struggled to get started with linux audio... goals are to provide a long living, maintainable and portable database, which can be branched and merged to and from mirror sites under GPL,CC; that the LAD/LAU community will pick up to maintain. The content is an archive of linux sound applications, projects, etc,.. imported from linux-sound.org with the best of both worlds: external links and/or [links to] local resources in a wiki page. local articles, how-to's, wiki pages, discussions, etc. are not part of the main database, but can be included/distributed as a separate wiki namespace. I am not in a position to provide major content improvements, edit or rewrite articles etc. - what is yet missing is an interface to the mailing-list archive. I was not meaning to be counter productive. I figured that starting a discussion would take much much longer than creating a prototype to start a discussion.. anyway it's just been 2 days. crazy how fast this community has become.. cheers, robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFfGXneVUk8U+VK0IRAnROAJ0Y032ikRLZaRM8w5cGinpvOsOeGwCgqUV2 Phbq/o7iq5pMkxIaNuS5rps= =PzBu -----END PGP SIGNATURE----- From ico at vt.edu Sun Dec 10 16:13:08 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Sun Dec 10 16:13:23 2006 Subject: [linux-audio-dev] rebuilding the linux soundapps site In-Reply-To: <457C4FB6.90205@woh.rr.com> Message-ID: <000301c71c9f$fe3236f0$0202a8c0@64BitBadass> Adoption of linux-sound.org into linuxaudio.org is a continuing standing offer, but obviously this is something that the community needs to embrace, rather than having a hostile takeover which will leave a sour aftertaste in everyone's mouths. Provided that the community is fine with this, the proposed course of action would be as follows: 1)generate apps.linuxaudio.org subdomain and port over a summary list of the applications (similar to Dave's format) 2) plug every listed app to the docs.linuxaudio.org wiki where we would build largest and most comprehensive documentation database Alternately, we could simply do everything inside docs.linuxaudio.org, but I feel that the usefulness of Dave's pages would be somewhat lost unless the docs would also have a nice categorized listing of available apps. Best wishes, Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Dave Phillips > Sent: Sunday, December 10, 2006 1:20 PM > To: LAD Mail List; LAU Mail List > Subject: [linux-audio-dev] rebuilding the linux soundapps site > > Greetings: > > I've received a few notes that indicate people are interested in > revising the look & feel of the site at linux-sound.org. > > If you're currently working on such a project *please* make your > intentions public. There are at least two projects working towards the > same end, and this is truly one wheel that does not need reinvention. > Better that folks work together on it. > > Best, > > dp From robin at gareus.org Sun Dec 10 17:53:36 2006 From: robin at gareus.org (Robin Gareus) Date: Sun Dec 10 18:02:20 2006 Subject: [linux-audio-dev] [ANN] yet another linux sound wiki. Message-ID: <457C8FAD.1060506@gareus.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've started to convert the information from linux-sound.org into a distributable doku-wiki. http://linux-sound.sonologic.nl/ This is a prototype installation and experimental suggestion! Please review and comment before further development proceeds. ** content information ** it's basically a database of http://linux-sound.org chopped up into text files. I have added URLs to [external] screenshots and logos to some pages and updated or deleted a few dead links.. it's still a long way to go, but some tasks could be semi-automated (fi. searching for dead links..) I am open to suggestions on how to maintain the content. This prototype is open for editing to all registered users (email verification). I can share experiences or rewrite and improve the dokuwiki to some extend, and may contribute to content but not on a day to day basis. patches, suggestions and comments are welcome. ** design/layout look&feel ** no efforts have been taken to change the default dokuwiki look and feel. Is anyone interested in a) designing and writing a dokuwiki template b) start a discussion on aims and goals for good user interaction design c) create a wiki-page to host a design contest d) rewriting the dokuwiki template ;-) ** technical- and mirror information. ** The data set is a 20MB git repository. dokuwiki keeps it's data in txt files. I've started to put them under git version control. The idea for mirror-sites is to check out and branch their wiki while maintainers can merge information upstream. dokuwiki only requires php. The wiki itself is available as a separate git repository (incl. pre-installed plugins and config) - the independent data-set git repos should work with every dokuwiki installation. The whole system including generated-meta data is about 50 MB. more information: http://linux-sound.sonologic.nl/devel:git http://linux-sound.sonologic.nl/devel:setup #robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFfI+seVUk8U+VK0IRAgrzAKDEF5aI9h8yZOis11v+T+GRTugL3wCfVc/z N/dkTVHWwZMWz9ca8iVnDcY= =z/Nj -----END PGP SIGNATURE----- From robin at gareus.org Sun Dec 10 18:05:37 2006 From: robin at gareus.org (Robin Gareus) Date: Sun Dec 10 18:12:04 2006 Subject: [linux-audio-dev] rebuilding the linux soundapps site In-Reply-To: <000301c71c9f$fe3236f0$0202a8c0@64BitBadass> References: <000301c71c9f$fe3236f0$0202a8c0@64BitBadass> Message-ID: <457C927E.8060702@gareus.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hey Ivo, Dave and you. > 1)generate apps.linuxaudio.org subdomain and port over a summary list of the > applications (similar to Dave's format) > 2) plug every listed app to the docs.linuxaudio.org wiki where we would > build largest and most comprehensive documentation database yes, a meta-index (1) should be kept separate from the documentation (2) itself. I would like to see this meta-index not as fixed (machine readable) database but as a wiki that can contain extra references, or provide quick information... > Alternately, we could simply do everything inside docs.linuxaudio.org, but I > feel that the usefulness of Dave's pages would be somewhat lost unless the > docs would also have a nice categorized listing of available apps. we should not draw a line between app-list or doc-wiki pages, but rather between maintained/edited and public editable content. if you like the analogy: stable / unstable distribution. public discussions evolve into signed-off articles and an index is kept separately (but can be linked/generated automatically..) i guess 90% of all the requests are either direct page access referring a search engine and people who will read an entire article, howto etc. so it might lack the critical mass to support a index site. Only few users will actually browse an index, but there are not [m]any alternatives to linux-sound.org when it comes to finding different tools for a certain task. so someone should keep that up... I ain't planning hostile takeovers either. In fact I do this in my spare time and will gladly return to other tasks. I have found a company to provide free hosting, but my aim is to build a distributable system.. This can certainly be part of linux-sound.org linuxsound.org or who ever wants to donate a domainname and webspace. I'm only experimenting with possible solutions. I won't have the time to become editor of linuxaudio.org but I'm certainly open for cooperation with apps.linuxaudio.org. linux-sound.sonologic.nl is far from a proper proposal. robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFfJJ9eVUk8U+VK0IRAhOdAJ0Y+3iKHZgOj7s0BqonGHvkOpbaGACgr7Wo 34Gky0jEc3gZT7wjesGNCIo= =1VsI -----END PGP SIGNATURE----- From t_w_ at freenet.de Mon Dec 11 03:58:33 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Mon Dec 11 04:00:09 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] rebuilding the linux soundapps site In-Reply-To: <457C4FB6.90205@woh.rr.com> References: <457C4FB6.90205@woh.rr.com> Message-ID: <20061211085833.GA5423@charly.SWORD> On Sun, Dec 10, 2006 at 01:19:34PM -0500, Dave Phillips wrote: > Greetings: > > I've received a few notes that indicate people are interested in > revising the look & feel of the site at linux-sound.org. I would be interested in helping with design a bit, but as things are, I will wait until the dust settles :) -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil From mobarre at gmail.com Sun Dec 10 05:04:40 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Mon Dec 11 04:49:21 2006 Subject: [linux-audio-dev] MIDI bank select MSB + LSB In-Reply-To: <20061209020149.GI31116@moule.localdomain> References: <200612081328.23645.cuse@users.sourceforge.net> <20061209020149.GI31116@moule.localdomain> Message-ID: <3c808a150612100204m7ed224faxa82aa7a970dca84@mail.gmail.com> On 12/9/06, Alexandre Ratchov wrote: > > On Fri, Dec 08, 2006 at 01:28:23PM +0100, Christian Schoenebeck wrote: > > Hi everybody! > > > > I wonder what's the common behavior for a synth/sampler regarding MIDI > bank > > select messages. You might know that MIDI has splitted bank indeces into > two > > values MSB (coarse) and LSB (fine) value. So the "optimal" behavior > would be > > a device / sequencer to send a MSB and a LSB bank select message to > change > > the current bank. But many older keyboards for example won't do that. > I've > > heard most of them only send MSB bank selects, while few others send > only LSB > > bank selects. Is that true? > > > > hello, > > i haven't seen such a keyboard sice around 1995. I dont think that > any recent midi keyboard uses MSB only (or LSB only) bank > controllers. > > Actually the CME UF-8 only has program change, no bank change, so I guess it's one of them. This keyboard appeared in 2005. __________________ Marc-Olivier Barre, Markinoko. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061210/a413583e/attachment.html From helgeingvart at gmail.com Mon Dec 11 01:46:58 2006 From: helgeingvart at gmail.com (Helge Fredriksen) Date: Mon Dec 11 04:49:25 2006 Subject: [linux-audio-dev] Grabbing sound using Roland Edirol FA-101 Message-ID: Hello! Did any of you guys ever tried to use the OpenAL API interface towards a Firewire sound device like FA-101? I see that it appears on your lists as a device that has drivers on Linux. Best regards, Helge Fredriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061211/9a3a4efd/attachment.html From dlphillips at woh.rr.com Mon Dec 11 05:47:54 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Mon Dec 11 05:39:52 2006 Subject: [linux-audio-dev] [ANN] yet another linux sound wiki. In-Reply-To: <457C8FAD.1060506@gareus.org> References: <457C8FAD.1060506@gareus.org> Message-ID: <457D375A.2000307@woh.rr.com> Robin Gareus wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I've started to convert the information from linux-sound.org into a >distributable doku-wiki. > >http://linux-sound.sonologic.nl/ > >This is a prototype installation and experimental suggestion! >Please review and comment before further development proceeds. > Would I be too egotistical to request that there be some notice of the fact that the pages were originally mine ? Forked projects often nod towards their original makers. But it's just a courtesy, not a requirement. :) Best, dp From robin at gareus.org Mon Dec 11 06:34:10 2006 From: robin at gareus.org (Robin Gareus) Date: Mon Dec 11 06:47:05 2006 Subject: [linux-audio-dev] [ANN] yet another linux sound wiki. In-Reply-To: <457D375A.2000307@woh.rr.com> References: <457C8FAD.1060506@gareus.org> <457D375A.2000307@woh.rr.com> Message-ID: <457D41EE.2080203@gareus.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Phillips wrote: > Robin Gareus wrote: > >> I've started to convert the information from linux-sound.org into a >> distributable doku-wiki. >> >> http://linux-sound.sonologic.nl/ >> >> This is a prototype installation and experimental suggestion! >> Please review and comment before further development proceeds. >> > Would I be too egotistical to request that there be some notice of the > fact that the pages were originally mine ? Forked projects often nod > towards their original makers. But it's just a courtesy, not a > requirement. :) > I'm sorry - I really am. even if you don't require it: I'd like to go GPL, CC or somewhat in that direction. Come to think of it i don't even remember putting my name in there somewhere yet. I'll get started on a About page.. robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFfUHteVUk8U+VK0IRAtEhAJ46IBAUIopQqGVno7TCL795/bXMRQCgoq9o Pm2kYS+/uL5oxXMBxC1W0m8= =BjCn -----END PGP SIGNATURE----- From dlphillips at woh.rr.com Mon Dec 11 09:07:38 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Mon Dec 11 08:59:40 2006 Subject: [linux-audio-dev] Hydrogen development ? Message-ID: <457D662A.3050606@woh.rr.com> Greetings: I've not checked out recent SVN sources, but watching the devel mail list I get the distinct impression that there's no internal development going on with Hydrogen. Almost all traffic on the list is concerned with translations. So, what's the story ? Is there a Hydrogen 1.0 in the works or is it a deader ? It would be a deep shame to see Hydrogen's development languish. Best, dp From parumi at iua.upf.edu Mon Dec 11 12:02:11 2006 From: parumi at iua.upf.edu (Pau Arumi) Date: Mon Dec 11 11:56:00 2006 Subject: [linux-audio-dev] CLAM 0.95 released Message-ID: <457D8F13.6010005@iua.upf.edu> After several months without a stable release but lots of development activity, we are pleased to announce CLAM 0.95 CLAM (http://clam.iua.upf.edu) is a C++ framework for doing research and app development in audio and music. It comes with a set of applications ready-to-use. Most important in this release is NetworkEditor 0.4, with a radically reworked UI based on Qt4.2, lots of work on stability and usability, and new visual-prototyping features. You can visually prototype standalone apps (or audio plugins): Edit audio networks with NetworkEditor, then edit its UI using Qt Designer and CLAM widgets plugins. Finally, Prototyper let you run the audio network with its UI. This is better shown in this quick tutorial: http://iua-share.upf.es/wikis/clam/index.php/Network_Editor_tutorial This release comes with many new processings, mostly spectral transformations. But we want to highlight the tonal-analysis which does chords identification at real-time, and its related visualizations. This code is based on the work done by researchers at Queen Mary University (London) and Universitat Pompeu Fabra (Barcelona). More credits are in the About box. These and many other improvements can be found in the ChangeLog: http://clam.iua.upf.edu/ChangeLog.txt This release brings new packages for Linux (Debian sid, Ubuntu edgy) and Windows installers. In Linux, you can simply add new sources to /etc/apt/sources.list deb http://clam.iua.upf.edu/download/linux-debian-sid ./ deb http://clam.iua.upf.edu/download/linux-ubuntu-edgly ./ Both Linux and Windows comes with desktop integration and several examples ready to use. Mac OSX packages will be catching up next weeks. Bug reports and any feedback is very welcomed (and needed). The CLAM team -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ico at vt.edu Mon Dec 11 17:17:40 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Mon Dec 11 17:18:16 2006 Subject: [linux-audio-dev] OT: interesting angle on the NOVL-MSFT deal Message-ID: <006401c71d72$2c2a85d0$c0c752c6@64BitBadass> http://weblog.infoworld.com/enterprisemac/archives/2006/12/leopard_server.ht ml Ico From James at superbug.co.uk Mon Dec 11 18:17:00 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Mon Dec 11 18:17:27 2006 Subject: [linux-audio-dev] OT: interesting angle on the NOVL-MSFT deal In-Reply-To: <006401c71d72$2c2a85d0$c0c752c6@64BitBadass> References: <006401c71d72$2c2a85d0$c0c752c6@64BitBadass> Message-ID: <457DE6EC.8000802@superbug.co.uk> Ivica Ico Bukvic wrote: > http://weblog.infoworld.com/enterprisemac/archives/2006/12/leopard_server.ht > ml > > Ico > > None of that is a concern here. The "intellectual property risk" is only a problem in the USA because they support software patents. We don't have that in Europe, so the "intellectual propery risk" does not exist in Europe. There is still "copyright protection" in Europe, but Linux has the GPL license, so that is also not a business "risk". James From ico at vt.edu Mon Dec 11 18:30:01 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Mon Dec 11 18:30:17 2006 Subject: [linux-audio-dev] OT: interesting angle on the NOVL-MSFT deal In-Reply-To: <457DE6EC.8000802@superbug.co.uk> Message-ID: <006501c71d7c$47936260$c0c752c6@64BitBadass> > None of that is a concern here. The "intellectual property risk" is only > a problem in the USA because they support software patents. We don't > have that in Europe, so the "intellectual propery risk" does not exist > in Europe. There is still "copyright protection" in Europe, but Linux > has the GPL license, so that is also not a business "risk". > > James This was not posted because of copyright/IP reasons, but rather the business model that the article implies Novell may be pushing for. Ico From jwoithe at physics.adelaide.edu.au Mon Dec 11 23:20:57 2006 From: jwoithe at physics.adelaide.edu.au (Jonathan Woithe) Date: Mon Dec 11 23:21:18 2006 Subject: [linux-audio-dev] Grabbing sound using Roland Edirol FA-101 In-Reply-To: <20061211114713.2558C4BD5318@music.columbia.edu> from "linux-audio-dev-request@music.columbia.edu" at Dec 11, 2006 06:47:13 AM Message-ID: <200612120420.kBC4Kv1P019624@turbo.physics.adelaide.edu.au> Helge Fredriksen wrote: > > Did any of you guys ever tried to use the OpenAL API interface towards a > Firewire sound device like FA-101? I see that it appears on your lists as a > device that has drivers on Linux. AFAIK OpenAL doesn't talk to hardware directly - it provides an API for programs to use but sends data to the soundcard via the operating system's native sound system. Therefore the devices supported by OpenAL are the devices supported by the underlying operating system. For many sound cards under Linux, that native sound system is ALSA (http://www.alsa-project.org). OSS was the previous default native sound system under Linux and is still in use by numerous programs. The FA-101 is (as you'd know) a firewire interface. Support for firewire interfaces is starting to gain momentum now but for various technical reasons this is not provided by ALSA at this time. The support effort is the so-called Freebob project (http://freebob.sourceforge.net) in combination with the JACK system (http://www.jackaudio.org/), a low-latency audio API. Only a small number of firewire audio interfaces are supported by freebob at this time, but from what I read the FA-101 is one of them. Getting back to your question, if OpenAL supports JACK under Linux then in theory you could talk to an FA-101 via OpenAL. According to the OpenAL website it currently only supports OSS and ALSA under Linux. Therefore at this point in time you can't use OpenAL to send audio to an FA-1-1. However, unless you particularly wanted the 3D modelling features of OpenAL you'd probably be better off using the JACK API directly. It should be noted that a long-term goal of the freebob project is to implement an ALSA driver for the firewire interfaces. However, there is still much to do before that will occur so I can't see it appearing any time soon. Once it did appear (and assuming OpenAL don't implement an interface to JACK earlier) you would be able to use OpenAL with the FA-101. Regards jonathan From andres at geminiflux.com Tue Dec 12 17:49:44 2006 From: andres at geminiflux.com (Andres Cabrera) Date: Tue Dec 12 17:50:38 2006 Subject: [linux-audio-dev] IEC 60608 or IEC 61672 Leq(A) measurement Message-ID: <457F3208.3050305@geminiflux.com> Hi all, I'm building a measuring system (naturally will be GPL'd, and initially linux only) aimed at audio post, and it would be great (and the main purpose) to include Leq(A) measurements, which are defined in IEC 60608 or the newer IEC 61672. Does anyone have access to this information or does anyone know this standard? Thanks, Andr?s From jens.andreasen at chello.se Fri Dec 15 11:21:50 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Dec 15 11:35:19 2006 Subject: [linux-audio-dev] kernel 2.6.18, -19 etc Message-ID: <1166199710.11331.119.camel@c80-216-124-251.bredband.comhem.se> Now that mingo's (et al) RT patches are coming into mainstream, what is the corporate rationale behind it and the running order of urgency? I am fishing for some information on; if it is the disk-drives, the network drivers, the usb stack or something else that I am too ignorant to have noticed? What worries me the most, is corner-cases on network, blocking multiple cpu's. FYI: I have been asked to set up a bunch of Xeon boxens to serve a VPN over WiFi, they/we are currently using kernel 2.6.17 (debian etch as of today.) So this is not stricly about audio, but I would guess all of us would like some clarification here. After all, we have followed the evolvement of these patches for quite a few years by now. -- mvh // Jens M Andreasen From ico at vt.edu Fri Dec 15 12:14:30 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Fri Dec 15 12:14:49 2006 Subject: [linux-audio-dev] linux-sound porting & documentation proposal (Was: Attracting more Linux audio developers) In-Reply-To: <003301c72068$48b9eb20$0202a8c0@64BitBadass> Message-ID: <003c01c7206c$7bd39890$0202a8c0@64BitBadass> How about we stop the seemingly endless discussion and instead all roll-up our sleeves and actually do this? Here's what I offer on behalf of linuxaudio.org: 1) generous hosting space 2) virtually unlimited bandwidth 3) docs.linuxaudio.org and apps.linuxaudio.org domains 4) accounts to maintainers 5) server support as needed What we need volunteers to do: 1) port Dave's pages over into a legible and appealing format to apps.linuxaudio.org 2) cross-link those pages to docs.linuxaudio.org page (in addition to apps homepages) which will be a wiki with documentation templates and standardized layout 3) need to design an appealing interface for both sites (hence consider this an open call for volunteer designers) -- this cannot be emphasized enough: we do not want an ugly, plain website, but a nice inviting and user-oriented resource. 4) create a generic wikipedia entry which gives a summary, philosophy, and notable achievements of the linux audio scene and provides critical links (hence it would be used as a portal rather than an exhaustive resource for a moving target which would never fly with the wikipedia editors anyhow) On a side note, here's another offer: As per my discussion with Joern, on behalf of linuxaudio.org I also offer free unlimited space for porting over LAU and LAD lists to lists.linuxaudio.org in hopes that we continue consolidating these invaluable resources. Maintainers will be given appropriate access privileges etc. Any takers? Best wishes, Ico From capocasa at gmx.net Fri Dec 15 12:44:50 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Fri Dec 15 12:45:26 2006 Subject: [linux-audio-dev] Re: Grabbing sound using Roland Edirol FA-101 In-Reply-To: References: Message-ID: I have an FA-101 and have it running by compiling freebob and jack myself. Carlo Helge Fredriksen schrieb: > Hello! > > Did any of you guys ever tried to use the OpenAL API interface towards a > Firewire sound device like FA-101? I see that it appears on your lists as a > device that has drivers on Linux. > > Best regards, > Helge Fredriksen > From jussi.laako at pp.inet.fi Fri Dec 15 15:00:02 2006 From: jussi.laako at pp.inet.fi (Jussi Laako) Date: Fri Dec 15 15:00:18 2006 Subject: [linux-audio-dev] kernel 2.6.18, -19 etc In-Reply-To: <1166199710.11331.119.camel@c80-216-124-251.bredband.comhem.se> References: <1166199710.11331.119.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <4582FEC2.1090208@pp.inet.fi> Jens M Andreasen wrote: > Now that mingo's (et al) RT patches are coming into mainstream, what is > the corporate rationale behind it and the running order of urgency? > > I am fishing for some information on; if it is the disk-drives, the > network drivers, the usb stack or something else that I am too ignorant > to have noticed? > > What worries me the most, is corner-cases on network, blocking multiple > cpu's. Isn't the functionality conditional and selected at configure time? I wouldn't be too worried about it. It also forces broken drivers to be fixed which is only a good thing. This is a bit similar to the situation when kernel pre-emption was introduced. - Jussi From jens.andreasen at chello.se Fri Dec 15 15:24:36 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Dec 15 15:25:17 2006 Subject: [linux-audio-dev] kernel 2.6.18, -19 etc In-Reply-To: <4582FEC2.1090208@pp.inet.fi> References: <1166199710.11331.119.camel@c80-216-124-251.bredband.comhem.se> <4582FEC2.1090208@pp.inet.fi> Message-ID: <1166214276.11331.161.camel@c80-216-124-251.bredband.comhem.se> On Fri, 2006-12-15 at 22:00 +0200, Jussi Laako wrote: > Jens M Andreasen wrote: > > Now that mingo's (et al) RT patches are coming into mainstream, what is > > the corporate rationale behind it and the running order of urgency? > > > > I am fishing for some information on; if it is the disk-drives, the > > network drivers, the usb stack or something else that I am too ignorant > > to have noticed? > > > > What worries me the most, is corner-cases on network, blocking multiple > > cpu's. > > Isn't the functionality conditional and selected at configure time? I > wouldn't be too worried about it. It also forces broken drivers to be > fixed which is only a good thing. This is a bit similar to the situation > when kernel pre-emption was introduced. Yes, but the pathces are introduced and applied a bit at the time for each official kernel version. At 2.6.19 we can read mingo's own comment over at slashdot that 'now 50% has gone in'. Friend of order would like to what half of which is accepted and why. Kernel conf is hard enough without knowing what to look for, really! > > > - Jussi -- From jens.andreasen at chello.se Fri Dec 15 15:42:05 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Dec 15 15:42:16 2006 Subject: [linux-audio-dev] kernel 2.6.18, -19 etc In-Reply-To: <1166214276.11331.161.camel@c80-216-124-251.bredband.comhem.se> References: <1166199710.11331.119.camel@c80-216-124-251.bredband.comhem.se> <4582FEC2.1090208@pp.inet.fi> <1166214276.11331.161.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <1166215325.11331.167.camel@c80-216-124-251.bredband.comhem.se> Just to clearify ... I believe that the RT patches that have been helpful to us in years, will also be helpful for corporations, better utilizing their fancy multiprocessor hardware, avoiding spinning in vain waiting ... So I am not afraid, no ;-) The PHB's are :-D On Fri, 2006-12-15 at 21:24 +0100, Jens M Andreasen wrote: > On Fri, 2006-12-15 at 22:00 +0200, Jussi Laako wrote: > > Jens M Andreasen wrote: > > > Now that mingo's (et al) RT patches are coming into mainstream, what is > > > the corporate rationale behind it and the running order of urgency? > > > > > > I am fishing for some information on; if it is the disk-drives, the > > > network drivers, the usb stack or something else that I am too ignorant > > > to have noticed? > > > > > > What worries me the most, is corner-cases on network, blocking multiple > > > cpu's. > > > > Isn't the functionality conditional and selected at configure time? I > > wouldn't be too worried about it. It also forces broken drivers to be > > fixed which is only a good thing. This is a bit similar to the situation > > when kernel pre-emption was introduced. > > Yes, but the pathces are introduced and applied a bit at the time for > each official kernel version. At 2.6.19 we can read mingo's own comment > over at slashdot that 'now 50% has gone in'. Friend of order would like > to what half of which is accepted and why. > > Kernel conf is hard enough without knowing what to look for, really! > > > > > > > - Jussi -- From jens.andreasen at chello.se Fri Dec 15 19:21:51 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Dec 15 19:22:02 2006 Subject: [linux-audio-dev] kernel 2.6.18, -19 etc In-Reply-To: <1166215325.11331.167.camel@c80-216-124-251.bredband.comhem.se> References: <1166199710.11331.119.camel@c80-216-124-251.bredband.comhem.se> <4582FEC2.1090208@pp.inet.fi> <1166214276.11331.161.camel@c80-216-124-251.bredband.comhem.se> <1166215325.11331.167.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <1166228511.11331.177.camel@c80-216-124-251.bredband.comhem.se> On Fri, 2006-12-15 at 21:42 +0100, Jens M Andreasen wrote: > Just to clearify ... ... and this is Scandinvia. Greatings to Jussi :-D Me and my significant other will dance a waltz along with the unknown finnish genious of Ismo. From kpanic at muppetslab.org Fri Dec 15 21:01:39 2006 From: kpanic at muppetslab.org (Marco Milanesi) Date: Fri Dec 15 19:59:27 2006 Subject: [linux-audio-dev] Grabbing sound using Roland Edirol FA-101 In-Reply-To: References: Message-ID: <20061216020138.GC10122@innerloop.it> > Did any of you guys ever tried to use the OpenAL API interface towards a > Firewire sound device like FA-101? I see that it appears on your lists as a > device that has drivers on Linux. hi, you have to use the jackd's freebob backend, and try alsa's jackplug to make alsa apps (and that library to talk to jack) I had successfully ran games that use alsa with jackplug that forward the 'traffic' to jackd good luck :) ciao, Marco -- ,= ,-_-. =. ------------------------------------------------------- + ((_/)o o(\_)) jabber:kpanic@jabber.linux.it/msn:kpanic@muppetslab.org | `-'(. .)`- #muppetslab@irc.freenode.net | \_/ The more I see, the less I know | From pshirkey at boosthardware.com Sat Dec 16 05:56:23 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sat Dec 16 05:56:58 2006 Subject: [linux-audio-dev] Daemon mode Message-ID: <4583D0D7.9090303@boosthardware.com> Hi, I am adding a Daemon mode to jackEQ and have most of the code in place now. I am stuck at the point where the daemon starts up and keeps going. Essentially I need the daemon mode equivalent of gtk_main() that keeps ticking over until the app is told to stop or otherwise shutdown. I have not threaded the app at this point so hopefully there is a very simple solution. Any thoughts on this are appreciated. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From lars.luthman at gmail.com Sat Dec 16 06:14:03 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Dec 16 06:14:25 2006 Subject: [linux-audio-dev] Daemon mode In-Reply-To: <4583D0D7.9090303@boosthardware.com> References: <4583D0D7.9090303@boosthardware.com> Message-ID: <1166267643.11667.3.camel@c213-100-20-29.swipnet.se> On Sat, 2006-12-16 at 17:56 +0700, Patrick Shirkey wrote: > Hi, > > I am adding a Daemon mode to jackEQ and have most of the code in place now. > > I am stuck at the point where the daemon starts up and keeps going. > > Essentially I need the daemon mode equivalent of gtk_main() that keeps > ticking over until the app is told to stop or otherwise shutdown. > > I have not threaded the app at this point so hopefully there is a very > simple solution. So the only thread that needs to do anything is the JACK thread? In that case you can just add something like ... init code ... bool run = true; while (run) sleep(10000); ... cleanup code ... in the main thread, after setting up JACK. If you want to be nice you can add signal handlers for SIGHUP and SIGINT that set 'run' to false. -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061216/1f05f0d7/attachment.bin From lars.luthman at gmail.com Sat Dec 16 06:17:46 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Dec 16 06:18:33 2006 Subject: [linux-audio-dev] Daemon mode In-Reply-To: <1166267643.11667.3.camel@c213-100-20-29.swipnet.se> References: <4583D0D7.9090303@boosthardware.com> <1166267643.11667.3.camel@c213-100-20-29.swipnet.se> Message-ID: <1166267866.11667.5.camel@c213-100-20-29.swipnet.se> On Sat, 2006-12-16 at 12:14 +0100, Lars Luthman wrote: > On Sat, 2006-12-16 at 17:56 +0700, Patrick Shirkey wrote: > > Hi, > > > > I am adding a Daemon mode to jackEQ and have most of the code in place now. > > > > I am stuck at the point where the daemon starts up and keeps going. > > > > Essentially I need the daemon mode equivalent of gtk_main() that keeps > > ticking over until the app is told to stop or otherwise shutdown. > > > > I have not threaded the app at this point so hopefully there is a very > > simple solution. > > So the only thread that needs to do anything is the JACK thread? In that > case you can just add something like > > ... init code ... > > bool run = true; > while (run) sleep(10000); > > ... cleanup code ... > > in the main thread, after setting up JACK. If you want to be nice you > can add signal handlers for SIGHUP and SIGINT that set 'run' to false. Ehm, and in that case you better change the sleep time to 1 or use usleep() and specify microseconds instead. You wouldn't want to wait for hours after trying to stop the program. Or is sleep() interrupted by signals even if there are signal handlers for them? -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061216/d977732f/attachment-0001.bin From dplist at free.fr Sat Dec 16 08:29:12 2006 From: dplist at free.fr (David) Date: Sat Dec 16 08:41:10 2006 Subject: [linux-audio-dev] Daemon mode In-Reply-To: <4583D0D7.9090303@boosthardware.com> References: <4583D0D7.9090303@boosthardware.com> Message-ID: <20061216142912.3d2c1f03.dplist@free.fr> On Sat, 16 Dec 2006 17:56:23 +0700 Patrick Shirkey wrote: > Hi, > > I am adding a Daemon mode to jackEQ and have most of the code in > place now. > > I am stuck at the point where the daemon starts up and keeps going. > > Essentially I need the daemon mode equivalent of gtk_main() that > keeps ticking over until the app is told to stop or otherwise > shutdown. I think you could use a Glib main loop : http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html HTH -- David From pshirkey at boosthardware.com Sat Dec 16 08:48:04 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sat Dec 16 08:49:15 2006 Subject: [linux-audio-dev] Daemon mode In-Reply-To: <1166267866.11667.5.camel@c213-100-20-29.swipnet.se> References: <4583D0D7.9090303@boosthardware.com> <1166267643.11667.3.camel@c213-100-20-29.swipnet.se> <1166267866.11667.5.camel@c213-100-20-29.swipnet.se> Message-ID: <4583F914.1000302@boosthardware.com> Lars Luthman wrote: > On Sat, 2006-12-16 at 12:14 +0100, Lars Luthman wrote: >> On Sat, 2006-12-16 at 17:56 +0700, Patrick Shirkey wrote: >>> Hi, >>> >>> I am adding a Daemon mode to jackEQ and have most of the code in place now. >>> >>> I am stuck at the point where the daemon starts up and keeps going. >>> >>> Essentially I need the daemon mode equivalent of gtk_main() that keeps >>> ticking over until the app is told to stop or otherwise shutdown. >>> >>> I have not threaded the app at this point so hopefully there is a very >>> simple solution. >> So the only thread that needs to do anything is the JACK thread? In that >> case you can just add something like >> >> ... init code ... >> >> bool run = true; >> while (run) sleep(10000); >> >> ... cleanup code ... >> >> in the main thread, after setting up JACK. If you want to be nice you >> can add signal handlers for SIGHUP and SIGINT that set 'run' to false. > > Ehm, and in that case you better change the sleep time to 1 or use > usleep() and specify microseconds instead. You wouldn't want to wait for > hours after trying to stop the program. > > Or is sleep() interrupted by signals even if there are signal handlers > for them? > Thanks for the pointer Lars. However I'm using c so this code doesn't work. I have modified it like so: int run = TRUE; while (run) sleep(10000); but that just gives a segv. It runs for about a second then gives up. I'm also looking at the code for jackd and have spotted this function: sigwait (&signals, &sig); so I added some new bits and pieces like so: static sigset_t signals; int main(int argc, char *argv[]) { int run; int sig; sigset_t allsignals; sigemptyset (&signals); sigaddset(&signals, SIGHUP); sigaddset(&signals, SIGINT); sigaddset(&signals, SIGQUIT); sigaddset(&signals, SIGPIPE); sigaddset(&signals, SIGTERM); sigfillset (&allsignals); process_init(); run = TRUE; while (run) sigwait (&signals, &sig); return 0; } but that also returns segv at sigwait(). If I put a printf after sigwait it doesn't print. Before is ok. I'm not sure how to proceed from here. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From lars.luthman at gmail.com Sat Dec 16 09:00:14 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Sat Dec 16 09:00:28 2006 Subject: [linux-audio-dev] Daemon mode In-Reply-To: <4583F914.1000302@boosthardware.com> References: <4583D0D7.9090303@boosthardware.com> <1166267643.11667.3.camel@c213-100-20-29.swipnet.se> <1166267866.11667.5.camel@c213-100-20-29.swipnet.se> <4583F914.1000302@boosthardware.com> Message-ID: <1166277614.11667.9.camel@c213-100-20-29.swipnet.se> On Sat, 2006-12-16 at 20:48 +0700, Patrick Shirkey wrote: > Thanks for the pointer Lars. > > However I'm using c so this code doesn't work. I have modified it like so: > > int run = TRUE; > > while (run) > sleep(10000); > > but that just gives a segv. It runs for about a second then gives up. > > I'm also looking at the code for jackd and have spotted this function: > > sigwait (&signals, &sig); > > > so I added some new bits and pieces like so: > > static sigset_t signals; > > int main(int argc, char *argv[]) > { > > int run; > int sig; > sigset_t allsignals; > > sigemptyset (&signals); > sigaddset(&signals, SIGHUP); > sigaddset(&signals, SIGINT); > sigaddset(&signals, SIGQUIT); > sigaddset(&signals, SIGPIPE); > sigaddset(&signals, SIGTERM); > sigfillset (&allsignals); > > > process_init(); > > run = TRUE; > > while (run) > sigwait (&signals, &sig); > > return 0; > > } > > > but that also returns segv at sigwait(). If I put a printf after sigwait > it doesn't print. Before is ok. That code compiles and runs fine here (after adding #include and commenting out process_init()). The problem is probably somewhere else in your code. I'd try running it in valgrind to spot any memory bugs (with JACK in softmode and using the dummy driver). -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061216/b23f2738/attachment.bin From nipo at ssji.net Sat Dec 16 09:05:05 2006 From: nipo at ssji.net (Nicolas Pouillon) Date: Sat Dec 16 09:05:46 2006 Subject: [linux-audio-dev] Daemon mode In-Reply-To: <4583F914.1000302@boosthardware.com> References: <4583D0D7.9090303@boosthardware.com> <1166267643.11667.3.camel@c213-100-20-29.swipnet.se> <1166267866.11667.5.camel@c213-100-20-29.swipnet.se> <4583F914.1000302@boosthardware.com> Message-ID: <4583FD11.8080408@ssji.net> Hi list Patrick Shirkey a ?crit : > int run = TRUE; > > while (run) > sleep(10000); The easiest one for this construct is probably pause(2) instead of sleep() with some random value, but is marked deprecated in favor of sigsuspend(2). > while (run) > sigwait (&signals, &sig); From manpages, sigwait(3) seems to disable signal handlers, whereas sigsuspend(2) lets them run, use what you need though. sigwait is threads related. > but that also returns segv at sigwait(). If I put a printf after sigwait > it doesn't print. Before is ok. You must have some data still referenced after cleanup, aren't there some callback systems you forgot to disable somewhere ? Cheers -- Nipo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061216/e3d197d6/signature.bin From mista.tapas at gmx.net Sat Dec 16 09:33:18 2006 From: mista.tapas at gmx.net (Florian Schmidt) Date: Sat Dec 16 09:31:43 2006 Subject: [linux-audio-dev] kernel 2.6.18, -19 etc In-Reply-To: <1166214276.11331.161.camel@c80-216-124-251.bredband.comhem.se> References: <1166199710.11331.119.camel@c80-216-124-251.bredband.comhem.se> <4582FEC2.1090208@pp.inet.fi> <1166214276.11331.161.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <200612161533.18219.mista.tapas@gmx.net> On Friday 15 December 2006 21:24, Jens M Andreasen wrote: > On Fri, 2006-12-15 at 22:00 +0200, Jussi Laako wrote: > > Jens M Andreasen wrote: > > > Now that mingo's (et al) RT patches are coming into mainstream, what is > > > the corporate rationale behind it and the running order of urgency? > > > > > > I am fishing for some information on; if it is the disk-drives, the > > > network drivers, the usb stack or something else that I am too ignorant > > > to have noticed? > > > > > > What worries me the most, is corner-cases on network, blocking multiple > > > cpu's. > > > > Isn't the functionality conditional and selected at configure time? I > > wouldn't be too worried about it. It also forces broken drivers to be > > fixed which is only a good thing. This is a bit similar to the situation > > when kernel pre-emption was introduced. > > Yes, but the pathces are introduced and applied a bit at the time for > each official kernel version. At 2.6.19 we can read mingo's own comment > over at slashdot that 'now 50% has gone in'. Friend of order would like > to what half of which is accepted and why. Can you post a link to the story? A quick search didn't find it here.. Flo -- Palimm Palimm! http://tapas.affenbande.org From jens.andreasen at chello.se Sat Dec 16 09:49:40 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sat Dec 16 09:51:05 2006 Subject: [linux-audio-dev] kernel 2.6.18, -19 etc In-Reply-To: <200612161533.18219.mista.tapas@gmx.net> References: <1166199710.11331.119.camel@c80-216-124-251.bredband.comhem.se> <4582FEC2.1090208@pp.inet.fi> <1166214276.11331.161.camel@c80-216-124-251.bredband.comhem.se> <200612161533.18219.mista.tapas@gmx.net> Message-ID: <1166280580.11331.182.camel@c80-216-124-251.bredband.comhem.se> On Sat, 2006-12-16 at 15:33 +0100, Florian Schmidt wrote: > Can you post a link to the story? A quick search didn't find it here.. > Heh, slashcode ain't doing what you thought it was supposed to? Google can find them all though: http://slashdot.org/~Ingo+Molnar That would be the latest 24 comments. There are bits of interresting information in most of them. > Flo > -- From pshirkey at boosthardware.com Sun Dec 17 09:41:23 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sun Dec 17 09:41:44 2006 Subject: [linux-audio-dev] Daemon mode In-Reply-To: <4583FD11.8080408@ssji.net> References: <4583D0D7.9090303@boosthardware.com> <1166267643.11667.3.camel@c213-100-20-29.swipnet.se> <1166267866.11667.5.camel@c213-100-20-29.swipnet.se> <4583F914.1000302@boosthardware.com> <4583FD11.8080408@ssji.net> Message-ID: <45855713.1040805@boosthardware.com> Nicolas Pouillon wrote: > > You must have some data still referenced after cleanup, aren't there > some callback systems you forgot to disable somewhere ? > Yep, was missing a global. Been a while since I worked on this code... Thanks for the help everyone. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://lau.linuxaudio.org - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B From oscarsi04 at yahoo.com Sun Dec 17 22:43:39 2006 From: oscarsi04 at yahoo.com (oscar si) Date: Mon Dec 18 13:43:14 2006 Subject: [linux-audio-dev] Audio Driver Sample Code Message-ID: <867584.3333.qm@web59002.mail.re1.yahoo.com> Hello: Could anyone please tell me if there are sample driver codes for PCI based sound card that are not using either alsa or oss? Thank you very much, Oscar __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061217/4c4839a9/attachment-0001.html From lars.luthman at gmail.com Mon Dec 18 13:51:59 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Mon Dec 18 13:52:41 2006 Subject: [linux-audio-dev] Audio Driver Sample Code In-Reply-To: <867584.3333.qm@web59002.mail.re1.yahoo.com> References: <867584.3333.qm@web59002.mail.re1.yahoo.com> Message-ID: <1166467919.12002.5.camel@c213-100-20-29.swipnet.se> On Sun, 2006-12-17 at 19:43 -0800, oscar si wrote: > Hello: > > Could anyone please tell me if there are sample driver codes for PCI > based sound card that are not using either alsa or oss? The FreeBoB driver in the JACK source tree maybe? -- Lars Luthman - please encrypt any email sent to me if possible PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061218/fc4344bf/attachment.bin From rlrevell at joe-job.com Mon Dec 18 13:57:21 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Dec 18 13:59:12 2006 Subject: [linux-audio-dev] Audio Driver Sample Code In-Reply-To: <867584.3333.qm@web59002.mail.re1.yahoo.com> References: <867584.3333.qm@web59002.mail.re1.yahoo.com> Message-ID: <1166468242.17059.89.camel@mindpipe> On Sun, 2006-12-17 at 19:43 -0800, oscar si wrote: > Hello: > > Could anyone please tell me if there are sample driver codes for PCI > based sound card that are not using either alsa or oss? Why wouldn't you just write an ALSA driver? What are you trying to do? Lee From paul at linuxaudiosystems.com Mon Dec 18 13:59:15 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Dec 18 13:59:55 2006 Subject: [linux-audio-dev] Audio Driver Sample Code In-Reply-To: <867584.3333.qm@web59002.mail.re1.yahoo.com> References: <867584.3333.qm@web59002.mail.re1.yahoo.com> Message-ID: <1166468355.8255.108.camel@localhost.localdomain> On Sun, 2006-12-17 at 19:43 -0800, oscar si wrote: > Hello: > > Could anyone please tell me if there are sample driver codes for PCI > based sound card that are not using either alsa or oss? why would you want such a thing? From green at redhat.com Wed Dec 20 18:43:34 2006 From: green at redhat.com (Anthony Green) Date: Wed Dec 20 19:01:29 2006 Subject: [linux-audio-dev] plugin loaders Message-ID: <1166658214.3172.60.camel@localhost.localdomain> I understand that LADSPA and friends specifically exclude any functionality around how to find and load plugins, but it seems that a lot can be gained by introducing some standards in this area. As a package of audio apps/plugins for a Linux distro, here are two of the problems I see: 1. Applications are often hard-coded to look in /usr/lib/ladspa (for instance), when many systems may require that libraries live somewhere else (like /usr/lib64/ladspa for x86-64, or /usr/lib32/ladspa for n32-ABI MIPS Linux). I've had to patch a lot of apps for x86-64 Fedora. 2. We build binaries for the lowest common denominator, so the plugins you'll find in Fedora, for instance, don't take advantage of SSE hardware or instruction scheduling for different processors. This can make a huge difference. What would be nice is if we could distribute an RPM containing a plurality of plugin builds, and then have the application load the plugin matching the capabilities the execution platform. Has there been any discussion around creating a plugin locator/loader library? It would be nice if one could be written and then widely adopted by app writers. (I'm not volunteering!) AG From contact at leonard-ritter.com Wed Dec 20 20:02:29 2006 From: contact at leonard-ritter.com (Leonard Ritter) Date: Wed Dec 20 20:02:45 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166658214.3172.60.camel@localhost.localdomain> References: <1166658214.3172.60.camel@localhost.localdomain> Message-ID: <1166662949.17056.59.camel@localhost> Hi Anthony, I guess most of us use the sample enumeration c code included with the LADSPA sources as starting point. This code expects a LADSPA_PATH variable to be set. As a fallback, I suppose most programmers added /usr/lib/ladspa:/usr/local/lib/ladspa, but all of them should support LADSPA_PATH. On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote: > I understand that LADSPA and friends specifically exclude any > functionality around how to find and load plugins, but it seems that a > lot can be gained by introducing some standards in this area. > > As a package of audio apps/plugins for a Linux distro, here are two of > the problems I see: > > 1. Applications are often hard-coded to look in /usr/lib/ladspa (for > instance), when many systems may require that libraries live somewhere > else (like /usr/lib64/ladspa for x86-64, or /usr/lib32/ladspa for > n32-ABI MIPS Linux). I've had to patch a lot of apps for x86-64 Fedora. > > 2. We build binaries for the lowest common denominator, so the plugins > you'll find in Fedora, for instance, don't take advantage of SSE > hardware or instruction scheduling for different processors. This can > make a huge difference. What would be nice is if we could distribute an > RPM containing a plurality of plugin builds, and then have the > application load the plugin matching the capabilities the execution > platform. > > Has there been any discussion around creating a plugin locator/loader > library? It would be nice if one could be written and then widely > adopted by app writers. (I'm not volunteering!) > > AG > > > -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From paul at linuxaudiosystems.com Wed Dec 20 21:11:06 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Dec 20 21:13:39 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166658214.3172.60.camel@localhost.localdomain> References: <1166658214.3172.60.camel@localhost.localdomain> Message-ID: <1166667066.2907.34.camel@localhost.localdomain> On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote: > I understand that LADSPA and friends specifically exclude any > functionality around how to find and load plugins, but it seems that a > lot can be gained by introducing some standards in this area. > > As a package of audio apps/plugins for a Linux distro, here are two of > the problems I see: > > 1. Applications are often hard-coded to look in /usr/lib/ladspa (for > instance), when many systems may require that libraries live somewhere > else (like /usr/lib64/ladspa for x86-64, or /usr/lib32/ladspa for > n32-ABI MIPS Linux). I've had to patch a lot of apps for x86-64 Fedora. the "standard" specifies that LADSPA_PATH be used if set. thus, distros that package LADSPA should set LADPSA_PATH in /etc/profile and its various equivalents. i am still dismayed that distros (and even Intel) could not agree on a common standard for the path to "the directory where system-level 64 bit libraries are installed"). > 2. We build binaries for the lowest common denominator, so the plugins > you'll find in Fedora, for instance, don't take advantage of SSE > hardware or instruction scheduling for different processors. This can > make a huge difference. What would be nice is if we could distribute an > RPM containing a plurality of plugin builds, and then have the > application load the plugin matching the capabilities the execution > platform. that's hard. but then again .... seems like its the job of a package manager to identify the correct build to install on processor foo, right? --p From paul at linuxaudiosystems.com Wed Dec 20 21:12:38 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Dec 20 21:14:52 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166662949.17056.59.camel@localhost> References: <1166658214.3172.60.camel@localhost.localdomain> <1166662949.17056.59.camel@localhost> Message-ID: <1166667158.2907.37.camel@localhost.localdomain> On Thu, 2006-12-21 at 02:02 +0100, Leonard Ritter wrote: > Hi Anthony, > > I guess most of us use the sample enumeration c code included with the > LADSPA sources as starting point. This code expects a LADSPA_PATH > variable to be set. As a fallback, I suppose most programmers > added /usr/lib/ladspa:/usr/local/lib/ladspa, but all of them should > support LADSPA_PATH. from ardour source: if (ladspa_path.length() == 0) { ladspa_path = "/usr/local/lib64/ladspa:/usr/local/lib/ladspa:/usr/lib64/ladspa:/usr/lib/ladspa:/Library/Audio/Plug-Ins/LADSPA"; } this used across linux and OS X if LADSPA_PATH is not set. From S.W.Harris at ecs.soton.ac.uk Thu Dec 21 03:40:27 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Thu Dec 21 03:41:02 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166667066.2907.34.camel@localhost.localdomain> References: <1166658214.3172.60.camel@localhost.localdomain> <1166667066.2907.34.camel@localhost.localdomain> Message-ID: <20061221084027.GA12312@login.ecs.soton.ac.uk> On Wed, Dec 20, 2006 at 09:11:06 -0500, Paul Davis wrote: > > 2. We build binaries for the lowest common denominator, so the plugins > > you'll find in Fedora, for instance, don't take advantage of SSE > > hardware or instruction scheduling for different processors. This can > > make a huge difference. What would be nice is if we could distribute an > > RPM containing a plurality of plugin builds, and then have the > > application load the plugin matching the capabilities the execution > > platform. > > that's hard. but then again .... seems like its the job of a package > manager to identify the correct build to install on processor foo, > right? Perhaps, perhaps not. LV2 has the potential to make that easier, as plugins are in directories, which can have multiple .so files, and they can be annotated so the host can pick out the right one. They could even be cross platform that way. c.f. http://lv2plug.in/ - though the full docs for the directory format are not yet uploaded. - Steve From betty.woessner at elec.qmul.ac.uk Tue Dec 19 11:42:02 2006 From: betty.woessner at elec.qmul.ac.uk (Betty Woessner) Date: Thu Dec 21 08:12:43 2006 Subject: [linux-audio-dev] 31st International AES Conference - New Directions in High Resolution Audio Message-ID: <001401c7238c$af01c1b0$3821258a@vpn.elec.qmul.ac.uk> Apologies if you receive multiple copies] +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 31st International AES Conference - New Directions in High Resolution Audio June 25-27, 2007 London, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Submissions site now open! Please let the conference organizers know of your intent to contribute or attend. Further detail available at http://www.aes.org/events/31/ The 31st International Audio Engineering Society Conference, entitled New Directions in High Resolution Audio, will be held at Queen Mary, University of London, from June 25th-27th, 2007. This Conference is concerned with the promotion and delivery of high resolution audio, by maintaining quality throughout the recording and playback chain with current and future technologies. It reflects the tremendous recent growth of high resolution audio techniques and products intended for use throughout the audio recording and playback chain. However, issues remain on how to avoid bottlenecks where quality is compromised, and how to maintain and encourage high resolution audio in an everchanging marketplace. These concerns are of interest to the audio engineering, recording and production industries, as well as to education and academia. We aim to provide a place for the exchange of news, issues and results, by bringing together researchers , developers, educators, students and professional users, working in fields that contribute to high resolution audio, to present original theoretical or practical work. It also serves as a discussion forum, provides introductory and in-depth information in specific domains, and showcases current products. The 31st AES Conference solicits contributions to the field of high resolution audio, including, but not limited to, the following domains and topics: High resolution recording issues * Bandwidth, sampling rate, dynamic resolution and spatial representation. * Analog and digital recording equipment Processing, manipulation and preparation of high resolution signals * High quality analog design * A/D and D/A conversion * Format and sample rate interconversions * High-resolution signal processing, 1 to n bit paradigms * Spatial audio, virtual and acoustic spaces, virtual image manipulation Storage of high resolution audio * Current and future storage technology for high-density audio data * Overview of high resolution consumer formats * Copy protection * Access speed, data reliability, bit packing and compression * Professional archival formats and future-proofing Electronic delivery of high resolution audio * Network (wired and wireless) systems/delivery of high quality audio content * Current and future formats for streaming and file delivery of high resolution audio * Bandwidth * Digital radio and broadcast applications including multichannel audio Maintaining quality at playback * Evolving technology for multiformat players * PC-based playback: configuration and interfacing * Converter technologies * Jitter/interface/power supplies and other related forms of noise * Digital amplification e.g., Class-D amplifiers Perception * Perceptual modeling. * Objective evaluation and subjective performance of high-resolution audio * Objective measurement and resolution issues * Subjective procedures and evaluation psychology +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ SUBMISSIONS Submissions, which will be peer-reviewed, may be in the following categories: - paper (to be presented in the main sessions) - poster or demonstration (to be presented in the poster sessions) - original composition demonstrating features of high resolution audio (to be showcased throughout the conference) - tutorial, panel or workshop proposals (see conference web site for details) Recording companies. publishers, software and hardware developers, etc., are invited to contact the programme committee regarding exhibition space. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DEADLINES Deadline for submissions of tutorials, panels and workshops: Feb. 2nd 2007. Deadline for submissions of papers and posters/demos: Feb. 2nd 2007. Deadline for exhibitor space: June 1st 2007. Please see the conference website for more information; http://www.aes.org/events/31/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061219/10105d85/attachment-0001.html From betty.woessner at elec.qmul.ac.uk Tue Dec 19 11:42:02 2006 From: betty.woessner at elec.qmul.ac.uk (Betty Woessner) Date: Thu Dec 21 08:12:46 2006 Subject: [linux-audio-dev] 31st International AES Conference - New Directions in High Resolution Audio Message-ID: <001e01c7238c$af8e7150$3821258a@vpn.elec.qmul.ac.uk> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 31st International AES Conference - New Directions in High Resolution Audio June 25-27, 2007 London, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Submissions site now open! Please let the conference organizers know of your intent to contribute or attend. Further detail available at http://www.aes.org/events/31/ The 31st International Audio Engineering Society Conference, entitled New Directions in High Resolution Audio, will be held at Queen Mary, University of London, from June 25th-27th, 2007. This Conference is concerned with the promotion and delivery of high resolution audio, by maintaining quality throughout the recording and playback chain with current and future technologies. It reflects the tremendous recent growth of high resolution audio techniques and products intended for use throughout the audio recording and playback chain. However, issues remain on how to avoid bottlenecks where quality is compromised, and how to maintain and encourage high resolution audio in an everchanging marketplace. These concerns are of interest to the audio engineering, recording and production industries, as well as to education and academia. We aim to provide a place for the exchange of news, issues and results, by bringing together researchers , developers, educators, students and professional users, working in fields that contribute to high resolution audio, to present original theoretical or practical work. It also serves as a discussion forum, provides introductory and in-depth information in specific domains, and showcases current products. The 31st AES Conference solicits contributions to the field of high resolution audio, including, but not limited to, the following domains and topics: High resolution recording issues * Bandwidth, sampling rate, dynamic resolution and spatial representation. * Analog and digital recording equipment Processing, manipulation and preparation of high resolution signals * High quality analog design * A/D and D/A conversion * Format and sample rate interconversions * High-resolution signal processing, 1 to n bit paradigms * Spatial audio, virtual and acoustic spaces, virtual image manipulation Storage of high resolution audio * Current and future storage technology for high-density audio data * Overview of high resolution consumer formats * Copy protection * Access speed, data reliability, bit packing and compression * Professional archival formats and future-proofing Electronic delivery of high resolution audio * Network (wired and wireless) systems/delivery of high quality audio content * Current and future formats for streaming and file delivery of high resolution audio * Bandwidth * Digital radio and broadcast applications including multichannel audio Maintaining quality at playback * Evolving technology for multiformat players * PC-based playback: configuration and interfacing * Converter technologies * Jitter/interface/power supplies and other related forms of noise * Digital amplification e.g., Class-D amplifiers Perception * Perceptual modeling. * Objective evaluation and subjective performance of high-resolution audio * Objective measurement and resolution issues * Subjective procedures and evaluation psychology +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ SUBMISSIONS Submissions, which will be peer-reviewed, may be in the following categories: - paper (to be presented in the main sessions) - poster or demonstration (to be presented in the poster sessions) - original composition demonstrating features of high resolution audio (to be showcased throughout the conference) - tutorial, panel or workshop proposals (see conference web site for details) Recording companies. publishers, software and hardware developers, etc., are invited to contact the programme committee regarding exhibition space. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DEADLINES Deadline for submissions of tutorials, panels and workshops: Feb. 2nd 2007. Deadline for submissions of papers and posters/demos: Feb. 2nd 2007. Deadline for exhibitor space: June 1st 2007. Please see the conference website for more information; http://www.aes.org/events/31/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061219/61e0b695/attachment.html From mlang at delysid.org Thu Dec 21 09:40:30 2006 From: mlang at delysid.org (Mario Lang) Date: Thu Dec 21 09:40:25 2006 Subject: [linux-audio-dev] ALSA performance issues? Message-ID: <87bqlxe2ht.fsf@x2.delysid.org> Hi. I just tried to get sound working on a LinkSys NSLU2 (ARM) running Debian Etch using a USB sound card. What I discovered I find pretty strange, and would like to know some more details. Apparently, all ALSA native clients don't manage to play sound click-free, they actually have underruns all the time. However, if I use OSS (via the snd-pcm-oss module) and set libao to use the oss driver, I get perfect playback with about 20% CPU use at maxiumum by the user-space app playing/decoding files. This is a bit strange, isn't it. OSS-emulation actually uses the same kernel code to access the actual hardware. I am just very vaguely familiar with the whole ALSA architecture, but it feels as if the problem here actually lies inside the user-space alsa libraries? Did anyone ever see such an effect, and investigate more closely what is the reason for the difference? -- CYa, Mario | Debian Developer .''`. | Get my public key via finger mlang@db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- From cladisch at fastmail.net Thu Dec 21 10:07:27 2006 From: cladisch at fastmail.net (Clemens Ladisch) Date: Thu Dec 21 10:08:24 2006 Subject: [linux-audio-dev] ALSA performance issues? In-Reply-To: <87bqlxe2ht.fsf@x2.delysid.org> References: <87bqlxe2ht.fsf@x2.delysid.org> Message-ID: <1166713647.26562.281535112@webmail.messagingengine.com> Mario Lang wrote: > I just tried to get sound working on a LinkSys NSLU2 (ARM) running > Debian Etch using a USB sound card. > > What I discovered I find pretty strange, and would like to know some > more details. Apparently, all ALSA native clients don't > manage to play sound click-free, they actually have underruns all the > time. However, if I use OSS (via the snd-pcm-oss module) and set > libao to use the oss driver, I get perfect playback with about > 20% CPU use at maxiumum by the user-space app playing/decoding files. Does the same happen when ALSA clients play to device "hw:0" as opposed to the default dmix device? Regards, Clemens From green at redhat.com Thu Dec 21 13:27:40 2006 From: green at redhat.com (Anthony Green) Date: Thu Dec 21 14:18:09 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166667066.2907.34.camel@localhost.localdomain> References: <1166658214.3172.60.camel@localhost.localdomain> <1166667066.2907.34.camel@localhost.localdomain> Message-ID: <1166725660.2952.15.camel@localhost.localdomain> On Wed, 2006-12-20 at 21:11 -0500, Paul Davis wrote: > the "standard" specifies that LADSPA_PATH be used if set. thus, distros > that package LADSPA should set LADPSA_PATH in /etc/profile and its > various equivalents. Ok, then maybe a good solution for now is to have our ladspa package generate an /etc/profile.d/ladspa.sh file at install-time that exports a system-dependent LADSPA_PATH, like export LADSPA_PATH=$HOME/.ladspa/sse2:$HOME/.ladspa:/usr/local/lib/ladspa/sse2:/usr/local/lib/ladspa:/usr/lib/ladspa/sse2:/usr/lib/ladspa ...for sse2-enabled platforms (for instance). Then plugin packagers can build and install any number of different plugin builds as long as they land in directories known by the ladspa package installer. Same goes for DSSI_PATH. AG From nando at ccrma.Stanford.EDU Thu Dec 21 15:39:11 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Thu Dec 21 15:39:22 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166658214.3172.60.camel@localhost.localdomain> References: <1166658214.3172.60.camel@localhost.localdomain> Message-ID: <1166733551.8812.26.camel@cmn3.stanford.edu> On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote: > 2. We build binaries for the lowest common denominator, so the plugins > you'll find in Fedora, for instance, don't take advantage of SSE > hardware or instruction scheduling for different processors. This can > make a huge difference. What would be nice is if we could distribute an > RPM containing a plurality of plugin builds, and then have the > application load the plugin matching the capabilities the execution > platform. Perhaps it would be possible to create packages for "i686" in addition of packages compiled for the "i386" architecture? I think I used to do that for my Planet CCRMA packages... but I don't think I ever saw a noticeable difference in performance. -- Fernando From iain at g7iii.net Thu Dec 21 16:19:04 2006 From: iain at g7iii.net (Iain Young) Date: Thu Dec 21 16:19:14 2006 Subject: [linux-audio-dev] LADSPA_Data audio values Message-ID: <20061221211903.GA14158@g7iii.net> Hi All, I'm trying to write a LADSPA plugin to do the following: Given n inputs (lets say 4), and one output, It should present the highest "priority" input on the output. Input 1 is the lowest priority, with Input 4 being the highest. In order to write this in code, within the runPriomux function, I do this: y=-1; for (i=0; i<=3; i++) { pfBuffer=*(pfInput[i]++); if (pfBuffer > -1.0f) y=i; } if (y!=-1) *(pfOutput++)=pfBuffer; i is the input channel (0-3, not 1-4, but you know what I mean) y is what is supposed to be the highest priority channel with audio on it. Now..here's where Im confused. I thought the values for audio samples in LADSPA were -1.0f...1.0f (with -1.0f being infinity). This doesn't seem to work, as the above code always appears to think that the 4th input (i=3) has data on it, even if it's muted in ardour (via another bus that's single output is connected to input 4...) I've also looked at the code of meterbridge, and tried using -70.0f, but with the same problem...Anyone want to plant me a clue on what I'm doing wrong ? I've attached the entire plugin source below. It's really been ripped off of the example amp in the LADSPA SDK I'm afraid.... Thanks in advance for any help, this last bit is driving me mad, now I've worked out how to code plugins! All the Best Iain -------------- next part -------------- A non-text attachment was scrubbed... Name: priomux.c Type: text/x-csrc Size: 6388 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061221/f95e5455/priomux.bin From cannam at all-day-breakfast.com Thu Dec 21 16:28:02 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Thu Dec 21 16:28:47 2006 Subject: [linux-audio-dev] LADSPA_Data audio values In-Reply-To: <20061221211903.GA14158@g7iii.net> References: <20061221211903.GA14158@g7iii.net> Message-ID: <200612212128.02985.cannam@all-day-breakfast.com> On Thursday 21 Dec 2006 21:19, Iain Young wrote: > Now..here's where Im confused. I thought the values for audio samples > in LADSPA were -1.0f...1.0f (with -1.0f being infinity). The range is a voltage range. It's -1.0 to +1.0 where 0.0 is effectively -Inf dB, -1.0 is 0dB at negative voltage and +1.0 is 0dB at positive voltage. "Digital silence" is all zeroes, not all -1.0s. Though inputs coming from hardware will be low level noise rather than absolute silence. Chris From green at redhat.com Thu Dec 21 16:31:12 2006 From: green at redhat.com (Anthony Green) Date: Thu Dec 21 16:33:06 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166733551.8812.26.camel@cmn3.stanford.edu> References: <1166658214.3172.60.camel@localhost.localdomain> <1166733551.8812.26.camel@cmn3.stanford.edu> Message-ID: <1166736672.3481.6.camel@localhost.localdomain> On Thu, 2006-12-21 at 12:39 -0800, Fernando Lopez-Lezcano wrote: > Perhaps it would be possible to create packages for "i686" in addition > of packages compiled for the "i386" architecture? I think I used to do > that for my Planet CCRMA packages... but I don't think I ever saw a > noticeable difference in performance. I think one big win will be with compiling certain plugins to use SSE floating point in order to eliminate denormal delays. As for creating multiple packages... I don't yet know to what extent the Fedora infrastructure (yum, rpm, etc) will handle this. Building them all in one package seems like the simplest thing for now and we can hack the ladspa spec file to generate /etc/profile.d/ladspa.sh based on the contents of /proc/cpuinfo at install time. The plugin packages aren't that big anyways. AG From cannam at all-day-breakfast.com Thu Dec 21 18:39:12 2006 From: cannam at all-day-breakfast.com (Chris Cannam) Date: Thu Dec 21 18:56:45 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166667158.2907.37.camel@localhost.localdomain> References: <1166658214.3172.60.camel@localhost.localdomain> <1166662949.17056.59.camel@localhost> <1166667158.2907.37.camel@localhost.localdomain> Message-ID: <200612212339.12213.cannam@all-day-breakfast.com> On Thursday 21 Dec 2006 02:12, Paul Davis wrote: > "/usr/local/lib64/ladspa:/usr/local/lib/ladspa:/usr/lib64/ladspa:/usr >/lib/ladspa:/Library/Audio/Plug-Ins/LADSPA"; } Shouldn't you also have $HOME/Library/Audio/Plug-Ins/LADSPA or some such on OS/X? Chris IANA OS/X developer From k.s.matheussen at notam02.no Fri Dec 22 04:44:10 2006 From: k.s.matheussen at notam02.no (Kjetil Svalastog Matheussen) Date: Fri Dec 22 04:51:28 2006 Subject: [linux-audio-dev] [ANN] das_watchdog V0.2.5 and jack_capture V0.9.3 Message-ID: Download from http://www.notam02.no/arkiv/src/ das_watchdog 0.2.5 ================== Whenever a program locks up the machine, das_watchdog will temporarily sets all realtime process to non-realtime for 8 seconds. You will get an xmessage window up on the screen whenever that happens. Changes 0.2.4->0.2.5 -------------------- *Let the test thread run with SCHED_FIFO priority using the lowest priority. Should hopefully stop all the unnecessary reports. (This change has been tested quite thoroughly) jack_capture v0.9.3 =================== jack_capture is a program for recording soundfiles with jack. Its default operation is 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. Note: Anyone using 0.9.2 should upgrade to 0.9.3! 0.9.2 will most likely hang during startup. :-( (I'm going to start testing my software before releasing from now on, this one was very embarrasing.) Distros: If there is a system for doing so, you should mark 0.9.2 as unusable. Changes 0.3.9 -> 0.9.3 ----------------------- *Fixed horrible deadlock in 0.9.2. Bug found by Ken Restivo. *Fix for a potensional deadlock. *Added the --silent/-s argument. *Some smaller fixes. *If recording to wav (the default) and the the 4GB limitation is reached, automatically close the file and continue writing to a new file with an autogenerated name. *Added the --version/-v argument. *Changed default number of zeros in the autogenerated filename to 1. *Better error output. *Autogenerate code to check if various formats are supported by sndlibfile. *Bumped version up to 0.9. jack_capture should reach a 1.0 state quite soon. *Changed the name of --recording-time to --duration to match -d. From ben at glw.com Fri Dec 22 09:25:35 2006 From: ben at glw.com (Ben Loftis) Date: Fri Dec 22 09:25:31 2006 Subject: [linux-audio-dev] Re: LADSPA_Data audio values In-Reply-To: <20061222095139.3403D5133708@music.columbia.edu> References: <20061222095139.3403D5133708@music.columbia.edu> Message-ID: <458BEADF.9050404@glw.com> > Message: 3 > Date: Thu, 21 Dec 2006 21:19:04 +0000 > From: iain@g7iii.net (Iain Young) > Subject: [linux-audio-dev] LADSPA_Data audio values > To: linux-audio-dev@music.columbia.edu > Message-ID: <20061221211903.GA14158@g7iii.net> > Content-Type: text/plain; charset="us-ascii" > > Hi All, > > I'm trying to write a LADSPA plugin to do the following: > > Given n inputs (lets say 4), and one output, It should present the > highest "priority" input on the output. Input 1 is the lowest priority, > with Input 4 being the highest. > > In order to write this in code, within the runPriomux function, I do > this: > > y=-1; > for (i=0; i<=3; i++) > { > pfBuffer=*(pfInput[i]++); > if (pfBuffer > -1.0f) > y=i; > } > if (y!=-1) > *(pfOutput++)=pfBuffer; > > Hi Iain, I don't know your application, but this looks wrong. If you are trying to choose between various microphones, and only output the microphone with the highest priority that has audio on it, (i.e. an automixer), then you're going to have to do a bit more work than this. Here are the immediate problems I see (Chris Cannam already indicated the first 2) 1) 0.0f indicates silence, not -1.0f 2) A microphone input will have some noise on it, you'll need an adjustable threshold value which separates the "on" state from the "off" 3) You can't do this on a sample-by-sample basis, you need some time averaging: 3a) you need to implement a rectified, running average value of all 4 inputs 3b) you'll need to mix the values of all four buffers into the output, with a smoothly changing level control on each input controlled by the logic 4) Make sure the "decay" of the envelope is kinda long ...this will keep a speaker from getting cut off if someody else coughs or whatever There are other subtleties that apply to an automixer, but this is enough to get started. -Ben Loftis From iain at g7iii.net Fri Dec 22 16:40:27 2006 From: iain at g7iii.net (Iain Young) Date: Fri Dec 22 16:40:35 2006 Subject: [linux-audio-dev] Re: LADSPA_Data audio values In-Reply-To: <458BEADF.9050404@glw.com> References: <20061222095139.3403D5133708@music.columbia.edu> <458BEADF.9050404@glw.com> Message-ID: <20061222214027.GA31112@g7iii.net> Hi Ben, You Wrote: > 1) 0.0f indicates silence, not -1.0f > 2) A microphone input will have some noise on it, you'll need an > adjustable threshold value which separates the "on" state from the "off" > 3) You can't do this on a sample-by-sample basis, you need some time > averaging: > 3a) you need to implement a rectified, running average value of all 4 > inputs > 3b) you'll need to mix the values of all four buffers into the output, > with a smoothly changing level control on each input controlled by the logic > 4) Make sure the "decay" of the envelope is kinda long ...this will > keep a speaker from getting cut off if someody else coughs or whatever Thanks for the additional feedback, The sources are actually all software rather than any hardware microphones. I also have the gate plugin inline with each of the 4 inputs, prior to feeding them into my plugin. It was really written, so I could have music, ISS Audio, Gaim notifications etc, and If any of the Astronauts say something, or someone logs on MSN/IRC, then any music I'm listening to gets overridden. It currently works for me, but I need to do some cleanup, and do a stereo version. I'm also thinking of a modified version to handle the situation where I'm outputting audio to my 5.1 Home Theatre system. I had named it 'PrioMux' (Priority Multiplexer), but if the correct term is 'Auto Mixer', then I can easily change it before release. Best Regards Iain From mlang at delysid.org Sat Dec 23 08:08:23 2006 From: mlang at delysid.org (Mario Lang) Date: Sat Dec 23 08:24:04 2006 Subject: [linux-audio-dev] ALSA performance issues? In-Reply-To: <1166713647.26562.281535112@webmail.messagingengine.com> (Clemens Ladisch's message of "Thu, 21 Dec 2006 16:07:27 +0100") References: <87bqlxe2ht.fsf@x2.delysid.org> <1166713647.26562.281535112@webmail.messagingengine.com> Message-ID: <87y7oydak8.fsf@x2.delysid.org> "Clemens Ladisch" writes: > Mario Lang wrote: >> I just tried to get sound working on a LinkSys NSLU2 (ARM) running >> Debian Etch using a USB sound card. >> >> What I discovered I find pretty strange, and would like to know some >> more details. Apparently, all ALSA native clients don't >> manage to play sound click-free, they actually have underruns all the >> time. However, if I use OSS (via the snd-pcm-oss module) and set >> libao to use the oss driver, I get perfect playback with about >> 20% CPU use at maxiumum by the user-space app playing/decoding files. > > Does the same happen when ALSA clients play to device "hw:0" as > opposed to the default dmix device? Excuse my ignorance please, but how do I reliably determine if dmix is the default device? For instance, ogg123, which uses libao, only offers -o card:N and such, but no -o device:"string", so I am kind of wondering if libao clients do perhaps always play on a hw device? I've tried to decipher the configuration in /usr/share/alsa, but I didn't really come far. dmix is definitely defined there, but how do I know it is the default? In any case, so far, playback only works through alsa oss emulation. native alsa just underuns like hell. -- CYa, Mario From mlang at delysid.org Sat Dec 23 08:25:14 2006 From: mlang at delysid.org (Mario Lang) Date: Sat Dec 23 08:39:27 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <1166733551.8812.26.camel@cmn3.stanford.edu> (Fernando Lopez-Lezcano's message of "Thu, 21 Dec 2006 12:39:11 -0800") References: <1166658214.3172.60.camel@localhost.localdomain> <1166733551.8812.26.camel@cmn3.stanford.edu> Message-ID: <87tzzmd9s5.fsf@x2.delysid.org> Fernando Lopez-Lezcano writes: > On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote: >> 2. We build binaries for the lowest common denominator, so the plugins >> you'll find in Fedora, for instance, don't take advantage of SSE >> hardware or instruction scheduling for different processors. This can >> make a huge difference. What would be nice is if we could distribute an >> RPM containing a plurality of plugin builds, and then have the >> application load the plugin matching the capabilities the execution >> platform. > > Perhaps it would be possible to create packages for "i686" in addition > of packages compiled for the "i386" architecture? I think I used to do > that for my Planet CCRMA packages... but I don't think I ever saw a > noticeable difference in performance. I still think the only true way to solve these issues is proper runtime CPU detection, and optimized routines for specific CPUs. This way, you do not extensively duplicate data. And you keep the installation process simple for your users, and you can distribute your packages in a standard way, without needing to care about the i686 or whatever details. JACK already does such a thing for its SSE mixing code... mplayer also does something similar. Simply maintain some function pointers for your algorithms that you setup at init time after you figured out what the best implementations are. You could even give them a spin by comparing performance at runtime, and deciding on the results (the linux kernel does that for crypto and raid algorithms). You can even have gcc help you optimize for specific targets, simply put target-specific code in a separate C file, compile it with your optimisation options, and make sure in your program, the code only gets called if this target has been detected. This is especially cool if you think about a user changing ther hardware components, but leaving their dsk driver untouched. Imagine you pull your disk out of a certain machine, put it into another (with another CPU type), and boot up. With runtime CPU detection, you get best possible performance immediately, no need to reinstall any packages. -- CYa, Mario | Debian Developer .''`. | Get my public key via finger mlang@db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- From James at superbug.co.uk Sat Dec 23 10:03:13 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Sat Dec 23 10:03:22 2006 Subject: [linux-audio-dev] ALSA performance issues? In-Reply-To: <87bqlxe2ht.fsf@x2.delysid.org> References: <87bqlxe2ht.fsf@x2.delysid.org> Message-ID: <458D4531.6010406@superbug.co.uk> Mario Lang wrote: > Hi. > > I just tried to get sound working on a LinkSys NSLU2 (ARM) running > Debian Etch using a USB sound card. > > What I discovered I find pretty strange, and would like to know some > more details. Apparently, all ALSA native clients don't > manage to play sound click-free, they actually have underruns all the > time. However, if I use OSS (via the snd-pcm-oss module) and set > libao to use the oss driver, I get perfect playback with about > 20% CPU use at maxiumum by the user-space app playing/decoding files. > > This is a bit strange, isn't it. OSS-emulation actually uses the same > kernel code to access the actual hardware. I am just very vaguely > familiar with the whole ALSA architecture, but it feels as if > the problem here actually lies inside the user-space alsa libraries? > > Did anyone ever see such an effect, and investigate more closely > what is the reason for the difference? Which applications have this problem? What quite often happens is an application's ALSA interface code is written wrongly. For example, if the application uses OSS is uses a nice big sound buffer, so no clicks, but if the application uses ALSA, it requests minute buffer sizes that results in lots of clicks. So, please explain which applications have the problem. James From zanga.mail at gmail.com Mon Dec 25 09:15:16 2006 From: zanga.mail at gmail.com (Stefano D'Angelo) Date: Tue Dec 26 13:52:59 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <87tzzmd9s5.fsf@x2.delysid.org> References: <1166658214.3172.60.camel@localhost.localdomain> <1166733551.8812.26.camel@cmn3.stanford.edu> <87tzzmd9s5.fsf@x2.delysid.org> Message-ID: <160c13350612250615o204f34d1y83677fee05a9623c@mail.gmail.com> Well, this topic truly interests me. I am the main developer of FreeADSP, my name's Stefano, and this is the first time I write in here. You know, in my application I'll try to make different kind of audio processing plugins work together using a compatibility layer (plugin loader plugins). I realize that it could be something that other people might be interested to as well, so maybe it's more convenient for the whole community if we develop a kind of wrapping library for different plugin architectures which also contains info on how to retrieve plugins (maybe such as fontconfig does for fonts, and maybe we could also use SWIG). What do you think about it? Let me know! Stefano 2006/12/23, Mario Lang : > > Fernando Lopez-Lezcano writes: > > > On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote: > >> 2. We build binaries for the lowest common denominator, so the plugins > >> you'll find in Fedora, for instance, don't take advantage of SSE > >> hardware or instruction scheduling for different processors. This can > >> make a huge difference. What would be nice is if we could distribute > an > >> RPM containing a plurality of plugin builds, and then have the > >> application load the plugin matching the capabilities the execution > >> platform. > > > > Perhaps it would be possible to create packages for "i686" in addition > > of packages compiled for the "i386" architecture? I think I used to do > > that for my Planet CCRMA packages... but I don't think I ever saw a > > noticeable difference in performance. > > I still think the only true way to solve these issues is proper > runtime CPU detection, and optimized routines for specific CPUs. > > This way, you do not extensively duplicate data. And you keep the > installation process simple for your users, and you can distribute > your packages in a standard way, without needing to care > about the i686 or whatever details. > > JACK already does such a thing for its SSE mixing code... > mplayer also does something similar. > > Simply maintain some function pointers for your algorithms that you setup > at init time after you figured out what the best implementations are. > You could even give them a spin by comparing performance at runtime, > and deciding on the results (the linux kernel does that for crypto > and raid algorithms). > > You can even have gcc help you optimize for specific targets, simply > put target-specific code in a separate C file, compile it with your > optimisation options, and make sure in your program, the code only > gets called if this target has been detected. > > This is especially cool if you think about a user changing ther hardware > components, but leaving their dsk driver untouched. Imagine you pull > your disk out of a certain machine, put it into another (with another CPU > type), and boot up. With runtime CPU detection, you get best possible > performance immediately, no need to reinstall any packages. > > -- > CYa, > Mario | Debian Developer > .''`. | Get my public key via finger mlang@db.debian.org > : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 > `. `' > `- http://www.staff.tugraz.at/mlang/> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061225/e4d063f3/attachment-0001.html From jesse at essej.net Tue Dec 26 22:52:47 2006 From: jesse at essej.net (Jesse Chappell) Date: Tue Dec 26 22:53:32 2006 Subject: [linux-audio-dev] plugin loaders In-Reply-To: <200612212339.12213.cannam@all-day-breakfast.com> References: <1166658214.3172.60.camel@localhost.localdomain> <1166662949.17056.59.camel@localhost> <1166667158.2907.37.camel@localhost.localdomain> <200612212339.12213.cannam@all-day-breakfast.com> Message-ID: On 12/21/06, Chris Cannam wrote: > On Thursday 21 Dec 2006 02:12, Paul Davis wrote: > > "/usr/local/lib64/ladspa:/usr/local/lib/ladspa:/usr/lib64/ladspa:/usr > >/lib/ladspa:/Library/Audio/Plug-Ins/LADSPA"; } > > Shouldn't you also have $HOME/Library/Audio/Plug-Ins/LADSPA or some such > on OS/X? Yes, that is a valid point. FWIW, that fallback code is not used in practice in Ardour's OS X release application bundle. It sets LADSPA_PATH and includes the above directory too. jlc From dlphillips at woh.rr.com Wed Dec 27 07:17:39 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed Dec 27 07:07:05 2006 Subject: [linux-audio-dev] nohid boot option ? Message-ID: <45926463.4050300@woh.rr.com> Greetings: My ancient 800 MHz machine has dead PS/2 ports so I plugged my mouse and keyboard into its available USB ports. Alas, the keyboard disappears after selecting my kernel image (Demudi) in grub. I'm away from the machine right now so I don't have the exact text of the error message. However, I do recall that it refers to a USB-related IRQ error. I tried to install the 32-bit version of 64Studio, but the error occurs during the configuration process: As soon as I press Enter at the boot prompt the keyboard is no longer present to the system. :( I Googled for some more information regarding the problem and found that it is in fact a known issue. However, none of the proposed solutions worked for me. I also sent messages to the 64Studio dev list and to Free and Daniel, but I've heard nothing back from them or the list (I think my email to the list isn't getting there). One thing does work: Dynebolic includes a nohid boot parameter that does the trick ('linux nohid'), so I can still boot into the machine and access my data. So, my question is: What's Dynebolic doing that the other distros aren't ? I'd surely like to boot directly into my system, and I'd like to install 32-bit 64Studio, but I can't do either until I solve this problem. Any suggestions ? Best, dp From mlang at delysid.org Wed Dec 27 09:03:33 2006 From: mlang at delysid.org (Mario Lang) Date: Wed Dec 27 09:03:32 2006 Subject: [linux-audio-dev] ALSA performance issues? In-Reply-To: <458D4531.6010406@superbug.co.uk> (James Courtier-Dutton's message of "Sat, 23 Dec 2006 15:03:13 +0000") References: <87bqlxe2ht.fsf@x2.delysid.org> <458D4531.6010406@superbug.co.uk> Message-ID: <87odppjv0q.fsf@x2.delysid.org> James Courtier-Dutton writes: > Mario Lang wrote: >> Hi. >> >> I just tried to get sound working on a LinkSys NSLU2 (ARM) running >> Debian Etch using a USB sound card. >> >> What I discovered I find pretty strange, and would like to know some >> more details. Apparently, all ALSA native clients don't >> manage to play sound click-free, they actually have underruns all the >> time. However, if I use OSS (via the snd-pcm-oss module) and set >> libao to use the oss driver, I get perfect playback with about >> 20% CPU use at maxiumum by the user-space app playing/decoding files. >> >> This is a bit strange, isn't it. OSS-emulation actually uses the same >> kernel code to access the actual hardware. I am just very vaguely >> familiar with the whole ALSA architecture, but it feels as if >> the problem here actually lies inside the user-space alsa libraries? >> >> Did anyone ever see such an effect, and investigate more closely >> what is the reason for the difference? > > Which applications have this problem? > What quite often happens is an application's ALSA interface code is > written wrongly. For example, if the application uses OSS is uses a > nice big sound buffer, so no clicks, but if the application uses ALSA, > it requests minute buffer sizes that results in lots of clicks. > So, please explain which applications have the problem. ogg123 and mpg321 (with libao set to alsa09). I am not sure I tried alsaplayer, maybe not. Was looking for a lightweight command-line tool, so no xmms or whatever. -- CYa, Mario From fons at kokkinizita.net Sat Dec 30 18:37:32 2006 From: fons at kokkinizita.net (Fons Adriaensen) Date: Sat Dec 30 18:34:14 2006 Subject: [linux-audio-dev] 2007.. Message-ID: <20061230233732.GC5838@linux-1.site> Hello all, First of all, my best wishes for 2007 to all Linux Audio Developers ! 2007 will be a special year for me. As some of you already know, I said goodbey at Alcatel Space two months ago, and starting 8 Jan 2007 I'll be working at LAE - Laboratorio di Acustica ed Elettroacustica - in Parma, Italy. LAE is an acoustics and electro-acoustics research and consultancy lab operated by the university of Parma and by three companies active in the area of acoustics and audio. My activities in LAD will continue of course, after maybe a short break while the dust of moving to Italy settles. Looking forward to meet you all at LAC2007 in Berlin ! -- FA Lascia la spina, cogli la rosa. From Dr.Graef at t-online.de Sat Dec 30 19:17:18 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Sat Dec 30 19:11:16 2006 Subject: [linux-audio-dev] 2007.. In-Reply-To: <20061230233732.GC5838@linux-1.site> References: <20061230233732.GC5838@linux-1.site> Message-ID: <4597018E.7050708@t-online.de> Fons Adriaensen wrote: > 2007 will be a special year for me. As some of you already know, I said goodbey > at Alcatel Space two months ago, and starting 8 Jan 2007 I'll be working at LAE > - Laboratorio di Acustica ed Elettroacustica - in > Parma, Italy. Congrats for the new job! Hope you'll enjoy yourself in Italy. :) See you in Berlin. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag From ce at christeck.de Sat Dec 30 20:25:39 2006 From: ce at christeck.de (Christoph Eckert) Date: Sat Dec 30 20:22:27 2006 Subject: [linux-audio-dev] 2007.. In-Reply-To: <4597018E.7050708@t-online.de> References: <20061230233732.GC5838@linux-1.site> <4597018E.7050708@t-online.de> Message-ID: <200612310225.40207.ce@christeck.de> > Congrats for the new job! Hope you'll enjoy yourself in Italy. :) See > you in Berlin. of even better in Italy - will there be a LAD-party?!? ;-) ce From rlrevell at joe-job.com Sun Dec 31 00:46:20 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Sun Dec 31 00:46:52 2006 Subject: [linux-audio-dev] ALSA performance issues? In-Reply-To: <87y7oydak8.fsf@x2.delysid.org> References: <87bqlxe2ht.fsf@x2.delysid.org> <1166713647.26562.281535112@webmail.messagingengine.com> <87y7oydak8.fsf@x2.delysid.org> Message-ID: <1167543980.15387.289.camel@mindpipe> On Sat, 2006-12-23 at 14:08 +0100, Mario Lang wrote: > Excuse my ignorance please, but how do I reliably determine > if dmix is the default device? For instance, ogg123, which uses > libao, only offers -o card:N and such, but no -o device:"string", so > I am kind of wondering if libao clients do perhaps always play on a > hw device? libao's ALSA device selection is pretty much correct - it uses "default" PCM if no device is specified, and other devices can be selected like so: ogg123 -d alsa09 -o dev:"hw:0,0" file.ogg Unfortunately the ALSA device selection syntax isn't documented in the manpage so I had to figure this out by code inspection and trial & error... Lee From dominique.michel at citycable.ch Sun Dec 31 05:52:22 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Sun Dec 31 05:57:37 2006 Subject: [linux-audio-dev] Re: [Alsa-user] alsa, oss and jack In-Reply-To: <1167549680.15387.310.camel@mindpipe> References: <20061230180628.7cad4802@localhost> <1167549680.15387.310.camel@mindpipe> Message-ID: <20061231115222.51c047b5@localhost> Le Sun, 31 Dec 2006 02:21:20 -0500, Lee Revell a ?crit : > On Sat, 2006-12-30 at 18:06 +0100, Dominique Michel wrote: > > The result was at the sound from flash 9 > > (some kind of worst case scenario) when listening to > > http://concerts.wolfgangsvault.com/ConcertDetail.aspx?id=2229|3385 was > > hopping all the time, when it's hopping without any .asoundrc only > > when I open or close a windows or when I shift from a virual desktop > > to another one. > > Did you install the latest Flash 9 beta? Earlier versions did not work > well for me. > > Lee > Thank you Bill and Lee. It is the last beta from portage in gentoo, that is 9.0.21.78 and it is the last version (installer 112006). After restarting not only alsa but the whole system and running flash on the same website with just 2 open windows in firefox, the sound work much better. The processor load was very high on the first test. And I am able to record from audacity without any .asoundrc file. Is it possible to run flash with jack? My wm is currently fvwm-crystal. I try to run arts with konqueror and arts with jack as sound server. I can see arts in the connection windows of qjackctl, the sound is here but already hoping with a processor load of 17% and I don't have flash in qjackctl. So, is it possible to run flash 9 with jack and firefox? Cheers, Dominique From dominique.michel at citycable.ch Sun Dec 31 06:28:41 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Sun Dec 31 06:48:13 2006 Subject: [linux-audio-dev] Re: [Alsa-user] alsa, oss and jack In-Reply-To: <20061231115222.51c047b5@localhost> References: <20061230180628.7cad4802@localhost> <1167549680.15387.310.camel@mindpipe> <20061231115222.51c047b5@localhost> Message-ID: <20061231122841.3aac51de@localhost> Le Sun, 31 Dec 2006 11:52:22 +0100, Dominique Michel a ?crit : > Le Sun, 31 Dec 2006 02:21:20 -0500, > Lee Revell a ?crit : > > > On Sat, 2006-12-30 at 18:06 +0100, Dominique Michel wrote: > > > The result was at the sound from flash 9 > > > (some kind of worst case scenario) when listening to > > > http://concerts.wolfgangsvault.com/ConcertDetail.aspx?id=2229|3385 was > > > hopping all the time, when it's hopping without any .asoundrc only > > > when I open or close a windows or when I shift from a virual desktop > > > to another one. > > > > Did you install the latest Flash 9 beta? Earlier versions did not work > > well for me. > > > > Lee > > > Thank you Bill and Lee. > > It is the last beta from portage in gentoo, that is 9.0.21.78 and it is the > last version (installer 112006). > > After restarting not only alsa but the whole system and running flash on the > same website with just 2 open windows in firefox, the sound work much better. > The processor load was very high on the first test. And I am able to record > from audacity without any .asoundrc file. > > Is it possible to run flash with jack? My wm is currently fvwm-crystal. I try > to run arts with konqueror and arts with jack as sound server. I can see arts > in the connection windows of qjackctl, the sound is here but already hoping > with a processor load of 17% and I don't have flash in qjackctl. So, is it > possible to run flash 9 with jack and firefox? > > Cheers, > Dominique I try with this in my .asoundrc: pcm.!default { type plug slave { pcm "jack" } } pcm.jack { type jack playback_ports { 0 alsa_pcm:playback_1 1 alsa_pcm:playback_2 } capture_ports { 0 alsa_pcm:capture_1 1 alsa_pcm:capture_2 } } But it doesn't work. I try it both with the jack-audigy configuration explained in the alsa sources (16 in and out, 48 kHz) and with only 2 in-out, 44.1 kHz and 1024 periods. The result was the same, flash start, i get a lot of output ports for flash (16 or more...) in qjackctl, when I try to connect one of those ports, I get "no ports available!". 30 seconds later or so, it is only 2 ports left for flash and when I try to connect one, flash crash as well as firefox and I get "unknown source port in attempted connection [alsa-jack.jackP.12333.59:out_000]" Cheers, Dominique From alberto.botti at gmail.com Sun Dec 31 07:10:54 2006 From: alberto.botti at gmail.com (Alberto Botti) Date: Sun Dec 31 07:27:25 2006 Subject: [linux-audio-dev] 2007.. In-Reply-To: <200612310225.40207.ce@christeck.de> References: <20061230233732.GC5838@linux-1.site> <4597018E.7050708@t-online.de> <200612310225.40207.ce@christeck.de> Message-ID: <1167567054.11085.2.camel@localhost.localdomain> Il giorno dom, 31/12/2006 alle 02.25 +0100, Christoph Eckert ha scritto: > > Congrats for the new job! Hope you'll enjoy yourself in Italy. :) See > > you in Berlin. > > of even better in Italy - will there be a LAD-party?!? Why not? :)