From lem0mel at gmail.com Wed Nov 1 02:30:17 2006 From: lem0mel at gmail.com (lemmel) Date: Wed Nov 1 02:30:38 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? Message-ID: <200611010830.18458.lem0mel@gmail.com> Hi everyone. for a project, we need to be able to play sound (at first look wav file), and we made several tests ; with a created stereo sound, we try to use alsa but the results doesn't fullfill our needs : sound played at the time, T, we want, and finished at the date, D=T+sound duration. (thi is a software with strict time constraints) The sound was always troncated (even with finished software such as xmms, amarok), and even randomly truncated, (sound created with audacity, and exported as WAV 16/32 bit etc). When we use OSS, all seems to be perfect. But, it seems that OSS is nowadays "deprecated", and consequently we shouldn't use OSS. What we can do ? Are our alsa results due to misconfigurations ? From krampenschiesser at freenet.de Wed Nov 1 06:06:14 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Wed Nov 1 05:55:43 2006 Subject: [linux-audio-dev] Clock/Sync tutorials, hints? Message-ID: <20061101120614.3bf8e2c0.krampenschiesser@freenet.de> Hi, do you know any good clock/sync tutorials out there? Or do you have any good hints on this? I hope you can help me. Scar -- Finagle's Eighth Law: If an experiment works, something has gone wrong. Finagle's Ninth Law: No matter what results are expected, someone is always willing to fake it. Finagle's Tenth Law: No matter what the result someone is always eager to misinterpret it. Finagle's Eleventh Law: No matter what occurs, someone believes it happened according to his pet theory. From jens.andreasen at chello.se Wed Nov 1 06:29:09 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Wed Nov 1 06:29:21 2006 Subject: [linux-audio-dev] Clock/Sync tutorials, hints? In-Reply-To: <20061101120614.3bf8e2c0.krampenschiesser@freenet.de> References: <20061101120614.3bf8e2c0.krampenschiesser@freenet.de> Message-ID: <1162380549.9224.226.camel@c80-216-124-251.bredband.comhem.se> krampenschiesser, you spend way too much time in Irish pubs! :-D On Wed, 2006-11-01 at 12:06 +0100, krampenschiesser@freenet.de wrote: Finagle's Eighth Law: If an experiment works, something has gone wrong. Finagle's Ninth Law: No matter what results are expected, someone is always willing to fake it. Finagle's Tenth Law: No matter what the result someone is always eager to misinterpret it. Finagle's Eleventh Law: No matter what occurs, someone believes it happened according to his pet theory. From krampenschiesser at freenet.de Wed Nov 1 06:53:06 2006 From: krampenschiesser at freenet.de (krampenschiesser@freenet.de) Date: Wed Nov 1 06:42:30 2006 Subject: [linux-audio-dev] Clock/Sync tutorials, hints? In-Reply-To: <1162380549.9224.226.camel@c80-216-124-251.bredband.comhem.se> References: <20061101120614.3bf8e2c0.krampenschiesser@freenet.de> <1162380549.9224.226.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <20061101125306.e1a00646.krampenschiesser@freenet.de> On Wed, 01 Nov 2006 12:29:09 +0100 Jens M Andreasen wrote: > krampenschiesser, you spend way too much time in Irish pubs! > :-D No I simply love fortune! From dplist at free.fr Wed Nov 1 07:10:50 2006 From: dplist at free.fr (David) Date: Wed Nov 1 07:11:32 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <200611010830.18458.lem0mel@gmail.com> References: <200611010830.18458.lem0mel@gmail.com> Message-ID: <20061101131050.1d572d1b.dplist@free.fr> On Wed, 01 Nov 2006 08:30:17 +0100 lemmel wrote: > Hi everyone. > > for a project, we need to be able to play sound (at first look wav > file), and we made several tests ; with a created stereo sound, we > try to use alsa but the results doesn't fullfill our needs : > > sound played at the time, T, we want, and finished at the date, D=T > +sound duration. > (thi is a software with strict time constraints) > > The sound was always troncated (even with finished software such as > xmms, amarok), and even randomly truncated, (sound created with > audacity, and exported as WAV 16/32 bit etc). > > When we use OSS, all seems to be perfect. > > But, it seems that OSS is nowadays "deprecated", and consequently we > shouldn't use OSS. What we can do ? Are our alsa results due to > misconfigurations ? I am not sure I understand your problems or your needs, but my advice is to use jack. It provides you with a very simple API that gives you sample accurate synchronicity and hides all the hard parts like directly dealing with the soundcard driver. If your client code is clean enough, then you can even evaluate with precision the latency of the software set made of your client, the jackd server and the soundcard driver backend. If you need to know the latency of your hardware, I invite you to google for jdelay, an measurement app. released by M. Fons Adriensen. Go read http://www.jackaudio.org/, you'll be delighted. BTW, thanks a lot to all the developpers of jack ! -- David From fons.adriaensen at skynet.be Wed Nov 1 08:38:02 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 1 08:36:11 2006 Subject: [linux-audio-dev] Alpha release of Aliki Message-ID: <20061101133802.GE6227@linux-1.site> For the brave: an alpha release of Aliki (Room Impulse Response Measurement) is now available on: http://users.skynet.be/solaris/linuxaudio along with a manual that should get you started. This is basically the code used at the LAC2006 workshop, cleaned up a but. As said, ALPHA, incomplete, probably lots of bugs. -- FA Lascia la spina, cogli la rosa. From arnold.krille at gmail.com Wed Nov 1 09:34:18 2006 From: arnold.krille at gmail.com (Arnold Krille) Date: Wed Nov 1 09:34:37 2006 Subject: [linux-audio-dev] Alpha release of Aliki In-Reply-To: <20061101133802.GE6227@linux-1.site> References: <20061101133802.GE6227@linux-1.site> Message-ID: <2def88b80611010634n4cff8db9w48882d217807ed5a@mail.gmail.com> 2006/11/1, Fons Adriaensen : > For the brave: an alpha release of Aliki (Room Impulse > Response Measurement) is now available Yippie! I've been wating for this since ... lac ;-) And I have been waiting for an integrated IR-measurment-tool for quite some years now. Thanks for the release, Fons! Arnold -- visit http://www.arnoldarts.de/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern k?nnte, w?rde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen. From k.s.matheussen at notam02.no Wed Nov 1 10:51:05 2006 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Wed Nov 1 10:54:37 2006 Subject: [linux-audio-dev] Re: alsa, oss , efficiency? In-Reply-To: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> Message-ID: lemmel: > > Hi everyone. > > for a project, we need to be able to play sound (at first look wav file), and > we made several tests ; with a created stereo sound, we try to use alsa but > the results doesn't fullfill our needs : > > sound played at the time, T, we want, and finished at the date, D=T+sound > duration. > (thi is a software with strict time constraints) > > The sound was always troncated (even with finished software such as xmms, > amarok), and even randomly truncated, (sound created with audacity, and > exported as WAV 16/32 bit etc). > > When we use OSS, all seems to be perfect. > > But, it seems that OSS is nowadays "deprecated", and consequently we shouldn't > use OSS. What we can do ? Are our alsa results due to misconfigurations ? > Only the oss modules in the linux kernel are deprecated. Programs using the OSS api will still continue to work, currently most importantly because of the oss emulation module in alsa. If you should choose between alsa and oss, and the oss version works just as well, or better than the alsa version, choose oss, because its a more portable API than alsa. However, if I were you, I would use sndlib, portaudio, jack, or some other higher level audio input/output library instead of oss or alsa. From ben at glw.com Wed Nov 1 10:48:37 2006 From: ben at glw.com (Ben Loftis) Date: Wed Nov 1 10:56:09 2006 Subject: [linux-audio-dev] Re: Alpha release of Aliki In-Reply-To: <20061101133616.B38133CB0FD7@music.columbia.edu> References: <20061101133616.B38133CB0FD7@music.columbia.edu> Message-ID: <4548C1D5.3070205@glw.com> Hi Fons. Can you please tell us more about Aliki? I am using Denis Sbragion's DRC program to generate an impulse response file, and his suite of graphing tools to generate various views of the measurement. What is the output of Aliki? Just an impulse response file? In what way is your method different than DRC? Does Aliki use ALSA or JACK for I/O? I'll have a look at the code tonight but I was hoping you could fill me in on the "big picture". Thanks, Ben Loftis From fons.adriaensen at skynet.be Wed Nov 1 11:22:13 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 1 11:20:19 2006 Subject: [linux-audio-dev] Re: Alpha release of Aliki In-Reply-To: <4548C1D5.3070205@glw.com> References: <20061101133616.B38133CB0FD7@music.columbia.edu> <4548C1D5.3070205@glw.com> Message-ID: <20061101162213.GF6227@linux-1.site> On Wed, Nov 01, 2006 at 09:48:37AM -0600, Ben Loftis wrote: > Can you please tell us more about Aliki? > > I am using Denis Sbragion's DRC program to generate an impulse response > file, and his suite of graphing tools to generate various views of the > measurement. > > What is the output of Aliki? Just an impulse response file? In what > way is your method different than DRC? Does Aliki use ALSA or JACK for I/O? The method used is linear or logarithmic sweeps and deconvolution. The object of Aliki is to make IR measurement easy. It has a graphical user interface, and can work with either ALSA directly or via JACK (it will also work without any audio interface for post-processing files). You will get a good idea of Aliki by reading the manual. Main functions are: - Generating sweep files. - Performing the actual measurement (up to 8 channels). - Deconvolution to get the IR. - Simple editing on the IR to prepare it for use. This is only a small subset of what it's planned to offer in the future. The measured IR can be exported to WAV files. Sox will convert this to the raw format expected by DRC. Aliki is not designed to replace DRC, but should complement it by providing an easy-to-use measurement solution. Some DRC-like functionality will be included in the future, but nothing of the sophistication of Denis Sbragion's magnificent software. -- FA Lascia la spina, cogli la rosa. From k.s.matheussen at notam02.no Wed Nov 1 11:47:58 2006 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Wed Nov 1 11:48:29 2006 Subject: [linux-audio-dev] [ANN] Snd-ls 0.9.7.7 and Ceres V0.46 In-Reply-To: References: Message-ID: Snd-ls v0.9.7.7 =============== Snd-ls is a distribution of Bill Schottstaedt's sound editor SND. Its target is people that don't know scheme very well, and don't want to spend too much time configuring Snd. It can also serve as a quick introduction to Snd and how it can be set up. Changes 0.9.7.1 -> 0.9.7.6: -Seems like the full menu patch was missing for all versions after 0.9.7.2, causing cutting (and probably other things) not to work. Download from http://www.notam02.no/arkiv/src/snd/ Ceres v0.46 =========== Ceres is a large program for doing various sound effects in the frequency domain and displaying sonograms. The program has been developed for about 10 years, and is mainly made by ?yvind Hammer with contributions from Jonathan Lee, Stanko Juzbasic and many others. Changes 0.45 -> 0.46 ------------------ -Fix to make pygtk1 build for Python 2.5. Bug found by Dave Phillips. Download from http://www.notam02.no/arkiv/src/ From a at gaydenko.com Wed Nov 1 11:52:03 2006 From: a at gaydenko.com (Andrew Gaydenko) Date: Wed Nov 1 11:55:24 2006 Subject: [linux-audio-dev] Alpha release of Aliki In-Reply-To: <20061101133802.GE6227@linux-1.site> References: <20061101133802.GE6227@linux-1.site> Message-ID: <200611011952.03327@goldspace.net> Fons, congratulates! Happy to see you and Aliki :-) Andrew ======= On Wednesday 01 November 2006 16:38, Fons Adriaensen wrote: ======= For the brave: an alpha release of Aliki (Room Impulse Response Measurement) is now available on: http://users.skynet.be/solaris/linuxaudio along with a manual that should get you started. This is basically the code used at the LAC2006 workshop, cleaned up a but. As said, ALPHA, incomplete, probably lots of bugs. From James at superbug.co.uk Wed Nov 1 15:55:03 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Wed Nov 1 15:55:11 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <200611010830.18458.lem0mel@gmail.com> References: <200611010830.18458.lem0mel@gmail.com> Message-ID: <454909A7.3010406@superbug.co.uk> lemmel wrote: > Hi everyone. > > for a project, we need to be able to play sound (at first look wav file), and > we made several tests ; with a created stereo sound, we try to use alsa but > the results doesn't fullfill our needs : > > sound played at the time, T, we want, and finished at the date, D=T+sound > duration. > (thi is a software with strict time constraints) > > The sound was always troncated (even with finished software such as xmms, > amarok), and even randomly truncated, (sound created with audacity, and > exported as WAV 16/32 bit etc). > > When we use OSS, all seems to be perfect. > > But, it seems that OSS is nowadays "deprecated", and consequently we shouldn't > use OSS. What we can do ? Are our alsa results due to misconfigurations ? > Lemmel, This might be a bug in ALSA. open a bug on the alsa bugtracker and see if it gets fixed. http://alsa-project.org/ If you can include a simple test program so that developers can reproduce the problem, that would help. James From lem0mel at gmail.com Wed Nov 1 16:17:19 2006 From: lem0mel at gmail.com (lemmel) Date: Wed Nov 1 16:17:25 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <454909A7.3010406@superbug.co.uk> References: <200611010830.18458.lem0mel@gmail.com> <454909A7.3010406@superbug.co.uk> Message-ID: <200611012217.20906.lem0mel@gmail.com> Le mercredi 01 novembre 2006 21:55, vous avez ?crit?: > This might be a bug in ALSA. open a bug on the alsa bugtracker and see > if it gets fixed. > http://alsa-project.org/ > > If you can include a simple test program so that developers can > reproduce the problem, that would help. I don't think it is a bug :-). It is too basic for a bug [1] : I just made a wav file and played it with xmms and amarok (thus I can reproduce the error by using the file). And when this players use ALSA, the playing is bad (randomly troncated), and when the players use OSS all work fine. I think it is bad ALSA settings (I am just too noob to know why, perhaps something in regard to sampling rate ?). [1] a so plain simple bug could had been detected sooner From lem0mel at gmail.com Wed Nov 1 16:20:34 2006 From: lem0mel at gmail.com (lemmel) Date: Wed Nov 1 16:20:46 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <20061101131050.1d572d1b.dplist@free.fr> References: <200611010830.18458.lem0mel@gmail.com> <20061101131050.1d572d1b.dplist@free.fr> Message-ID: <200611012220.36547.lem0mel@gmail.com> Le mercredi 01 novembre 2006 13:10, David a ?crit?: > I am not sure I understand your problems or your needs, but my advice is > to use jack. It provides you with a very simple API that gives you > sample accurate synchronicity and hides all the hard parts like > directly dealing with the soundcard driver. Are you sur I need to embarrase myself with an audio server, when all I need it is to play simple wav files on a dedicated machine ? > If your client code is clean enough, then you can even evaluate with > precision the latency of the software set made of your client, the > jackd server and the soundcard driver backend. If you need to know the > latency of your hardware, I invite you to google for jdelay, an > measurement app. released by M. Fons Adriensen. That is quite interresting, thanks for the information. From lem0mel at gmail.com Wed Nov 1 16:32:57 2006 From: lem0mel at gmail.com (lemmel) Date: Wed Nov 1 16:33:02 2006 Subject: [linux-audio-dev] Re: alsa, oss , efficiency? In-Reply-To: References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> Message-ID: <200611012232.58568.lem0mel@gmail.com> Le mercredi 01 novembre 2006 16:51, Kjetil S. Matheussen a ?crit?: > Only the oss modules in the linux kernel are deprecated. Programs using > the OSS api will still continue to work, currently most importantly > because of the oss emulation module in alsa. I knew that the oss module was deprecated, and I infered that using the OSS mecanism was too deprecated :-P. Are sure [1]? > If you should choose between alsa and oss, and the oss version works > just as well, or better than the alsa version, choose oss, because its a > more portable API than alsa. What do you mean by "the oss version works just as well, or better than the alsa version" ? > However, if I were you, I would use sndlib, portaudio, jack, or some other > higher level audio input/output library instead of oss or alsa. Well, all the files, that I will play, will have the same charactistics, do I really need to bother with an hi-level API [2] ? [1] I noticed that a lot of applications still use OSS, and I thought it was because the migration to ALSA was too complex. [2] Futhermore I am afraid that an hi-level API will produce time drifts in the playing. From paul at linuxaudiosystems.com Wed Nov 1 17:20:48 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Nov 1 17:25:40 2006 Subject: [linux-audio-dev] Re: alsa, oss , efficiency? In-Reply-To: <200611012232.58568.lem0mel@gmail.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> Message-ID: <1162419648.26663.21.camel@localhost.localdomain> On Wed, 2006-11-01 at 22:32 +0100, lemmel wrote: > Well, all the files, that I will play, will have the same charactistics, do I > really need to bother with an hi-level API [2] ? > > [1] I noticed that a lot of applications still use OSS, and I thought it was > because the migration to ALSA was too complex. > [2] Futhermore I am afraid that an hi-level API will produce time drifts in > the playing. you really have not provided us with much information on the nature of the problem you are seeing. dozens, hundreds, perhaps even thousands of us use ALSA and layers of software built on top of ALSA every day to play gigabytes of audio, and have not noticed the error you describe. perhaps you should be a lot more specific about the s/w you are using and the error you think you are encountering. as for time drifts when using JACK, forget about it. JACK-based software is essentially locked into the hardware. From cladisch at fastmail.net Thu Nov 2 03:44:43 2006 From: cladisch at fastmail.net (Clemens Ladisch) Date: Thu Nov 2 03:44:48 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <200611010830.18458.lem0mel@gmail.com> References: <200611010830.18458.lem0mel@gmail.com> Message-ID: <1162457083.4071.274815913@webmail.messagingengine.com> lemmel wrote: > The sound was always troncated (even with finished software such as xmms, > amarok), Were there samples missing at the beginning or at the end? > and even randomly truncated, What do you mean with "randomly"? What sound card/kernel version/ALSA version are you using? Regards, Clemens From fbar at footils.org Thu Nov 2 07:37:09 2006 From: fbar at footils.org (Frank Barknecht) Date: Thu Nov 2 07:38:06 2006 Subject: [linux-audio-dev] Re: [PD] [PD-announce] Pd Q and Faust interfaces / ICMC 2006 demo In-Reply-To: <4549ACE2.4090308@t-online.de> References: <4549ACE2.4090308@t-online.de> Message-ID: <20061102123709.GD8122@fliwatut.scifi> Hallo, Albert Graef hat gesagt: // Albert Graef wrote: > This should be interesting for all who want to extend their Pd with > programs written in languages other than C/C++. I have created Pd plugin > interfaces for these two languages: Damn, that's amazing. Finally a Faust for Pd and it comes with an added Q for free as well. Or the other way around... ;) Thanks a lot! Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From orlarey at grame.fr Thu Nov 2 09:13:41 2006 From: orlarey at grame.fr (Orlarey Yann) Date: Thu Nov 2 09:13:45 2006 Subject: [linux-audio-dev] [ANN] Faust Online Message-ID: <4549FD15.5070809@grame.fr> Dear All, A completely rewritten Faust website is available at http://faudiostream.sourceforge.net or at http://faust.grame.fr . Its main feature is the possibility to use the Faust compiler online, via the web pages, without having to install it on your machine. The website contains a small catalog of softwares written in Faust. Each software is available to download in various binary formats (Linux/i386) : * standalone applications : alsa-gtk, jack-gtk, oss-gtk, libsndfile command line * plugins : ladspa, puredata, Q, supercollider The SVG block-diagrams of each software are also available ('->svg' link). These block-diagrams were generated by the Faust compiler using the -svg option. You can navigate down the hierarchy of block diagrams by clicking on the blue boxes. A click on the white background allows to move up. Another link, the '->code' link, allows to view and edit the Faust code of the application. It is useful to learn how a specific application is written in Faust. But the funny part is to modify the Faust code to your needs. You can then recompile it and look at the generated C++ code or at the corresponding SVG block-diagrams. Once your Faust program successfully compile, you can choose the appropriate architecture and download a 'source' tar.gz file that contains the C++ code and a Makefile, or directly a binary file for Linux/i386. Please note that for puredata, the binary file is a tar.gz archive that packs together the plugin and a user interface patch, thanks to Albert Graef 'faust2pd' patch generator. For supercollider it is also a tar.gz archive that packs together the plugin and a class description, thanks to Stefan Kersten 'faust2sc' class generator. Please note also that the website is still experimental and probably not very robust. To navigate the website use the navigation buttons on the left, the back and forward buttons will not work very well. Yann From hannu at opensound.com Thu Nov 2 09:51:19 2006 From: hannu at opensound.com (Hannu Savolainen) Date: Thu Nov 2 12:21:21 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <200611012232.58568.lem0mel@gmail.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> Message-ID: <454A05E7.40005@opensound.com> Hi folks, The "deprecated" OSS issue needs some clarification. It's just the OSS/Free drivers that are still hanging around in the kernel. that are depracated. They are based on 10 years old version of the OSS architecture and lack all the improvements and features added during past years. However the real OSS by 4Front Technoliges is there to stay. While OSS is "binary only" at this moment the situation is changing. We are about to release OSS 4.0 under some open source license. We still need to decide the exact license (GPL, CDDL, BSD or some combination of them) before releasing the sources but that should happen in the near future (maybe weeks or months). The whole "OSS is depracated" issue is just marketing propaganda used to enforce application developers to jump to the ALSA API. Without this developers would stick with OSS which is several magnitudes easier API to use. OSS and ALSA are very different APIs. OSS is designed for professional software developers who should get their job done within tight schedules. For this reason it has strong device abstraction. Everything that could be automated has been automated. ALSA in turn is designed for hackers (in the 1st place) who like to tweak every possible detail of the hardware. This means there is practically no device abstraction and the application should be more or less aware of the capabilities of the hardware. Which API works better depends on the nature of the application. This decision should not be driven by some political issues as today. My message is that if you prefer OSS over ALSA then there is no need to convert the code. OSS has been in the shadows during past couple of years. However it will be back, We are working on an OSS version that makes it possible to ALSA and OSS to co-exist. Both OSS and ALSA will be _native_ code (no emulation). In this way all Linux audio applications will work regardless of which API they use. Best regards, Hannu lemmel wrote: >Le mercredi 01 novembre 2006 16:51, Kjetil S. Matheussen a ?crit : > > >>Only the oss modules in the linux kernel are deprecated. Programs using >>the OSS api will still continue to work, currently most importantly >>because of the oss emulation module in alsa. >> >> >I knew that the oss module was deprecated, and I infered that using the OSS >mecanism was too deprecated :-P. Are sure [1]? > > >>If you should choose between alsa and oss, and the oss version works >>just as well, or better than the alsa version, choose oss, because its a >>more portable API than alsa. >> >> >What do you mean by "the oss version works just as well, or better than the >alsa version" ? > > >>However, if I were you, I would use sndlib, portaudio, jack, or some other >>higher level audio input/output library instead of oss or alsa. >> >> >Well, all the files, that I will play, will have the same charactistics, do I >really need to bother with an hi-level API [2] ? > >[1] I noticed that a lot of applications still use OSS, and I thought it was >because the migration to ALSA was too complex. >[2] Futhermore I am afraid that an hi-level API will produce time drifts in >the playing. > > > From lem0mel at gmail.com Thu Nov 2 12:52:42 2006 From: lem0mel at gmail.com (lemmel) Date: Thu Nov 2 12:53:02 2006 Subject: [linux-audio-dev] Re: alsa, oss , efficiency? In-Reply-To: <1162419648.26663.21.camel@localhost.localdomain> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <1162419648.26663.21.camel@localhost.localdomain> Message-ID: <200611021852.43915.lem0mel@gmail.com> Le mercredi 01 novembre 2006 23:20, Paul Davis a ?crit?: > you really have not provided us with much information on the nature of > the problem you are seeing. Well my question was mainly about what sound system I should use. > dozens, hundreds, perhaps even thousands of > us use ALSA and layers of software built on top of ALSA every day to > play gigabytes of audio, and have not noticed the error you describe. English is not my native tongue, I am sorry if I gived the feeling to critized ALSA. > perhaps you should be a lot more specific about the s/w you are using > and the error you think you are encountering. Well, in order to settle the matter, the wav file is available at http://maleelma.free.fr/lemmel/test.wav.bz2, and this is my software and hardware configuration : - amarok 1.4.1-3 - xmms 1.2.10+20060901-2 - alsa 1.0.12-1 - linux kernel 2.6.17.8 - lspci : ALi Corporation High Definition Audio/AC'97 Host Controller (rev 01) [a 939SLI-eSATA2 motherboard, with Realtek ALC 660 5.1 channel CODEC with HD Audio] - no asoundrc file the wav file contains BIP sound, first on one channel, then the other one. File created with audacity. > as for time drifts when using JACK, forget about it. JACK-based software > is essentially locked into the hardware. Well I work with a Magnetic Resonance Imaging machine (MRI), and the generated sound must be rather accurate : the software is allowed to have a time drifting of 1 milli-seconde in sound generation. I was considerating that small wav files (about 3secondes) pre-loaded, will be a good choice, what do you think ? From lem0mel at gmail.com Thu Nov 2 12:55:19 2006 From: lem0mel at gmail.com (lemmel) Date: Thu Nov 2 12:57:09 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <1162457083.4071.274815913@webmail.messagingengine.com> References: <200611010830.18458.lem0mel@gmail.com> <1162457083.4071.274815913@webmail.messagingengine.com> Message-ID: <200611021855.21225.lem0mel@gmail.com> Le jeudi 02 novembre 2006 09:44, vous avez ?crit?: > Were there samples missing at the beginning or at the end? At the end > > and even randomly truncated, > What do you mean with "randomly"? In order to lighten, I will take an example : a 3 secondes sound file. 0------------------------------>1.5---------------------------------------->3s a beep on a channel a beep on the other channel the sound can be truncated at this time position : 1.5, 2, even at 1. It is rather difficult to be accurate for the real duration is small (the wav file is available at http://maleelma.free.fr/lemmel/test.wav.bz2), and I am focusing on the choice of a sound system. > What sound card/kernel version/ALSA version are you using? see an another post of mine. From pcoccoli at gmail.com Thu Nov 2 13:31:04 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Thu Nov 2 13:31:14 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <4549FD15.5070809@grame.fr> References: <4549FD15.5070809@grame.fr> Message-ID: <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> On 11/2/06, Orlarey Yann wrote: > Dear All, > > A completely rewritten Faust website is available at > http://faudiostream.sourceforge.net or at http://faust.grame.fr . Its > main feature is the possibility to use the Faust compiler online, via > the web pages, without having to install it on your machine. > > The website contains a small catalog of softwares written in Faust. Each > software is available to download in various binary formats (Linux/i386) : > > * standalone applications : alsa-gtk, jack-gtk, oss-gtk, libsndfile > command line > * plugins : ladspa, puredata, Q, supercollider > The alsa-gtk build does not run on my FC4 box, because it requires libpangocairo-1.0.so.0. The whole thing looks very cool though! From lem0mel at gmail.com Thu Nov 2 04:33:28 2006 From: lem0mel at gmail.com (lemmel) Date: Thu Nov 2 13:39:34 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <1162457083.4071.274815913@webmail.messagingengine.com> References: <200611010830.18458.lem0mel@gmail.com> <1162457083.4071.274815913@webmail.messagingengine.com> Message-ID: <200611021033.29332.lem0mel@gmail.com> Le jeudi 02 novembre 2006 09:44, vous avez ?crit?: > Were there samples missing at the beginning or at the end? At the end > > and even randomly truncated, > What do you mean with "randomly"? In order to lighten, I will take an example : a 3 secondes sound file. 0------------------------------>1.5---------------------------------------->3s a beep on a channel a beep on the other channel the sound can be truncated at this time position : 1.5, 2, even at 1. It is rather difficult to be accurate for the real duration is small (see an another post of mine with the wav file enclosed), and I am focusing on the choice of a sound system. > What sound card/kernel version/ALSA version are you using? see an another post of mine. From lem0mel at gmail.com Thu Nov 2 14:44:12 2006 From: lem0mel at gmail.com (lemmel) Date: Thu Nov 2 14:44:19 2006 Subject: [linux-audio-dev] Re: OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <454A05E7.40005@opensound.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> Message-ID: <200611022044.13952.lem0mel@gmail.com> Le jeudi 02 novembre 2006 15:51, vous avez ?crit?: > Hi folks, Hi and thanks for the mail :-) > [...] > However the real OSS by 4Front Technoliges is there to stay. While OSS > is "binary only" at this moment the situation is changing. We are about > to release OSS 4.0 under some open source license. We still need to > decide the exact license (GPL, CDDL, BSD or some combination of them) > before releasing the sources but that should happen in the near future > (maybe weeks or months). I found your website when I looked for information, and it is true :-) that the "OSS deprecated" blurred my valuation. You say that you will make a release with an Opensource licence, but when ? > Without this > developers would stick with OSS which is several magnitudes easier API > to use. Can you justify your point ? > OSS and ALSA are very different APIs. OSS is designed for professional > software developers who should get their job done within tight > schedules. For this reason it has strong device abstraction. Everything > that could be automated has been automated. ALSA in turn is designed for > hackers (in the 1st place) who like to tweak every possible detail of > the hardware. This means there is practically no device abstraction and > the application should be more or less aware of the capabilities of the > hardware. Which API works better depends on the nature of the > application. This decision should not be driven by some political issues > as today. And for my problem, what do you suggest ? (look at an another posted mail ) From jens.andreasen at chello.se Thu Nov 2 14:58:37 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Nov 2 14:58:47 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <200611021033.29332.lem0mel@gmail.com> References: <200611010830.18458.lem0mel@gmail.com> <1162457083.4071.274815913@webmail.messagingengine.com> <200611021033.29332.lem0mel@gmail.com> Message-ID: <1162497517.9224.251.camel@c80-216-124-251.bredband.comhem.se> On Thu, 2006-11-02 at 10:33 +0100, lemmel wrote: Lots of people have been wondering, but this is the meat I think: > > > and even randomly truncated, The difference in behaviour /might/ arise from differences in philosophy of closing the device at end of file. Should we shut up now! Or wait untill the buffer is empty ... The buffer could be incredibly huge, not least because Linux-audio traditionally do not have RT capabilities, so waiting for that has the potential to be very annoying. OTOH, our man is not getting his signal through (which is also annoying ) Fast and dirty solution: Append some silence at the end of your test-signal, enough to lure your application not to close the device while there is still valid signal in the buffer. Real solution: Ehh ... I get lost in ALSA documentation for users (sound programmers that is, not device driver programmers.) Where is the canonical "Hello World" example? -- From jurek at cs.uchicago.edu Thu Nov 2 15:01:58 2006 From: jurek at cs.uchicago.edu (Josef Jurek) Date: Thu Nov 2 15:02:05 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <454A05E7.40005@opensound.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> Message-ID: <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> Hannu Savolainen writes: > [...] > The whole "OSS is depracated" issue is just marketing propaganda used > to enforce application developers to jump to the ALSA API. Without this > developers would stick with OSS which is several magnitudes easier API > to use. "Marketing propaganda?" 4Front Technologies is a company that engages in the sale of software for profit. 4Front Technologies therefore requires and presumably has a "market", people who pay them for their products. I don't think the same situation exists for those who develop ALSA. > OSS and ALSA are very different APIs. OSS is designed for professional > software developers who should get their job done within tight > schedules. For this reason it has strong device abstraction. Everything > that could be automated has been automated. ALSA in turn is designed for > hackers (in the 1st place) who like to tweak every possible detail of > the hardware. This means there is practically no device abstraction and > the application should be more or less aware of the capabilities of the > hardware. Which API works better depends on the nature of the > application. This decision should not be driven by some political issues > as today. So you say: OSS: professional software developers ALSO: hackers How do others feel about this issue. Here is an example from past discussion: From: Paul Davis Date: Tue, 03 Apr 2001 16:15:53 -0400 To: LAD Subject: Re: [linux-audio-dev] efficient non-blocking writes to /dev/dsp Message-Id: <200104032013.QAA29210@renoir.op.net> In message <3ACA1FE4.B8E4EBE8@pp.htv.fi>you write: > >I would like to know what's wrong with OSS API? its impossible to use it in an efficient hardware-independent fashion, because it has no concept of noninterleaved data streams. every time you want to add a new concept to it, such as changing the sample clock sync source, it can only be done via a new ioctl, which is rarely done in a h/w independent fashion but instead as a card-specific hack. the direct use of system calls means that its impossible to do the "grunt" work of, say, resampling or sample bitwidth changes in user space - this is all forced into the kernel. the system call-based API also prevents the interposition of additional layers to provide abstraction: the alsa-oss library, which is coming along very nicely as a way to get *full* ALSA functionality even when using /dev/dsp (rather than just OSS functionality via "emulation"), can only work by using the LD_PRELOAD hack. there's no way to "bind" physical connectors to channels in the OSS model: every OSS-based multichannel driver so far has allowed wierd things like "well, this time when i asked for 10 channels, I got channels 1-10, but the last time, it was 2-12". the kernel code has no interesting "midlevel" layer, forcing many drivers to either offer limited functionality or duplicate code from other drivers. need i go on ? basically, the OSS API is based on h/w models from the SB16 era; ALSA has successfully incorporated lots of lessons from devices like the Hammerfall, the ice1712-based devices and others. --p [...] > My message is that if you prefer OSS over ALSA then there is no need to > convert the code. OSS has been in the shadows during past couple of > years. However it will be back, We are working on an OSS version that > makes it possible to ALSA and OSS to co-exist. Probably, the widespread adoption of ALSA by the linux community gave you no choice but to develop such a version of OSS, no? Oh, and you mis-spelled "4Front Technologies" From dplist at free.fr Thu Nov 2 15:06:18 2006 From: dplist at free.fr (David) Date: Thu Nov 2 15:09:38 2006 Subject: [linux-audio-dev] Re: alsa, oss , efficiency? In-Reply-To: <200611021852.43915.lem0mel@gmail.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <1162419648.26663.21.camel@localhost.localdomain> <200611021852.43915.lem0mel@gmail.com> Message-ID: <20061102210618.f56b3b10.dplist@free.fr> On Thu, 02 Nov 2006 18:52:42 +0100 lemmel wrote: > > perhaps you should be a lot more specific about the s/w you are > > using and the error you think you are encountering. > Well, in order to settle the matter, the wav file is available at > http://maleelma.free.fr/lemmel/test.wav.bz2, > and this is my software and hardware configuration : > - amarok 1.4.1-3 > - xmms 1.2.10+20060901-2 > - alsa 1.0.12-1 > - linux kernel 2.6.17.8 > - lspci : ALi Corporation High Definition Audio/AC'97 Host > Controller (rev > 01) [a 939SLI-eSATA2 motherboard, with Realtek ALC 660 5.1 channel > CODEC with HD Audio] > - no asoundrc file > > the wav file contains BIP sound, first on one channel, then the other > one. File created with audacity. Have you tried playing your file with the simple aplay command ? $ aplay test.wav It works fine here. > > as for time drifts when using JACK, forget about it. JACK-based > > software is essentially locked into the hardware. > Well I work with a Magnetic Resonance Imaging machine (MRI), and the > generated sound must be rather accurate : the software is allowed to > have a time drifting of 1 milli-seconde in sound generation. > I was considerating that small wav files (about 3secondes) > pre-loaded, will be a good choice, what do you think ? If you can do without the on-the-fly generation of the sound clips, it might be easier to have them preloaded, yes. HTH -- David From paul at linuxaudiosystems.com Thu Nov 2 15:09:56 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Nov 2 15:13:18 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <1162497517.9224.251.camel@c80-216-124-251.bredband.comhem.se> References: <200611010830.18458.lem0mel@gmail.com> <1162457083.4071.274815913@webmail.messagingengine.com> <200611021033.29332.lem0mel@gmail.com> <1162497517.9224.251.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <1162498196.26663.102.camel@localhost.localdomain> On Thu, 2006-11-02 at 20:58 +0100, Jens M Andreasen wrote: > On Thu, 2006-11-02 at 10:33 +0100, lemmel wrote: > > Lots of people have been wondering, but this is the meat I think: > > > > > and even randomly truncated, > > The difference in behaviour /might/ arise from differences in philosophy > of closing the device at end of file. Should we shut up now! Or wait > untill the buffer is empty ... The buffer could be incredibly huge, not > least because Linux-audio traditionally do not have RT capabilities, so > waiting for that has the potential to be very annoying. OTOH, our man is > not getting his signal through (which is also annoying ) very good point, the relevant call here is "snd_pcm_drain()". ALSA allows you to close the device immediately (i.e. when you call snd_pcm_close()), or when all data sent to the device has been played. OSS doesn't provide an automatic way to select these behaviours, and I recall from memory that you always get the second one. which of these behaviours is correct is a very app-dependent issue. From orlarey at grame.fr Thu Nov 2 15:52:32 2006 From: orlarey at grame.fr (Orlarey Yann) Date: Thu Nov 2 15:52:44 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> Message-ID: <454A5A90.9000207@grame.fr> Paul Coccoli a ?crit : > The alsa-gtk build does not run on my FC4 box, because it requires > libpangocairo-1.0.so.0. alsa-gtk applications are build against gtk+-2.0 which requires pangocairo-1.0. Have you gtk+-2.0 installed ? > > The whole thing looks very cool though! > Thanks. From James at superbug.co.uk Thu Nov 2 15:56:54 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Nov 2 15:57:08 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <200611021855.21225.lem0mel@gmail.com> References: <200611010830.18458.lem0mel@gmail.com> <1162457083.4071.274815913@webmail.messagingengine.com> <200611021855.21225.lem0mel@gmail.com> Message-ID: <454A5B96.4070502@superbug.co.uk> lemmel wrote: > Le jeudi 02 novembre 2006 09:44, vous avez ?crit : >> Were there samples missing at the beginning or at the end? > At the end >>> and even randomly truncated, >> What do you mean with "randomly"? > In order to lighten, I will take an example : a 3 secondes sound file. > 0------------------------------>1.5---------------------------------------->3s > a beep on a channel a beep on the other channel > > the sound can be truncated at this time position : 1.5, 2, even at 1. > > It is rather difficult to be accurate for the real duration is small (the wav > file is available at http://maleelma.free.fr/lemmel/test.wav.bz2), and I am > focusing on the > choice of a sound system. >> What sound card/kernel version/ALSA version are you using? > see an another post of mine. > We, unless this is actually reported to the alsa bug tracker at http://alsa-project.org/ it might not get fixed or even investigated further. From James at superbug.co.uk Thu Nov 2 16:04:14 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Thu Nov 2 16:04:25 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <454A5B96.4070502@superbug.co.uk> References: <200611010830.18458.lem0mel@gmail.com> <1162457083.4071.274815913@webmail.messagingengine.com> <200611021855.21225.lem0mel@gmail.com> <454A5B96.4070502@superbug.co.uk> Message-ID: <454A5D4E.1010605@superbug.co.uk> James Courtier-Dutton wrote: > lemmel wrote: >> Le jeudi 02 novembre 2006 09:44, vous avez ?crit : >>> Were there samples missing at the beginning or at the end? >> At the end >>>> and even randomly truncated, >>> What do you mean with "randomly"? >> In order to lighten, I will take an example : a 3 secondes sound file. >> 0------------------------------>1.5---------------------------------------->3s >> >> a beep on a channel a beep on the other channel >> >> the sound can be truncated at this time position : 1.5, 2, even at 1. >> >> It is rather difficult to be accurate for the real duration is small >> (the wav file is available at >> http://maleelma.free.fr/lemmel/test.wav.bz2), and I am focusing on the >> choice of a sound system. >>> What sound card/kernel version/ALSA version are you using? >> see an another post of mine. >> > > We, unless this is actually reported to the alsa bug tracker at > http://alsa-project.org/ it might not get fixed or even investigated > further. > > > This is probably an application problem. There is a special case that if the application does not write a full period to the sound card before calling snd_pcm_drain(), the last samples(incomplete period) written might not be played. The recommended way to use the sound card drivers is to use a callback method. The callback will ask for a period at a time, so it is made clear to the application writer that they HAVE to send an entire period. This might help you. James James From pcoccoli at gmail.com Thu Nov 2 16:07:42 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Thu Nov 2 16:07:52 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <454A5A90.9000207@grame.fr> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> <454A5A90.9000207@grame.fr> Message-ID: <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> On 11/2/06, Orlarey Yann wrote: > Paul Coccoli a ?crit : > > The alsa-gtk build does not run on my FC4 box, because it requires > > libpangocairo-1.0.so.0. > alsa-gtk applications are build against gtk+-2.0 which requires > pangocairo-1.0. Have you gtk+-2.0 installed ? Yes, I have gtk+-2.0 installed, but the Fedora Core 4 version of Pango doesn't (yet) have cairo support. So libpangocairo isn't there, but other libpangos are. I'll check my FC5 box later (I don't have FC6 yet). On what system are the apps built? I didn't know anybody was really using Cairo yet. > > > > The whole thing looks very cool though! > > > Thanks. > From lem0mel at gmail.com Thu Nov 2 16:26:04 2006 From: lem0mel at gmail.com (lemmel) Date: Thu Nov 2 16:26:42 2006 Subject: [linux-audio-dev] Re: alsa, oss , efficiency? In-Reply-To: <20061102210618.f56b3b10.dplist@free.fr> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611021852.43915.lem0mel@gmail.com> <20061102210618.f56b3b10.dplist@free.fr> Message-ID: <200611022226.05392.lem0mel@gmail.com> Le jeudi 02 novembre 2006 21:06, David a ?crit?: > Have you tried playing your file with the simple aplay command ? > > $ aplay test.wav > > It works fine here. It is the same for me, it works fine with aplay, but not with xmms and amarok ??!!! > If you can do without the on-the-fly generation of the sound clips, it > might be easier to have them preloaded, yes. What is "generation of the sound clips" ? From Dr.Graef at t-online.de Thu Nov 2 03:31:30 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu Nov 2 16:31:39 2006 Subject: [linux-audio-dev] Pd Q and Faust interfaces / ICMC 2006 demo Message-ID: <4549ACE2.4090308@t-online.de> Hi all, (Sorry for crossposting.) This should be interesting for all who want to extend their Pd with programs written in languages other than C/C++. I have created Pd plugin interfaces for these two languages: - Q, a functional programming language based on term rewriting (my own creation; see http://q-lang.sf.net). Q is a modern-style functional programming language in which functions are defined by equations. It also has an extensive collection of modules for doing graphics and multimedia. My Pd/Q external allows you to execute Q functions in order to do complicated control stuff in Pd, and it also provides a way to access Q's multimedia interfaces inside Pd. This is available as a source tarball (pd-qext-0.1.tar.gz); RPMs for Linux systems are also available. - Faust, Yann Orlarey's functional DSP programming language (http://faudiostream.sf.net). Faust's programming model combines two approaches: functional programming and block diagram composition. You can think of Faust as a structured block diagram language with a textual syntax. The resulting C++ code is heavily optimized and can compete in speed with handwritten C code. My Faust architecture file allows Faust programs to be translated to Pd externals using the Faust compiler. This makes it very easy to create new audio externals for Pd, and a bunch of examples are readily available. I have also written a Q script which generates complete Pd patches with graph-on-parent GUIs from Faust programs. This stuff can be found in the faust2pd-1.0.tar.gz package. You can find all the good stuff, including documentation and a lot of examples on the Q website at: http://q-lang.sourceforge.net/examples.html#Multimedia (see the bottom of this page). The Faust interface will also soon be available as a part of the mainstream Faust distribution. Yann and me will show Faust, Q and their Pd and SuperCollider interfaces at the International Computer Music Conference (ICMC) next week in New Orleans, so if you have an opportunity to come we hope to meet you there. (The presentation is on the very last day of the conference, Sat Nov 11th, 3:30 p.m., see http://www.icmc2006.org.) For more information please see http://faudiostream.sf.net and http://q-lang.sf.net. Enjoy. :) 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 lem0mel at gmail.com Thu Nov 2 16:50:55 2006 From: lem0mel at gmail.com (lemmel) Date: Thu Nov 2 16:51:02 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? In-Reply-To: <454A5D4E.1010605@superbug.co.uk> References: <200611010830.18458.lem0mel@gmail.com> <454A5B96.4070502@superbug.co.uk> <454A5D4E.1010605@superbug.co.uk> Message-ID: <200611022250.56859.lem0mel@gmail.com> Le jeudi 02 novembre 2006 22:04, vous avez ?crit?: > This is probably an application problem. There is a special case that if > the application does not write a full period to the sound card before > calling snd_pcm_drain(), the last samples(incomplete period) written > might not be played. I share your point of view for I tested with aplay (see another post), and all works fine :-) > The recommended way to use the sound card drivers is to use a callback > method. The callback will ask for a period at a time, so it is made > clear to the application writer that they HAVE to send an entire period. Can you be more precise about the function? (I a noob with sound and alsa, but I know well dhat is a callbcak function :-) ) From Dr.Graef at t-online.de Thu Nov 2 17:19:31 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu Nov 2 17:20:30 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> Message-ID: <454A6EF3.6070705@t-online.de> Paul Coccoli wrote: > The alsa-gtk build does not run on my FC4 box, because it requires > libpangocairo-1.0.so.0. Get the source package instead of the binary one and compile from there yourself (a Makefile is included IIRC). That should do the trick. Or try the Pd target, those binaries should work with a recent Pd version on almost any Linux system because they only require Pd. > The whole thing looks very cool though! It is. :) 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 Dr.Graef at t-online.de Thu Nov 2 17:46:32 2006 From: Dr.Graef at t-online.de (Albert Graef) Date: Thu Nov 2 17:47:45 2006 Subject: [linux-audio-dev] Re: [PD] [PD-announce] Pd Q and Faust interfaces / ICMC 2006 demo In-Reply-To: <20061102123709.GD8122@fliwatut.scifi> References: <4549ACE2.4090308@t-online.de> <20061102123709.GD8122@fliwatut.scifi> Message-ID: <454A7548.7060408@t-online.de> Frank Barknecht wrote: > Damn, that's amazing. Finally a Faust for Pd and it comes with an > added Q for free as well. Or the other way around... ;) Hi Frank, I thought you might be interested in this. ;-) Please note that the Q and Faust interfaces are in two different packages. If you can live with just the naked Faust plugins you don't actually need Q at all, just Faust to compile the DSP sources. But then you don't get the generated gop patches which make the Faust plugins much easier to use, IMHO. :) 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 k.s.matheussen at notam02.no Thu Nov 2 18:06:37 2006 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Thu Nov 2 18:07:02 2006 Subject: [linux-audio-dev] Re: Re: alsa, oss , efficiency? In-Reply-To: <20061102175714.B29B13D1BA2F@music.columbia.edu> References: <20061102175714.B29B13D1BA2F@music.columbia.edu> Message-ID: lemmel: > > Le mercredi 01 novembre 2006 16:51, Kjetil S. Matheussen a ?crit?: >> Only the oss modules in the linux kernel are deprecated. Programs using >> the OSS api will still continue to work, currently most importantly >> because of the oss emulation module in alsa. > I knew that the oss module was deprecated, and I infered that using the OSS > mecanism was too deprecated :-P. Are sure [1]? Hmm, well, who decides... I think its pretty safe to write code for OSS and be sure it will work for a long time. Maybe longer than code written for ALSA as well, who knows. >> If you should choose between alsa and oss, and the oss version works >> just as well, or better than the alsa version, choose oss, because its a >> more portable API than alsa. > What do you mean by "the oss version works just as well, or better than the > alsa version" ? Thats a liberal quote... But sorry, I don't think I can write what I ment any clearer... (well, you can remove the comma after "well", but thats as clear as I can make it, english is not my native language either. :-) ) >> However, if I were you, I would use sndlib, portaudio, jack, or some other >> higher level audio input/output library instead of oss or alsa. > Well, all the files, that I will play, will have the same charactistics, do I > really need to bother with an hi-level API [2] ? Why not? > > [1] I noticed that a lot of applications still use OSS, and I thought it was > because the migration to ALSA was too complex. That might be one reason. But if it works well with OSS, thats often good enough. Its a shame it sometimes is hard to make OSS programs work with jack though, but thats a problem that goes for alsa programs as well. (Actually, its worse with alsa programs.) > [2] Futhermore I am afraid that an hi-level API will produce time drifts in > the playing. > No, I don't think so. Many people use portaudio, it could be your best choise. From dplist at free.fr Thu Nov 2 19:08:57 2006 From: dplist at free.fr (David) Date: Thu Nov 2 19:09:20 2006 Subject: [linux-audio-dev] Re: alsa, oss , efficiency? In-Reply-To: <200611022226.05392.lem0mel@gmail.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611021852.43915.lem0mel@gmail.com> <20061102210618.f56b3b10.dplist@free.fr> <200611022226.05392.lem0mel@gmail.com> Message-ID: <20061103010857.cc75087a.dplist@free.fr> On Thu, 02 Nov 2006 22:26:04 +0100 lemmel wrote: > Le jeudi 02 novembre 2006 21:06, David a ?crit?: > > Have you tried playing your file with the simple aplay command ? > > > > $ aplay test.wav > > > > It works fine here. > It is the same for me, it works fine with aplay, but not with xmms > and amarok ??!!! As wise people already told you, different apps with different goals behave differently ... The test with aplay at least shows that your ALSA setup is ok and that the flammable debate about ALSA vs OSS is not the point in your case. If you want help here, you really should try to give a clearer explanation of what you are trying to achieve. You are talking with highly knowledgeable persons on this list, myself belonging to the least knowledgeable ones, I am ordinarily part of the "silent lurkers". What I could gather from this thread goes from "I can't play this wav file" to "I need to link synchronous audio to magnetic resonance imaging" (quotes are mine). Please try to clearly state your case or you won't be answered in any helpful way. > > If you can do without the on-the-fly generation of the sound clips, > > it might be easier to have them preloaded, yes. > What is "generation of the sound clips" ? I was just supposing you could need to generate sound data from realtime events/data. If your need is to "play" predefined sound data when needed, then you're better off with keeping it in memory, as long as its size remains compatible with your hardware. HTH -- David From loki.davison at gmail.com Thu Nov 2 21:42:25 2006 From: loki.davison at gmail.com (Loki Davison) Date: Thu Nov 2 21:42:43 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> Message-ID: On 11/3/06, Josef Jurek wrote: > > Hannu Savolainen writes: > > > [...] > > > The whole "OSS is depracated" issue is just marketing propaganda used > > to enforce application developers to jump to the ALSA API. Without this > > developers would stick with OSS which is several magnitudes easier API > > to use. > > "Marketing propaganda?" 4Front Technologies is a company that > engages in the sale of software for profit. 4Front Technologies therefore > requires and presumably has a "market", people who pay them for their > products. I don't think the same situation exists for those > who develop ALSA. > > > > OSS and ALSA are very different APIs. OSS is designed for professional > > software developers who should get their job done within tight > > schedules. For this reason it has strong device abstraction. Everything > > that could be automated has been automated. ALSA in turn is designed for > > hackers (in the 1st place) who like to tweak every possible detail of > > the hardware. This means there is practically no device abstraction and > > the application should be more or less aware of the capabilities of the > > hardware. Which API works better depends on the nature of the > > application. This decision should not be driven by some political issues > > as today. > > So you say: > > OSS: professional software developers > ALSA: hackers > mmm. I think they are missing the point about ALSA vs OSS api here. It doesn't matter. The only one who should care about alsa vs oss is the jack guys who write the jack backend. Everyone else uses the clear, nice, well implemented, well documented modern and sensible jack api instead of some very 80's style pipe based system. Have you tried OSS for midi? ARRG horrible flashbacks. Any app using oss for midi is automatically classed as useless by me. Good bye timing, good by flexibility hello dodgyness! Portability wise how is OSS better than jack? Jack runs on posix systems (mac, linux, etc) and there seems to be action on the windoze front. OSS for portability is silly, everyone gets screwed over in the features department for really no uses to get anything out of it. How do you record the output of an OSS app nicely? Route it to timemachine... i don't think so. Look at the example jack apps. So easy! Loki From jens.andreasen at chello.se Fri Nov 3 02:29:50 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Nov 3 02:30:01 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> Message-ID: <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> On Fri, 2006-11-03 at 13:42 +1100, Loki Davison wrote: > mmm. I think they are missing the point about ALSA vs OSS api here. It > doesn't matter. The only one who should care about alsa vs oss is the > jack guys who write the jack backend. Everyone else uses the clear, > nice, well implemented, well documented modern and sensible jack api > instead of some very 80's style pipe based system. JACK isn't based on "some very 80' style" named pipes anymore? When did that happen? From loki.davison at gmail.com Fri Nov 3 02:37:13 2006 From: loki.davison at gmail.com (Loki Davison) Date: Fri Nov 3 02:37:23 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> Message-ID: On 11/3/06, Jens M Andreasen wrote: > On Fri, 2006-11-03 at 13:42 +1100, Loki Davison wrote: > > > mmm. I think they are missing the point about ALSA vs OSS api here. It > > doesn't matter. The only one who should care about alsa vs oss is the > > jack guys who write the jack backend. Everyone else uses the clear, > > nice, well implemented, well documented modern and sensible jack api > > instead of some very 80's style pipe based system. > > JACK isn't based on "some very 80' style" named pipes anymore? When did > that happen? > > > I actually meant vs a callback based system. Jack being callback based makes it easier to understand in my mind. I didn't mention named pipes, just the | <> signs. Even without the pipe section i think the comment still stands. As a person new to all 3 i found jack by far the easiest to understand and use. Loki From fons.adriaensen at skynet.be Fri Nov 3 02:53:30 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Fri Nov 3 02:51:17 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <20061103075330.GB5953@linux-1.site> On Fri, Nov 03, 2006 at 06:37:13PM +1100, Loki Davison wrote: > On 11/3/06, Jens M Andreasen wrote: > >On Fri, 2006-11-03 at 13:42 +1100, Loki Davison wrote: > > > >> mmm. I think they are missing the point about ALSA vs OSS api here. It > >> doesn't matter. The only one who should care about alsa vs oss is the > >> jack guys who write the jack backend. Everyone else uses the clear, > >> nice, well implemented, well documented modern and sensible jack api > >> instead of some very 80's style pipe based system. > > > >JACK isn't based on "some very 80' style" named pipes anymore? When did > >that happen? > > I actually meant vs a callback based system. Jack being callback based > makes it easier to understand in my mind. I didn't mention named > pipes, just the | <> signs. Even without the pipe section i think the > comment still stands. As a person new to all 3 i found jack by far the > easiest to understand and use. I'd say that the essential feature of JACK is not that it is a callback based system, but that it presents and expects audio data in fixed size blocks and enforces the rule that all clients must have processed a block before the next arrives. This could be done with blocking as well as with a callback, and indeed it would be useful if JACK offered that option. -- FA Lascia la spina, cogli la rosa. From orlarey at grame.fr Fri Nov 3 07:02:28 2006 From: orlarey at grame.fr (Orlarey Yann) Date: Fri Nov 3 07:02:44 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> <454A5A90.9000207@grame.fr> <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> Message-ID: <454B2FD4.5030002@grame.fr> Paul Coccoli a ?crit : > On 11/2/06, Orlarey Yann wrote: >> Paul Coccoli a ?crit : >> > The alsa-gtk build does not run on my FC4 box, because it requires >> > libpangocairo-1.0.so.0. >> alsa-gtk applications are build against gtk+-2.0 which requires >> pangocairo-1.0. Have you gtk+-2.0 installed ? > > Yes, I have gtk+-2.0 installed, but the Fedora Core 4 version of Pango > doesn't (yet) have cairo support. So libpangocairo isn't there, but > other libpangos are. > > I'll check my FC5 box later (I don't have FC6 yet). > > On what system are the apps built? I didn't know anybody was really > using Cairo yet. Well, on my SUSE 10.1 'pkg-config --libs gtk+-2.0' returns : -L/usr/X11R6/lib -L/opt/gnome/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lfreetype -lfontconfig -lXrender -lX11 -lXext -lpng12 -lz -lglitz -lm requiring explicitly pangocairo-1.0 But on the Faust server (an old Mandrake 10.1) 'pkg-config --libs gtk+-2.0' returns : -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 It doesn't require pangocairo explicitly. Moreover ldd doesn't show any dependency to libpangocairo in the generated binary on the server. 'ldd freeverb | grep libpango' returns libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x40479000) libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x4047e000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x4048b000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x40949000) It seems to be a problem of configuration of gtk+-2.0 on FC4. Could you try, as suggested by Albert in a previous mail, to download a source package and recompile it on your FC4 machine to see if you still have the problem ? What does 'pkg-config --libs gtk+-2.0' return on your machine ? Yann From pcoccoli at gmail.com Fri Nov 3 09:29:29 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Fri Nov 3 09:29:42 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <454B2FD4.5030002@grame.fr> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> <454A5A90.9000207@grame.fr> <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> <454B2FD4.5030002@grame.fr> Message-ID: <8d27a0610611030629q4266b70fp3af18cd81f06930f@mail.gmail.com> On 11/3/06, Orlarey Yann wrote: > Paul Coccoli a ?crit : > > On 11/2/06, Orlarey Yann wrote: > >> Paul Coccoli a ?crit : > >> > The alsa-gtk build does not run on my FC4 box, because it requires > >> > libpangocairo-1.0.so.0. > >> alsa-gtk applications are build against gtk+-2.0 which requires > >> pangocairo-1.0. Have you gtk+-2.0 installed ? > > > > Yes, I have gtk+-2.0 installed, but the Fedora Core 4 version of Pango > > doesn't (yet) have cairo support. So libpangocairo isn't there, but > > other libpangos are. > > > > I'll check my FC5 box later (I don't have FC6 yet). > > > > On what system are the apps built? I didn't know anybody was really > > using Cairo yet. > Well, on my SUSE 10.1 'pkg-config --libs gtk+-2.0' returns : > -L/usr/X11R6/lib -L/opt/gnome/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 > -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 > -lgmodule-2.0 -ldl -lglib-2.0 -lfreetype -lfontconfig -lXrender -lX11 > -lXext -lpng12 -lz -lglitz -lm > > requiring explicitly pangocairo-1.0 > > But on the Faust server (an old Mandrake 10.1) 'pkg-config --libs > gtk+-2.0' returns : > -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 > -lgdk_pixbuf-2.0 > -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 > -ldl -lglib-2.0 > > It doesn't require pangocairo explicitly. Moreover ldd doesn't show any > dependency to libpangocairo in the generated binary on the server. 'ldd > freeverb | grep libpango' returns > libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x40479000) > libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x4047e000) > libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x4048b000) > libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x40949000) > > It seems to be a problem of configuration of gtk+-2.0 on FC4. Could you > try, as suggested by Albert in a previous mail, to download a source > package and recompile it on your FC4 machine to see if you still have > the problem ? What does 'pkg-config --libs gtk+-2.0' return on your > machine ? > > Yann > The "volume" and "tester" apps I downloaded have different ldd output: [pcoccoli@tuttle ~]$ ldd volume linux-gate.so.1 => (0x0075a000) libasound.so.2 => /lib/libasound.so.2 (0x04c4e000) libpthread.so.0 => /lib/libpthread.so.0 (0x00a99000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x0467a000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00c49000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x04c28000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00be3000) libpangocairo-1.0.so.0 => not found libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x0631c000) libcairo.so.2 => not found libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x04e95000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x009f8000) libdl.so.2 => /lib/libdl.so.2 (0x008cf000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x0025b000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00ad4000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00b3e000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x00bd9000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x008ea000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00a4a000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x055a2000) libz.so.1 => /usr/lib/libz.so.1 (0x008d5000) libglitz.so.1 => not found libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x05468000) libm.so.6 => /lib/libm.so.6 (0x008a8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00525000) libc.so.6 => /lib/libc.so.6 (0x0077d000) /lib/ld-linux.so.2 (0x0075b000) libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x009f0000) libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x00a38000) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x00c43000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x00bcf000) libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x00a33000) libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x00ba2000) libXfixes.so.3 => /usr/X11R6/lib/libXfixes.so.3 (0x00c16000) libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x00c0a000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00ab3000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x063bc000) Here's pkg-config on my FC4: [pcoccoli@tuttle ~]$ pkg-config --libs gtk+-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 Unless you statically link the generated apps, I don't think you can really expect them to run everywhere. From pw_lists at slinkp.com Fri Nov 3 10:02:39 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Fri Nov 3 10:02:58 2006 Subject: [linux-audio-dev] Re: Re: alsa, oss , efficiency? In-Reply-To: References: <20061102175714.B29B13D1BA2F@music.columbia.edu> Message-ID: <20061103150239.GA8060@slinkp.com> regarding portability... portaudio? -- Paul Winkler http://www.slinkp.com From sjenkins at blueyonder.co.uk Fri Nov 3 11:39:18 2006 From: sjenkins at blueyonder.co.uk (Simon Jenkins) Date: Fri Nov 3 11:39:34 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <20061103075330.GB5953@linux-1.site> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> <20061103075330.GB5953@linux-1.site> Message-ID: <1162571958.4551.36.camel@sgen-laptop> On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote: > [...] > I'd say that the essential feature of JACK is not that it is a > callback based system, but that it presents and expects audio > data in fixed size blocks and enforces the rule that all clients > must have processed a block before the next arrives. > > This could be done with blocking as well as with a callback, > and indeed it would be useful if JACK offered that option. Fons, I remember your mail to jackit-devel on this subject: http://sourceforge.net/mailarchive/message.php?msg_id=14073424 I had a question at the time which I didn't get around to asking which is... What about event processing? (ie GraphReordered, BufferSizeChange etc) These are delivered to the same thread in libjack that waits on the buffers so they would be turning up somewhere inside your proposed jack_thread_wait() function. Two possible approaches would be: a) Stick with callbacks for events b) Poll for events In either case when you called jack_thread_wait() it would wait for events and/or a buffer. The difference is that in a) it would call a callback whenever it got an event but only return to caller when it got a buffer, whereas in b) it would return to caller on either an event or a buffer with an indication of which had arrived. a) would be easiest and I can't see any advantage in b). What do you think? Simon From letz at grame.fr Fri Nov 3 11:50:02 2006 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Fri Nov 3 11:52:59 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <1162571958.4551.36.camel@sgen-laptop> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> <20061103075330.GB5953@linux-1.site> <1162571958.4551.36.camel@sgen-laptop> Message-ID: Le 3 nov. 06 ? 17:39, Simon Jenkins a ?crit : > On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote: >> [...] >> I'd say that the essential feature of JACK is not that it is a >> callback based system, but that it presents and expects audio >> data in fixed size blocks and enforces the rule that all clients >> must have processed a block before the next arrives. >> >> This could be done with blocking as well as with a callback, >> and indeed it would be useful if JACK offered that option. > > Fons, I remember your mail to jackit-devel on this subject: > > http://sourceforge.net/mailarchive/message.php?msg_id=14073424 > > I had a question at the time which I didn't get around to asking which > is... What about event processing? (ie GraphReordered, > BufferSizeChange > etc) These are delivered to the same thread in libjack that waits > on the > buffers so they would be turning up somewhere inside your proposed > jack_thread_wait() function. > > Two possible approaches would be: > > a) Stick with callbacks for events > b) Poll for events > > In either case when you called jack_thread_wait() it would wait for > events and/or a buffer. The difference is that in a) it would call a > callback whenever it got an event but only return to caller when it > got > a buffer, whereas in b) it would return to caller on either an > event or > a buffer with an indication of which had arrived. > > a) would be easiest and I can't see any advantage in b). What do you > think? > > Simon > > > c) or move to a 2 threads model: one for RT audio, one for notification event handling Stephane From fons.adriaensen at skynet.be Fri Nov 3 12:10:57 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Fri Nov 3 12:08:34 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <1162571958.4551.36.camel@sgen-laptop> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> <20061103075330.GB5953@linux-1.site> <1162571958.4551.36.camel@sgen-laptop> Message-ID: <20061103171057.GE5953@linux-1.site> On Fri, Nov 03, 2006 at 04:39:18PM +0000, Simon Jenkins wrote: > On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote: > > [...] > > I'd say that the essential feature of JACK is not that it is a > > callback based system, but that it presents and expects audio > > data in fixed size blocks and enforces the rule that all clients > > must have processed a block before the next arrives. > > > > This could be done with blocking as well as with a callback, > > and indeed it would be useful if JACK offered that option. > > Fons, I remember your mail to jackit-devel on this subject: > > http://sourceforge.net/mailarchive/message.php?msg_id=14073424 > > I had a question at the time which I didn't get around to asking which > is... What about event processing? (ie GraphReordered, BufferSizeChange > etc) These are delivered to the same thread in libjack that waits on the > buffers so they would be turning up somewhere inside your proposed > jack_thread_wait() function. There is no problem with this. They are handled in libjack which will call one of the user's callbacks. This happens in the code block named 'A' in my proposal, just as it does now. The fact that we are inside jack_thread_wait() doesn't matter at all - the callback is a function call like any other. The two forms are really equivalent ! The event could arrive at an inconvenient time for the client, but that is also the case in the normal structure. The worst that could happen is that an algorithm has to be terminated while it is still threaded. If that's the case you have to code for it. -- FA Lascia la spina, cogli la rosa. From sjenkins at blueyonder.co.uk Fri Nov 3 12:16:40 2006 From: sjenkins at blueyonder.co.uk (Simon Jenkins) Date: Fri Nov 3 12:16:51 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> <20061103075330.GB5953@linux-1.site> <1162571958.4551.36.camel@sgen-laptop> Message-ID: <1162574200.7937.8.camel@sgen-laptop> On Fri, 2006-11-03 at 17:50 +0100, St?phane Letz wrote: > Le 3 nov. 06 ? 17:39, Simon Jenkins a ?crit : > > > On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote: > >> [...] > >> I'd say that the essential feature of JACK is not that it is a > >> callback based system, but that it presents and expects audio > >> data in fixed size blocks and enforces the rule that all clients > >> must have processed a block before the next arrives. > >> > >> This could be done with blocking as well as with a callback, > >> and indeed it would be useful if JACK offered that option. > > > > Fons, I remember your mail to jackit-devel on this subject: > > > > http://sourceforge.net/mailarchive/message.php?msg_id=14073424 > > > > I had a question at the time which I didn't get around to asking which > > is... What about event processing? (ie GraphReordered, > > BufferSizeChange > > etc) These are delivered to the same thread in libjack that waits > > on the > > buffers so they would be turning up somewhere inside your proposed > > jack_thread_wait() function. > > > > Two possible approaches would be: > > > > a) Stick with callbacks for events > > b) Poll for events > > > > In either case when you called jack_thread_wait() it would wait for > > events and/or a buffer. The difference is that in a) it would call a > > callback whenever it got an event but only return to caller when it > > got > > a buffer, whereas in b) it would return to caller on either an > > event or > > a buffer with an indication of which had arrived. > > > > a) would be easiest and I can't see any advantage in b). What do you > > think? > > > > Simon > > > > c) or move to a 2 threads model: one for RT audio, one for > notification event handling Possible, but a lot more effort in current JACK and no good reason (that I can see at the moment) to do it that way. How about jackdmp? Which of a) b) or c) would be easier or better there? Simon > Stephane From letz at grame.fr Fri Nov 3 12:19:09 2006 From: letz at grame.fr (=?ISO-8859-1?Q?St=E9phane_Letz?=) Date: Fri Nov 3 12:22:00 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <1162574200.7937.8.camel@sgen-laptop> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> <20061103075330.GB5953@linux-1.site> <1162571958.4551.36.camel@sgen-laptop> <1162574200.7937.8.camel@sgen-laptop> Message-ID: Le 3 nov. 06 ? 18:16, Simon Jenkins a ?crit : > On Fri, 2006-11-03 at 17:50 +0100, St?phane Letz wrote: >> Le 3 nov. 06 ? 17:39, Simon Jenkins a ?crit : >> >>> On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote: >>>> [...] >>>> I'd say that the essential feature of JACK is not that it is a >>>> callback based system, but that it presents and expects audio >>>> data in fixed size blocks and enforces the rule that all clients >>>> must have processed a block before the next arrives. >>>> >>>> This could be done with blocking as well as with a callback, >>>> and indeed it would be useful if JACK offered that option. >>> >>> Fons, I remember your mail to jackit-devel on this subject: >>> >>> http://sourceforge.net/mailarchive/message.php?msg_id=14073424 >>> >>> I had a question at the time which I didn't get around to asking >>> which >>> is... What about event processing? (ie GraphReordered, >>> BufferSizeChange >>> etc) These are delivered to the same thread in libjack that waits >>> on the >>> buffers so they would be turning up somewhere inside your proposed >>> jack_thread_wait() function. >>> >>> Two possible approaches would be: >>> >>> a) Stick with callbacks for events >>> b) Poll for events >>> >>> In either case when you called jack_thread_wait() it would wait for >>> events and/or a buffer. The difference is that in a) it would call a >>> callback whenever it got an event but only return to caller when it >>> got >>> a buffer, whereas in b) it would return to caller on either an >>> event or >>> a buffer with an indication of which had arrived. >>> >>> a) would be easiest and I can't see any advantage in b). What do you >>> think? >>> >>> Simon >>> >> >> c) or move to a 2 threads model: one for RT audio, one for >> notification event handling > > Possible, but a lot more effort in current JACK and no good reason > (that > I can see at the moment) to do it that way. > > How about jackdmp? Which of a) b) or c) would be easier or better > there? > > Simon > jackdmp is c) already. Stephane > > > > > >> Stephane > > From orlarey at grame.fr Fri Nov 3 12:49:59 2006 From: orlarey at grame.fr (Orlarey Yann) Date: Fri Nov 3 12:50:18 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <8d27a0610611030629q4266b70fp3af18cd81f06930f@mail.gmail.com> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> <454A5A90.9000207@grame.fr> <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> <454B2FD4.5030002@grame.fr> <8d27a0610611030629q4266b70fp3af18cd81f06930f@mail.gmail.com> Message-ID: <454B8147.8000901@grame.fr> Paul Coccoli a ?crit : > Here's pkg-config on my FC4: > > [pcoccoli@tuttle ~]$ pkg-config --libs gtk+-2.0 > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm > -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 > -ldl -lglib-2.0 > > Unless you statically link the generated apps, I don't think you can > really expect them to run everywhere. > libpangocairo-1.0.so.0 => not found Unfortunately I don't have any explanation (and no FC4 to try to reproduce your problem here). Anyone else with similar problems with gtk binaries ? From jens.andreasen at chello.se Fri Nov 3 12:55:06 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Nov 3 12:55:50 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <1162576506.9224.268.camel@c80-216-124-251.bredband.comhem.se> On Fri, 2006-11-03 at 18:37 +1100, Loki Davison wrote: > I actually meant vs a callback based system. Jack being callback based > makes it easier to understand in my mind. I didn't mention named > pipes, just the | <> signs. Even without the pipe section i think the > comment still stands. As a person new to all 3 i found jack by far the > easiest to understand and use. > You have used shell syntax as a glue between various audio applications? Hats off to you then, I would have thought to be unpossible, that gcc was a minimum requirement ... at least I am not getting anywhere without taking that route, opening an audio device using 'ioctl' ( ... which I copy/pasted from another app, not totally unlike how one would copy 'simple_jack_client' and fill in the blanks) > Loki -- From pcoccoli at gmail.com Fri Nov 3 16:39:59 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Fri Nov 3 16:40:08 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <454B8147.8000901@grame.fr> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> <454A5A90.9000207@grame.fr> <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> <454B2FD4.5030002@grame.fr> <8d27a0610611030629q4266b70fp3af18cd81f06930f@mail.gmail.com> <454B8147.8000901@grame.fr> Message-ID: <8d27a0610611031339m2a43878ex70a6c93297fd117e@mail.gmail.com> On 11/3/06, Orlarey Yann wrote: > Paul Coccoli a ?crit : > > Here's pkg-config on my FC4: > > > > [pcoccoli@tuttle ~]$ pkg-config --libs gtk+-2.0 > > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm > > -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 > > -ldl -lglib-2.0 > > > > Unless you statically link the generated apps, I don't think you can > > really expect them to run everywhere. > > libpangocairo-1.0.so.0 => not found > Unfortunately I don't have any explanation (and no FC4 to try to > reproduce your problem here). Anyone else with similar problems with gtk > binaries ? > Not to drag things out, but the problem isn't really with FC4. Anyone who doesn't have libpangocairo installed will not be able to run those binaries. Period. You said the compiler server isn't linking the binaries against that lib, but I just don't see how that's possible. Run strings on the binaries; you'll see. Anyway, don't spend any time on it on my behalf; I was just curious about how it could produce working binaries. I'd rather install faust and build things myself anyway... From orlarey at grame.fr Fri Nov 3 17:19:15 2006 From: orlarey at grame.fr (Orlarey Yann) Date: Fri Nov 3 17:19:47 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <8d27a0610611031339m2a43878ex70a6c93297fd117e@mail.gmail.com> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> <454A5A90.9000207@grame.fr> <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> <454B2FD4.5030002@grame.fr> <8d27a0610611030629q4266b70fp3af18cd81f06930f@mail.gmail.com> <454B8147.8000901@grame.fr> <8d27a0610611031339m2a43878ex70a6c93297fd117e@mail.gmail.com> Message-ID: <454BC063.6060507@grame.fr> > Not to drag things out, but the problem isn't really with FC4. Anyone > who doesn't have libpangocairo installed will not be able to run those > binaries. Period. You said the compiler server isn't linking the > binaries against that lib, but I just don't see how that's possible. > Run strings on the binaries; you'll see. There is no cairo libraires on that server. But let see, on which binary is the problem : - the precompiled binary (get-it ! button on the catalog) - the one compiled on demand (following the ->code link and going into the online compiler) ? They may behave differently. > Anyway, don't spend any time on it on my behalf; I was just curious > about how it could produce working binaries. > I'd rather install faust and build things myself anyway... That's a solution, but the whole idea is not to have to, at least to try... From loki.davison at gmail.com Fri Nov 3 20:56:42 2006 From: loki.davison at gmail.com (Loki Davison) Date: Fri Nov 3 20:56:51 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <1162576506.9224.268.camel@c80-216-124-251.bredband.comhem.se> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <1162538990.9224.256.camel@c80-216-124-251.bredband.comhem.se> <1162576506.9224.268.camel@c80-216-124-251.bredband.comhem.se> Message-ID: On 11/4/06, Jens M Andreasen wrote: > On Fri, 2006-11-03 at 18:37 +1100, Loki Davison wrote: > > > I actually meant vs a callback based system. Jack being callback based > > makes it easier to understand in my mind. I didn't mention named > > pipes, just the | <> signs. Even without the pipe section i think the > > comment still stands. As a person new to all 3 i found jack by far the > > easiest to understand and use. > > > > You have used shell syntax as a glue between various audio applications? > Hats off to you then, I would have thought to be unpossible, that gcc > was a minimum requirement ... at least I am not getting anywhere without > taking that route, opening an audio device using 'ioctl' ( ... which I > copy/pasted from another app, not totally unlike how one would copy > 'simple_jack_client' and fill in the blanks) > > > Loki > -- > > cat thing.au > /dev/dsp works on some systems. I'm not saying it makes total sense though. Loki From jens.andreasen at chello.se Fri Nov 3 22:43:25 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Fri Nov 3 22:43:34 2006 Subject: [linux-audio-dev] Re: Re: alsa, oss , efficiency? In-Reply-To: <20061103150239.GA8060@slinkp.com> References: <20061102175714.B29B13D1BA2F@music.columbia.edu> <20061103150239.GA8060@slinkp.com> Message-ID: <1162611805.9224.273.camel@c80-216-124-251.bredband.comhem.se> On Fri, 2006-11-03 at 10:02 -0500, Paul Winkler wrote: > > regarding portability... > portaudio? > > You mean, as in overhead next to none? Could be ... -- From drobilla at connect.carleton.ca Fri Nov 3 22:52:04 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Fri Nov 3 22:52:12 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <454A05E7.40005@opensound.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> Message-ID: <1162612324.17127.13.camel@localhost.localdomain> On Thu, 2006-11-02 at 16:51 +0200, Hannu Savolainen wrote: > Hi folks, > > The "deprecated" OSS issue needs some clarification. It's just the > OSS/Free drivers that are still hanging around in the kernel. that are > depracated. They are based on 10 years old version of the OSS > architecture and lack all the improvements and features added during > past years. > > However the real OSS by 4Front Technoliges is there to stay. While OSS > is "binary only" at this moment the situation is changing. We are about > to release OSS 4.0 under some open source license. We still need to > decide the exact license (GPL, CDDL, BSD or some combination of them) > before releasing the sources but that should happen in the near future > (maybe weeks or months). > > The whole "OSS is depracated" issue is just marketing propaganda used > to enforce application developers to jump to the ALSA API. Without this > developers would stick with OSS which is several magnitudes easier API > to use. Yeah, and you're clearly not biased. If 4front wanted to stay relevant in Linux, the time to open up was years and years ago. They open it now because Alsa killed OSS? Gee, no kidding. In related news, Sun opens Solaris and all Linux users immediately drop Linux for Solaris. After all, the real Unix from Sun Microsystems is here to stay! Anyway, apps should not be directly using EITHER Alsa or OSS. -DR- From pcoccoli at gmail.com Fri Nov 3 23:02:07 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Fri Nov 3 23:02:15 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <454BC063.6060507@grame.fr> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> <454A5A90.9000207@grame.fr> <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> <454B2FD4.5030002@grame.fr> <8d27a0610611030629q4266b70fp3af18cd81f06930f@mail.gmail.com> <454B8147.8000901@grame.fr> <8d27a0610611031339m2a43878ex70a6c93297fd117e@mail.gmail.com> <454BC063.6060507@grame.fr> Message-ID: <8d27a0610611032002h2f9864afk979892db149e63c9@mail.gmail.com> On 11/3/06, Orlarey Yann wrote: > > > Not to drag things out, but the problem isn't really with FC4. Anyone > > who doesn't have libpangocairo installed will not be able to run those > > binaries. Period. You said the compiler server isn't linking the > > binaries against that lib, but I just don't see how that's possible. > > Run strings on the binaries; you'll see. > There is no cairo libraires on that server. But let see, on which binary > is the problem : > - the precompiled binary (get-it ! button on the catalog) > - the one compiled on demand (following the ->code link and going into > the online compiler) ? > They may behave differently. > Ah, my mistake. Yes, the pre-compiled binary is linked against libpangocairo and libglitz, etc. The on-demand compiled version is not. It works fine on my FC5 box. Very cool! > > Anyway, don't spend any time on it on my behalf; I was just curious > > about how it could produce working binaries. > > I'd rather install faust and build things myself anyway... > That's a solution, but the whole idea is not to have to, at least to try... > Understood. Any plans for a DSSI architecture? From orlarey at grame.fr Sat Nov 4 09:22:16 2006 From: orlarey at grame.fr (Orlarey Yann) Date: Sat Nov 4 09:23:00 2006 Subject: [linux-audio-dev] [ANN] Faust Online In-Reply-To: <8d27a0610611032002h2f9864afk979892db149e63c9@mail.gmail.com> References: <4549FD15.5070809@grame.fr> <8d27a0610611021031o20cf7b84kb75ee666cdde6db0@mail.gmail.com> <454A5A90.9000207@grame.fr> <8d27a0610611021307n606a1109q35459515b736de88@mail.gmail.com> <454B2FD4.5030002@grame.fr> <8d27a0610611030629q4266b70fp3af18cd81f06930f@mail.gmail.com> <454B8147.8000901@grame.fr> <8d27a0610611031339m2a43878ex70a6c93297fd117e@mail.gmail.com> <454BC063.6060507@grame.fr> <8d27a0610611032002h2f9864afk979892db149e63c9@mail.gmail.com> Message-ID: <454CA218.7050507@grame.fr> > Any plans for a DSSI architecture? The plan is, with the help of the community, to support the largest possible set of architectures. DSSI support is certainly a good candidate , but I don't know how much work it would represent, compared for example to the existing LADSPA architecture. From fons.adriaensen at skynet.be Sat Nov 4 17:08:44 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Sat Nov 4 17:06:20 2006 Subject: [Jackit-devel] [linux-audio-dev] Re: Multiplexing 4 channels on SPDIF In-Reply-To: <1162233053.27037.27.camel@mindpipe> References: <20061029235748.GF6000@linux-1.site> <4545E4A0.1030606@pp.inet.fi> <1162220827.14733.113.camel@mindpipe> <20061030163546.GB9886@bth05w.ABSp.alcatel.be> <1162226496.27037.9.camel@mindpipe> <20061030175233.GA5949@linux-1.site> <1162233053.27037.27.camel@mindpipe> Message-ID: <20061104220844.GE5949@linux-1.site> On Mon, Oct 30, 2006 at 01:30:53PM -0500, Lee Revell wrote: > On Mon, 2006-10-30 at 18:52 +0100, Fons Adriaensen wrote: > > The real question is how to fit this into the existing architecture: > > > > - hardware presents itself as 2 * 96 kHz > > - user wants to see a device with 4 * 48 kHz. > > > Is there any online documentation on how to write ALSA plugins ? > > No, ask on the ALSA list. Joined the alsa-devel list and asked if such a thing would be possible. Five days later: more spam than I've had in a year and no reply. Today I wrote a JACK backend that does the job. -- FA Lascia la spina, cogli la rosa. From lem0mel at gmail.com Sun Nov 5 03:45:41 2006 From: lem0mel at gmail.com (lemmel) Date: Sun Nov 5 03:46:49 2006 Subject: [linux-audio-dev] alsa, oss , efficiency? Message-ID: <200611050945.44085.lem0mel@gmail.com> Thanks for all of your mails, I collected a lot of information :-) Bye ! From dmills_00 at yahoo.co.uk Sun Nov 5 16:44:14 2006 From: dmills_00 at yahoo.co.uk (Dan Mills) Date: Sun Nov 5 16:44:59 2006 Subject: [linux-audio-dev] Anyone else ever run a THD test on Jamin? Message-ID: <1162763055.22415.19.camel@dans-laptop> Hi all, While hacking around with aliasing effects in digital compressors (Yes it is real, yes you can hear it!), I happened to run a 10Khz sine wave into jamin with an instance of Jaaa hooked up to the output. The results were 'interesting' as it appears that jamin introduces easily measurable harmonic distortion even with all compressors and eq bypassed! Switching the master bypass in jamin however does make the effect go away. This was at a level of -26dbFS with no boost and with the limiter bypassed. I say 'harmonic distortion', but it really is not quite that as it appears as a series of narrow spikes every few hundred Hz. Further checks show that the same effect appears with the test tone turned down to 2.5Khz and that eq bypass has no effect. Now with a single tone we are looking at per 'harmonic' energy almost a hundred db down on the test tone, but there are a lot of these spikes and they increase in number as additional inputs are added, so there might be quite a lot of energy here all told. Anyone have any ideas? This thing should be linear under these conditions! Regards, Dan. Send instant messages to your online friends http://uk.messenger.yahoo.com From pw_lists at slinkp.com Sun Nov 5 18:07:33 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Sun Nov 5 18:07:49 2006 Subject: [linux-audio-dev] Anyone else ever run a THD test on Jamin? In-Reply-To: <1162763055.22415.19.camel@dans-laptop> References: <1162763055.22415.19.camel@dans-laptop> Message-ID: <20061105230732.GB7959@slinkp.com> On Sun, Nov 05, 2006 at 09:44:14PM +0000, Dan Mills wrote: > Hi all, > While hacking around with aliasing effects in digital compressors (Yes > it is real, yes you can hear it!), I happened to run a 10Khz sine wave > into jamin with an instance of Jaaa hooked up to the output. > > The results were 'interesting' as it appears that jamin introduces > easily measurable harmonic distortion even with all compressors and eq > bypassed! Switching the master bypass in jamin however does make the > effect go away. I haven't tried anything like that, but I did notice that listening to the low band soloed (no mids, no highs) there was some easily audible distortion that I couldn't get rid of. When turning off the solo switch, it either went away or was masked by the mids and highs. Not sure which version of JAMIN, this was early 2006 and I haven't used it lately. -- Paul Winkler http://www.slinkp.com From dmills_00 at yahoo.co.uk Sun Nov 5 20:42:08 2006 From: dmills_00 at yahoo.co.uk (Dan Mills) Date: Sun Nov 5 20:42:23 2006 Subject: [linux-audio-dev] Anyone else ever run a THD test on Jamin? In-Reply-To: <1162763055.22415.19.camel@dans-laptop> References: <1162763055.22415.19.camel@dans-laptop> Message-ID: <1162777328.29316.3.camel@dans-laptop> AAARRRGGHHH! That was supposed to go to jamin-devel, sorry folks. Apologies to the Jamin gang, a bad case of driving mail client without looking at screen. Sorry about that. Regards, Dan. Send instant messages to your online friends http://uk.messenger.yahoo.com From hannu at opensound.com Mon Nov 6 05:46:37 2006 From: hannu at opensound.com (Hannu Savolainen) Date: Mon Nov 6 05:47:07 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> Message-ID: <454F128D.2090703@opensound.com> Josef Jurek wrote: > > "Marketing propaganda?" 4Front Technologies is a company that > engages in the sale of software for profit. 4Front Technologies therefore > requires and presumably has a "market", people who pay them for their > products. 4Front Technologies is just three programmers/developers. There is no marketing people. > I don't think the same situation exists for those > who develop ALSA. > So you didn't know that key members of the ALSA team have been employees of SuSE. Best regards, Hannu From S.W.Harris at ecs.soton.ac.uk Mon Nov 6 09:14:04 2006 From: S.W.Harris at ecs.soton.ac.uk (Steve Harris) Date: Mon Nov 6 09:14:32 2006 Subject: [linux-audio-dev] Anyone else ever run a THD test on Jamin? In-Reply-To: <20061105230732.GB7959@slinkp.com> References: <1162763055.22415.19.camel@dans-laptop> <20061105230732.GB7959@slinkp.com> Message-ID: <20061106141404.GB32515@login.ecs.soton.ac.uk> On Sun, Nov 05, 2006 at 06:07:33 -0500, Paul Winkler wrote: > On Sun, Nov 05, 2006 at 09:44:14PM +0000, Dan Mills wrote: > > Hi all, > > While hacking around with aliasing effects in digital compressors (Yes > > it is real, yes you can hear it!), I happened to run a 10Khz sine wave > > into jamin with an instance of Jaaa hooked up to the output. > > > > The results were 'interesting' as it appears that jamin introduces > > easily measurable harmonic distortion even with all compressors and eq > > bypassed! Switching the master bypass in jamin however does make the > > effect go away. That probably an effect from the compressors, someone pointed out that there is a distortion on the falling edge of sinewaves, I've not had time to look at it. I did do THD tests on the EQ etc., but not the compressors. > I haven't tried anything like that, but I did notice that listening > to the low band soloed (no mids, no highs) there was some easily > audible distortion that I couldn't get rid of. > When turning off the solo switch, it either went away or was masked by > the mids and highs. > Not sure which version of JAMIN, this was early 2006 and > I haven't used it lately. That's not too surprising, the solos dont really do the right thing, and you will end up with some distortion around the band changoever points. - Steve From ladev at sound-man.co.uk Mon Nov 6 13:07:03 2006 From: ladev at sound-man.co.uk (John Rigg) Date: Mon Nov 6 12:45:44 2006 Subject: [linux-audio-dev] Anyone else ever run a THD test on Jamin? In-Reply-To: <1162763055.22415.19.camel@dans-laptop> References: <1162763055.22415.19.camel@dans-laptop> Message-ID: <20061106180703.GA3058@localhost.localdomain> On Sun, Nov 05, 2006 at 09:44:14PM +0000, Dan Mills wrote: > The results were 'interesting' as it appears that jamin introduces > easily measurable harmonic distortion even with all compressors and eq > bypassed! Switching the master bypass in jamin however does make the > effect go away. > > This was at a level of -26dbFS with no boost and with the limiter > bypassed. Doesn't the boost control add harmonics? Perhaps `zero' on the boost setting isn't actually zero. John From nando at ccrma.Stanford.EDU Mon Nov 6 13:36:51 2006 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon Nov 6 13:37:02 2006 Subject: [linux-audio-dev] OSS will be back In-Reply-To: <454F128D.2090703@opensound.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <20061102200158.8F3C18DD0@classes.cs.uchicago.edu> <454F128D.2090703@opensound.com> Message-ID: <1162838211.32167.29.camel@cmn3.stanford.edu> On Mon, 2006-11-06 at 12:46 +0200, Hannu Savolainen wrote: > Josef Jurek wrote: > > "Marketing propaganda?" 4Front Technologies is a company that > > engages in the sale of software for profit. 4Front Technologies therefore > > requires and presumably has a "market", people who pay them for their > > products. > > 4Front Technologies is just three programmers/developers. There is no > marketing people. Ahem... In my eyes the stuff you posted _is_ marketing. Nothing wrong with that, of course, just don't be surprised if the target audience does not buy into it. > > I don't think the same situation exists for those > > who develop ALSA. > > So you didn't know that key members of the ALSA team have been employees > of SuSE. My feeling is that technical factors favored ALSA over OSS (not to say that the ALSA api is complete or perfect, of course). Obviously you and others disagree about that. Re: SuSE, I don't know if Jaroslav was hired before he started work on ALSA, or after ALSA had been around for a while, I suspect the later. Another important factor other than the (crucial) technical stuff is that ALSA has been completely open from the get go, one of the very reasons I switched a long time ago. -- Fernando From rlrevell at joe-job.com Mon Nov 6 13:39:43 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Mon Nov 6 13:39:42 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <454A05E7.40005@opensound.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> Message-ID: <1162838383.22849.19.camel@mindpipe> On Thu, 2006-11-02 at 16:51 +0200, Hannu Savolainen wrote: > Hi folks, > > The "deprecated" OSS issue needs some clarification. It's just the > OSS/Free drivers that are still hanging around in the kernel. that are > depracated. They are based on 10 years old version of the OSS > architecture and lack all the improvements and features added during > past years. Real linux drivers reside in the mainline kernel. Out of tree stuff is is irrelevant. Also, you've been promising for years that OSS will be free software again, I doubt anyone believes you at this point. Lee From pw_lists at slinkp.com Mon Nov 6 16:38:06 2006 From: pw_lists at slinkp.com (Paul Winkler) Date: Mon Nov 6 16:38:20 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <1162838383.22849.19.camel@mindpipe> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> Message-ID: <20061106213806.GA10230@slinkp.com> On Mon, Nov 06, 2006 at 01:39:43PM -0500, Lee Revell wrote: > Real linux drivers reside in the mainline kernel. Out of tree stuff is > is irrelevant. I don't think that's a fair blanket statement given that drivers often begin life outside the mainline kernel tree. ALSA, for example. -- Paul Winkler http://www.slinkp.com From paul at linuxaudiosystems.com Mon Nov 6 17:11:17 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Mon Nov 6 17:27:31 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <20061106213806.GA10230@slinkp.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> Message-ID: <1162851077.15613.13.camel@localhost.localdomain> On Mon, 2006-11-06 at 16:38 -0500, Paul Winkler wrote: > On Mon, Nov 06, 2006 at 01:39:43PM -0500, Lee Revell wrote: > > Real linux drivers reside in the mainline kernel. Out of tree stuff is > > is irrelevant. > > I don't think that's a fair blanket statement given that drivers often > begin life outside the mainline kernel tree. ALSA, for example. > i also think its not necessary to be so antagonistic towards 4 Front or OSS. Hannu was the guy who made sound on linux possible in the first place. Have a little respect. OK, so he and others decided to try to make a business out of it, and they bowed down to NDA requirements from vendors as part of doing that. Many of us never liked the results of that decision, but its an understandable and, from some points of view, a defensible one too. I continue to have disagreements with the technical decisions that Hannu and others made with OSS' design. Other people I respect (hi Guenter) continue to prefer the OSS design. Either way, lets have a little respect for someone who got the SB cards, the incredible Gravis Ultrasound and many other devices working, who offered help to others trying to write drivers and generally has had a lot of similar goals that many LAD members do. --p From James at superbug.co.uk Mon Nov 6 19:29:42 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Mon Nov 6 19:29:57 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <1162851077.15613.13.camel@localhost.localdomain> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> Message-ID: <454FD376.7030306@superbug.co.uk> Paul Davis wrote: > Hannu was the guy who made sound on linux possible in the first place. > Have a little respect. OK, so he and others decided to try to make a > business out of it, and they bowed down to NDA requirements from vendors > as part of doing that. Many of us never liked the results of that > decision, but its an understandable and, from some points of view, a > defensible one too. > NDAs are not all bad. I signed an NDA with creative, and the result is better support for open source drivers for Audigy and E-MU cards. I choose the GPL license for my code, but I could have chosen any other license I wanted. I am not allowed to copy the datasheets themselves, but I can write anything I like in the source code. I.e. comments etc. So, I don't believe the argument that signing NDAs requires closed source drivers. James P.S. For those interested, there is now an ALSA driver for the E-MU 1212m and E-MU 1820m. From pshirkey at boosthardware.com Mon Nov 6 19:41:31 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Mon Nov 6 19:41:43 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <1162851077.15613.13.camel@localhost.localdomain> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> Message-ID: <454FD63B.2080604@boosthardware.com> Paul Davis wrote: > > I continue to have disagreements with the technical decisions that Hannu > and others made with OSS' design. Other people I respect (hi Guenter) > continue to prefer the OSS design. Either way, lets have a little > respect for someone who got the SB cards, the incredible Gravis > Ultrasound and many other devices working, who offered help to others > trying to write drivers and generally has had a lot of similar goals > that many LAD members do. > I think Hannu annoyed a few of us by stating that ALSA is designed by hackers. There is absolutely no question in my mind that ALSA is designed by professionals. The difference is that 4Front is a company whereas ALSA is a group of individuals, several of whom are employed to work on the drivers or derive income thereof. Many people have commented that 4Front have made their install and configuration system very user friendly. That's definitely something that the ALSA Project could improve but as the product is not being sold it's not a priority and the docs are fairly complete. I like to think of it as an enforced learning curve. Installing the ALSA drivers is not the hardest task that Linux Audio Users are confronted with anymore. -- 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 pieterp at joow.be Tue Nov 7 09:12:51 2006 From: pieterp at joow.be (Pieter Palmers) Date: Tue Nov 7 09:13:08 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <454FD376.7030306@superbug.co.uk> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD376.7030306@superbug.co.uk> Message-ID: <45509463.9030203@joow.be> James Courtier-Dutton wrote: > Paul Davis wrote: > >> Hannu was the guy who made sound on linux possible in the first place. >> Have a little respect. OK, so he and others decided to try to make a >> business out of it, and they bowed down to NDA requirements from vendors >> as part of doing that. Many of us never liked the results of that >> decision, but its an understandable and, from some points of view, a >> defensible one too. > > NDAs are not all bad. I signed an NDA with creative, and the result is > better support for open source drivers for Audigy and E-MU cards. I > choose the GPL license for my code, but I could have chosen any other > license I wanted. > I am not allowed to copy the datasheets themselves, but I can write > anything I like in the source code. I.e. comments etc. > So, I don't believe the argument that signing NDAs requires closed > source drivers. I also signed a NDA to get the documents to work on FreeBoB. I don't see a problem there, as long as the NDA doesn't restrict me with respect to the licensing of FreeBoB. Pieter From shulmang at colorado.edu Tue Nov 7 09:56:52 2006 From: shulmang at colorado.edu (Garett Shulman) Date: Tue Nov 7 09:57:16 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <454FD63B.2080604@boosthardware.com> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> Message-ID: <45509EB4.1080701@colorado.edu> > I think Hannu annoyed a few of us by stating that ALSA is designed by > hackers. > > There is absolutely no question in my mind that ALSA is designed by > professionals. True. However... there are definitely some hackish aspects to the alsa project. On numerous occasions I have found the files created by alsactl for my ice1712's to break from version to version of ALSA. Then I have to check what the mixer settings where, reset them manually, and run alsactl store again. Lame. The plugin infrastructure seems to often be variously broken... except for the sample rate & bit rate plugin... and perhaps dmix. I was able to get dshare working pretty well once... but an alsa upgrade broke that. But... it's gratis & libre & generally works great under Jack. So... Thank you ALSA Team! If you ask me... I would recommend that the alsa team drop all of the ambitions plugin stuff (except sampl rate & bit rate) and focus on building the most stable & broadly supported hardware abstraction for jack. From phanatic at volny.cz Tue Nov 7 10:39:19 2006 From: phanatic at volny.cz (Ctirad Fertr) Date: Tue Nov 7 10:39:48 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <454FD376.7030306@superbug.co.uk> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <1162851077.15613.13.camel@localhost.localdomain> <454FD376.7030306@superbug.co.uk> Message-ID: <200611071539.19426.phanatic@volny.cz> Dne ?ter? 07 listopad 2006 00:29 James Courtier-Dutton napsal(a): > P.S. For those interested, there is now an ALSA driver for the E-MU > 1212m and E-MU 1820m. Excellent news! It is already usable for serious work? Is it compatible with the current 1212M v2 revision? Best regards, Ctirad From ladev at sound-man.co.uk Tue Nov 7 11:54:07 2006 From: ladev at sound-man.co.uk (John Rigg) Date: Tue Nov 7 11:32:23 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <45509EB4.1080701@colorado.edu> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> Message-ID: <20061107165407.GA2608@localhost.localdomain> On Tue, Nov 07, 2006 at 07:56:52AM -0700, Garett Shulman wrote: > If you ask me... I would recommend that the alsa team drop all of the > ambitions plugin stuff (except sampl rate & bit rate) Without `ambitious plugin stuff' like pcm_multi, nobody would be able to use multiple sound cards with ALSA. The fact that pcm_multi has needed patching since January 2005 to make it work in duplex mode with jackd is only a minor inconvenience compared with not having it at all. John From rlrevell at joe-job.com Tue Nov 7 11:42:40 2006 From: rlrevell at joe-job.com (Lee Revell) Date: Tue Nov 7 11:42:33 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <20061107165407.GA2608@localhost.localdomain> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> Message-ID: <1162917761.22849.135.camel@mindpipe> On Tue, 2006-11-07 at 16:54 +0000, John Rigg wrote: > On Tue, Nov 07, 2006 at 07:56:52AM -0700, Garett Shulman wrote: > > If you ask me... I would recommend that the alsa team drop all of the > > ambitions plugin stuff (except sampl rate & bit rate) > > Without `ambitious plugin stuff' like pcm_multi, nobody would be able > to use multiple sound cards with ALSA. The fact that pcm_multi has needed > patching since January 2005 to make it work in duplex mode with jackd > is only a minor inconvenience compared with not having it at all. > Please, please keep pushing the ALSA guys to fix this. I keep raising the issue and every time the thread peters out with no resolution. Lee > John > From James at superbug.co.uk Tue Nov 7 19:20:42 2006 From: James at superbug.co.uk (James Courtier-Dutton) Date: Tue Nov 7 19:20:58 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <1162917761.22849.135.camel@mindpipe> References: <20061101133616.CAE8F3CB0FDA@music.columbia.edu> <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> <1162917761.22849.135.camel@mindpipe> Message-ID: <455122DA.1000908@superbug.co.uk> Lee Revell wrote: > On Tue, 2006-11-07 at 16:54 +0000, John Rigg wrote: > >> On Tue, Nov 07, 2006 at 07:56:52AM -0700, Garett Shulman wrote: >> >>> If you ask me... I would recommend that the alsa team drop all of the >>> ambitions plugin stuff (except sampl rate & bit rate) >>> >> Without `ambitious plugin stuff' like pcm_multi, nobody would be able >> to use multiple sound cards with ALSA. The fact that pcm_multi has needed >> patching since January 2005 to make it work in duplex mode with jackd >> is only a minor inconvenience compared with not having it at all. >> >> > > Please, please keep pushing the ALSA guys to fix this. I keep raising > the issue and every time the thread peters out with no resolution. > > Lee > I don't know the details, but it is probably due to jackd not using the poll api in the way alsa recommends. The current jackd skips a step in the processing of the poll events. James From k.s.matheussen at notam02.no Wed Nov 8 03:27:29 2006 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Wed Nov 8 03:28:12 2006 Subject: [linux-audio-dev] [ANN] Snd-ls V0.9.7.12 and jack_capture V0.3.9 Message-ID: Snd-ls v0.9.7.7 =============== Snd-ls is a distribution of Bill Schottstaedt's sound editor SND. Its target is people that don't know scheme very well, and don't want to spend too much time configuring Snd. It can also serve as a quick introduction to Snd and how it can be set up. Changes 0.9.7.7 -> 0.9.7.12: ---------------------------- -Fixed listener. -Removed various debug printing. -added --without-builtin-gtkrc configuration option. -Downgraded Snd from 8.4/26.9 back to 8.4/12.9 again. That upgrade was a mindless mistake. -Copied all files from my private snd three into snd-ls. Hopefully, this should make everything work again. -Added fix to make jackdmp work with standard installation of guile. -Don't quit snd-ls in case file can't be opened during startup. Bug reported by Dragan Noveski. -Disable FAM for now, because it fails for no reason during startup. Problem reported by Dragan Noveski. Download from http://www.notam02.no/arkiv/src/snd/ jack_capture v0.3.9 =================== 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. Changes 0.3.8 -> 0.3.9: ----------------------- *Changed the -rt option name to -d, to be compatible with jackrec. *Do not stop recording in case of disk errors. *Replaced deprecated libsndfile functions. *Added the --format/-f option. ("jack_capture -f flac", nice :-) ) (adding "-f w64" solves the 4GB limitation of wav files) From fons.adriaensen at skynet.be Wed Nov 8 08:09:23 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 8 08:06:55 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <455122DA.1000908@superbug.co.uk> References: <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> <1162917761.22849.135.camel@mindpipe> <455122DA.1000908@superbug.co.uk> Message-ID: <20061108130923.GB6006@linux-1.site> On Wed, Nov 08, 2006 at 12:20:42AM +0000, James Courtier-Dutton wrote: > The current jackd skips a step in the processing of the poll events. Looking at the code it seems already quite elaborate. Basically what happens comes down to (ignoring error checking and timeouts): - The set of pollfd is poll()'ed until all are ready. - Within each iteration of the loop the pollfd used are re-initialised by a call to the alsa library. - There is one optimisation: the pollfd are divided into two groups, one for capture and one for playback. A group that is complete is not polled again. I use similar code in libclalsadrv and in a new jackd backend that I wrote last week. What is misssing ? -- FA Lascia la spina, cogli la rosa. From cladisch at fastmail.net Wed Nov 8 08:12:09 2006 From: cladisch at fastmail.net (Clemens Ladisch) Date: Wed Nov 8 08:12:15 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <20061108130923.GB6006@linux-1.site> References: <200611012232.58568.lem0mel@gmail.com> <454A05E7.40005@opensound.com> <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> <1162917761.22849.135.camel@mindpipe> <455122DA.1000908@superbug.co.uk> <20061108130923.GB6006@linux-1.site> Message-ID: <1162991529.30819.275307089@webmail.messagingengine.com> Fons Adriaensen wrote: > On Wed, Nov 08, 2006 at 12:20:42AM +0000, James Courtier-Dutton wrote: > > The current jackd skips a step in the processing of the poll events. > > Basically what happens comes down to (ignoring error > checking and timeouts): > > - The set of pollfd is poll()'ed until all are ready. Applications must not look at ALSA's pollfds, they must use snd_pcm_poll_descriptors_revents() instead. Regards, Clemens From fons.adriaensen at skynet.be Wed Nov 8 08:24:30 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 8 08:22:11 2006 Subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?) In-Reply-To: <1162991529.30819.275307089@webmail.messagingengine.com> References: <1162838383.22849.19.camel@mindpipe> <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> <1162917761.22849.135.camel@mindpipe> <455122DA.1000908@superbug.co.uk> <20061108130923.GB6006@linux-1.site> <1162991529.30819.275307089@webmail.messagingengine.com> Message-ID: <20061108132430.GC6006@linux-1.site> On Wed, Nov 08, 2006 at 02:12:09PM +0100, Clemens Ladisch wrote: > Fons Adriaensen wrote: > > Basically what happens comes down to (ignoring error > > checking and timeouts): > > > > - The set of pollfd is poll()'ed until all are ready. > > Applications must not look at ALSA's pollfds, they must use > snd_pcm_poll_descriptors_revents() instead. Given that poll() is a system call and that the struct used by it is a system type and not one of ALSA's private ones, what is wrong with looking at it ? Is snd_pcm_poll_descriptors_revents() more than an accessor ? If it is, the name is a quite misleading. -- FA Lascia la spina, cogli la rosa. From fons.adriaensen at skynet.be Wed Nov 8 09:42:05 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 8 09:39:59 2006 Subject: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question In-Reply-To: <20061108132430.GC6006@linux-1.site> References: <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> <1162917761.22849.135.camel@mindpipe> <455122DA.1000908@superbug.co.uk> <20061108130923.GB6006@linux-1.site> <1162991529.30819.275307089@webmail.messagingengine.com> <20061108132430.GC6006@linux-1.site> Message-ID: <20061108144205.GD6006@linux-1.site> On Wed, Nov 08, 2006 at 02:24:30PM +0100, Fons Adriaensen wrote: > Is snd_pcm_poll_descriptors_revents() more than an > accessor ? If it is, the name is a quite misleading. To answer my own question, it seems that it *is* more than an accessor. The docs leave one thing unclear. Does this call require an array of unsigned short int (one per pollfd), or are events from all pollfds combined into one revents value ? The example code in test.pcm seems to indicate the latter. In that case, how can one test if *all* pollfd for a given pcm are ready ? -- FA Lascia la spina, cogli la rosa. From cladisch at fastmail.net Wed Nov 8 11:58:40 2006 From: cladisch at fastmail.net (Clemens Ladisch) Date: Wed Nov 8 11:59:30 2006 Subject: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question In-Reply-To: <20061108144205.GD6006@linux-1.site> References: <20061106213806.GA10230@slinkp.com> <1162851077.15613.13.camel@localhost.localdomain> <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> <1162917761.22849.135.camel@mindpipe> <455122DA.1000908@superbug.co.uk> <20061108130923.GB6006@linux-1.site> <1162991529.30819.275307089@webmail.messagingengine.com> <20061108132430.GC6006@linux-1.site> <20061108144205.GD6006@linux-1.site> Message-ID: <1163005120.24421.275327352@webmail.messagingengine.com> Fons Adriaensen wrote: > On Wed, Nov 08, 2006 at 02:24:30PM +0100, Fons Adriaensen wrote: > > Is snd_pcm_poll_descriptors_revents() more than an > > accessor ? If it is, the name is a quite misleading. > > To answer my own question, it seems that it *is* more > than an accessor. > > The docs leave one thing unclear. Does this call require > an array of unsigned short int (one per pollfd), or are > events from all pollfds combined into one revents value? It returns one revents value for the PCM device. > In that case, how can one test if *all* pollfd for a given > pcm are ready ? You cannot. The state of the file descriptors is not necessarily related to the state of the PCM device (which is why this function exists). Regards, Clemens From fons.adriaensen at skynet.be Wed Nov 8 13:47:51 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 8 13:45:23 2006 Subject: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question In-Reply-To: <1163005120.24421.275327352@webmail.messagingengine.com> References: <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> <1162917761.22849.135.camel@mindpipe> <455122DA.1000908@superbug.co.uk> <20061108130923.GB6006@linux-1.site> <1162991529.30819.275307089@webmail.messagingengine.com> <20061108132430.GC6006@linux-1.site> <20061108144205.GD6006@linux-1.site> <1163005120.24421.275327352@webmail.messagingengine.com> Message-ID: <20061108184751.GF6006@linux-1.site> On Wed, Nov 08, 2006 at 05:58:40PM +0100, Clemens Ladisch wrote: > > In that case, how can one test if *all* pollfd for a given > > pcm are ready ? > > You cannot. The state of the file descriptors is not necessarily > related to the state of the PCM device (which is why this function > exists). OK, thanks. So a loop waiting for both capture and playback being ready could be something like (cut down to the bare minimum): n_play = driver->play_parm.npoll; n_capt = driver->capt_parm.npoll; while (n_play || n_capt) { if (n_play) snd_pcm_poll_descriptors (driver->play_parm.handle, pfd, n_play); if (n_capt) snd_pcm_poll_descriptors (driver->capt_parm.handle, pfd + n_play, n_capt); prv = poll (pfd, n_play + n_capt, 1000); if (prv < 0) { if (errno == EINTR) return ERR1; return ERR2; } if (prv == 0) return ERR3; if (n_play) { snd_pcm_poll_descriptors_revents (driver->play_parm.handle, pfd, n_play, &rev); if (rev & POLLERR) return ERR4; if (rev & POLLOUT) n_play = 0; } if (n_capt) { snd_pcm_poll_descriptors_revents (driver->capt_parm.handle, pfd + n_play, n_capt, &rev); if (rev & POLLERR) return ERR5; if (rev & POLLIN) n_capt = 0; } } return 0; -- FA Lascia la spina, cogli la rosa. From ballet_j at epitech.net Wed Nov 8 16:47:14 2006 From: ballet_j at epitech.net (Elthariel) Date: Wed Nov 8 15:46:45 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a Message-ID: <45525062.9020500@epitech.net> I'm happy to announce the release of kbdz 0.2.0 alpha, a set of tool which allows you to transform classical pc keyboards and mouses plugged via USB into midi keyboards and controller. Support for joysticks is planned for soon. It uses alsa sequencer and the 'new' event devices stack (evdev module). You can find it here: http://sourceforge.net/projects/nahlwe/ Please give me feedback if you test it. Regards, Elthariel. From ce at christeck.de Wed Nov 8 15:59:41 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Nov 8 15:58:55 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <45525062.9020500@epitech.net> References: <45525062.9020500@epitech.net> Message-ID: <200611082159.41644.ce@christeck.de> Hi, > You can find it here: > http://sourceforge.net/projects/nahlwe/ > > Please give me feedback if you test it. build failed on a Gentoo Linux box: evdev_mode_report.c: In function `evdev_events_report': evdev_mode_report.c:37: warning: assignment makes pointer from integer without a cast evdev_mode_report.c: In function `evdev_events_get_type': evdev_mode_report.c:57: error: `EV_SW' undeclared (first use in this function) evdev_mode_report.c:57: error: (Each undeclared identifier is reported only once evdev_mode_report.c:57: error: for each function it appears in.) make[1]: *** [evdev_mode_report.o] Error 1 make[1]: Leaving directory `/home/ce/Desktop/kbdz/kbdz-0.2.0/daemon' make: *** [all-recursive] Error 1 gcc-config -l [1] i686-pc-linux-gnu-3.3.6 [2] i686-pc-linux-gnu-3.3.6-hardened [3] i686-pc-linux-gnu-3.3.6-hardenednopie [4] i686-pc-linux-gnu-3.3.6-hardenednopiessp [5] i686-pc-linux-gnu-3.3.6-hardenednossp [6] i686-pc-linux-gnu-3.4.4 * [7] i686-pc-linux-gnu-3.4.4-hardened [8] i686-pc-linux-gnu-3.4.4-hardenednopie [9] i686-pc-linux-gnu-3.4.4-hardenednopiessp [10] i686-pc-linux-gnu-3.4.4-hardenednossp HTH, ce From goctaf at gmail.com Wed Nov 8 16:12:27 2006 From: goctaf at gmail.com (CTAF ctaf) Date: Wed Nov 8 16:12:37 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <1a9cd1af0611081306p2f0f16e1we21c13cb6e501504@mail.gmail.com> References: <45525062.9020500@epitech.net> <200611082159.41644.ce@christeck.de> <1a9cd1af0611081306p2f0f16e1we21c13cb6e501504@mail.gmail.com> Message-ID: <1a9cd1af0611081312r622116f5w4b2a8b7d69fd5706@mail.gmail.com> I have tried it, it work nice for me. nice jobs. I am waiting for the joystick support, to use it with mixxx :-) From ballet_j at epitech.net Wed Nov 8 17:19:41 2006 From: ballet_j at epitech.net (Elthariel) Date: Wed Nov 8 16:19:52 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <200611082159.41644.ce@christeck.de> References: <45525062.9020500@epitech.net> <200611082159.41644.ce@christeck.de> Message-ID: <455257FD.2040900@epitech.net> Thk you for testing it. You build problem looks quite strange, is there any error message about other EV_XXX identifier missing. EV_SW is a macro defined in linux/input.h can you send me your version of the kernel and your /usr/include/linux/input.h I don't know Gentoo so the place for linux/input.h may vary Regard, Elthariel. Christoph Eckert wrote: > Hi, > > > >> You can find it here: >> http://sourceforge.net/projects/nahlwe/ >> >> Please give me feedback if you test it. >> > > build failed on a Gentoo Linux box: > > evdev_mode_report.c: In function `evdev_events_report': > evdev_mode_report.c:37: warning: assignment makes pointer from integer > without a cast > evdev_mode_report.c: In function `evdev_events_get_type': > evdev_mode_report.c:57: error: `EV_SW' undeclared (first use in this > function) > evdev_mode_report.c:57: error: (Each undeclared identifier is reported > only once > evdev_mode_report.c:57: error: for each function it appears in.) > make[1]: *** [evdev_mode_report.o] Error 1 > make[1]: Leaving directory `/home/ce/Desktop/kbdz/kbdz-0.2.0/daemon' > make: *** [all-recursive] Error 1 > > > gcc-config -l > [1] i686-pc-linux-gnu-3.3.6 > [2] i686-pc-linux-gnu-3.3.6-hardened > [3] i686-pc-linux-gnu-3.3.6-hardenednopie > [4] i686-pc-linux-gnu-3.3.6-hardenednopiessp > [5] i686-pc-linux-gnu-3.3.6-hardenednossp > [6] i686-pc-linux-gnu-3.4.4 * > [7] i686-pc-linux-gnu-3.4.4-hardened > [8] i686-pc-linux-gnu-3.4.4-hardenednopie > [9] i686-pc-linux-gnu-3.4.4-hardenednopiessp > [10] i686-pc-linux-gnu-3.4.4-hardenednossp > > > HTH, > > ce > > > > From paul at linuxaudiosystems.com Wed Nov 8 16:34:25 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Nov 8 16:37:12 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <455257FD.2040900@epitech.net> References: <45525062.9020500@epitech.net> <200611082159.41644.ce@christeck.de> <455257FD.2040900@epitech.net> Message-ID: <1163021665.15613.134.camel@localhost.localdomain> On Wed, 2006-11-08 at 23:19 +0100, Elthariel wrote: > Thk you for testing it. > > You build problem looks quite strange, > is there any error message about other EV_XXX identifier missing. > > EV_SW is a macro defined in linux/input.h > can you send me your version of the kernel and your > /usr/include/linux/input.h > I don't know Gentoo so the place for linux/input.h may vary you should never include linux kernel headers in user-space application software. Linus has repeated this often. From ce at christeck.de Wed Nov 8 16:44:30 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Nov 8 16:43:49 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <455257FD.2040900@epitech.net> References: <45525062.9020500@epitech.net> <200611082159.41644.ce@christeck.de> <455257FD.2040900@epitech.net> Message-ID: <200611082244.30255.ce@christeck.de> Hi, > You build problem looks quite strange, > is there any error message about other EV_XXX identifier missing. The errors I posted have been the only ones. > EV_SW is a macro defined in linux/input.h > can you send me your version of the kernel uname -a Linux Grandevitesse 2.6.14.2-20060917 #3 SMP PREEMPT Sun Sep 17 19:19:21 CEST 2006 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz GenuineIntel GNU/Linux It's not Genkernel, it was a vanilla custom kernel I build from source. Additionally, I compiled the module rt-lsm outside the kernel sources and installed it manually. It is loaded: lsmod | grep realtime realtime 5512 0 commoncap 7296 1 realtime > and your > /usr/include/linux/input.h > I don't know Gentoo so the place for linux/input.h may vary There was one at that place, but attached you'll find the one as found in my kernel sources: /usr/src/linux-2.6.14.2/include/linux/input.h BTW: I only did test the compile for "fun", I currently don't have the time to play with the (though interesting) app. So there's no need to hurry about fixing this issue on my machine. Only if you feel like it. HTH, ce -------------- next part -------------- A non-text attachment was scrubbed... Name: input.h.tar.gz Type: application/x-tgz Size: 7337 bytes Desc: not available Url : http://music.columbia.edu/pipermail/linux-audio-dev/attachments/20061108/2d43faae/input.h.tar-0001.bin From ballet_j at epitech.net Wed Nov 8 17:50:51 2006 From: ballet_j at epitech.net (Elthariel) Date: Wed Nov 8 16:50:24 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <1163021665.15613.134.camel@localhost.localdomain> References: <45525062.9020500@epitech.net> <200611082159.41644.ce@christeck.de> <455257FD.2040900@epitech.net> <1163021665.15613.134.camel@localhost.localdomain> Message-ID: <45525F4B.10409@epitech.net> Paul Davis wrote: > On Wed, 2006-11-08 at 23:19 +0100, Elthariel wrote: > >> Thk you for testing it. >> >> You build problem looks quite strange, >> is there any error message about other EV_XXX identifier missing. >> >> EV_SW is a macro defined in linux/input.h >> can you send me your version of the kernel and your >> /usr/include/linux/input.h >> I don't know Gentoo so the place for linux/input.h may vary >> > > you should never include linux kernel headers in user-space application > software. Linus has repeated this often. > Since this header is copied into /usr/include i was thinking there was no pb about it. How should I get the #define and the definitions necessaty to read 'evdev' devices > > > From ballet_j at epitech.net Wed Nov 8 18:06:00 2006 From: ballet_j at epitech.net (Elthariel) Date: Wed Nov 8 17:06:36 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <200611082244.30255.ce@christeck.de> References: <45525062.9020500@epitech.net> <200611082159.41644.ce@christeck.de> <455257FD.2040900@epitech.net> <200611082244.30255.ce@christeck.de> Message-ID: <455262D8.8000401@epitech.net> Christoph Eckert wrote: > Hi, > > > >> You build problem looks quite strange, >> is there any error message about other EV_XXX identifier missing. >> > > The errors I posted have been the only ones. > > >> EV_SW is a macro defined in linux/input.h >> can you send me your version of the kernel >> > > uname -a > Linux Grandevitesse 2.6.14.2-20060917 #3 SMP PREEMPT Sun Sep 17 19:19:21 > CEST 2006 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz GenuineIntel > GNU/Linux > > It's not Genkernel, it was a vanilla custom kernel I build from source. > Additionally, I compiled the module rt-lsm outside the kernel sources > and installed it manually. It is loaded: > > lsmod | grep realtime > realtime 5512 0 > commoncap 7296 1 realtime > > >> and your >> /usr/include/linux/input.h >> I don't know Gentoo so the place for linux/input.h may vary >> > > There was one at that place, but attached you'll find the one as found > in my kernel sources: > /usr/src/linux-2.6.14.2/include/linux/input.h > > BTW: I only did test the compile for "fun", I currently don't have the > time to play with the (though interesting) app. So there's no need to > hurry about fixing this issue on my machine. Only if you feel like it. > > HTH, > > ce > > This build error is quite strange since your input.h has EV_SW. This define is also still in the 2.6.18 version of the kernel. I'll try to buld it on a gentoo box at a friend. Thank you again for reporting this problem, I'll notice you when i'll have found the solution. Elthariel. From ce at christeck.de Wed Nov 8 17:27:23 2006 From: ce at christeck.de (Christoph Eckert) Date: Wed Nov 8 17:26:43 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <455262D8.8000401@epitech.net> References: <45525062.9020500@epitech.net> <200611082244.30255.ce@christeck.de> <455262D8.8000401@epitech.net> Message-ID: <200611082327.24099.ce@christeck.de> > Thank you again for reporting this problem, I'll notice you when i'll > have found the solution. feel free to do this by PM. There are chances I miss it if posted to the list. Cheers, ce From cladisch at fastmail.net Thu Nov 9 03:30:25 2006 From: cladisch at fastmail.net (Clemens Ladisch) Date: Thu Nov 9 03:30:45 2006 Subject: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question In-Reply-To: <20061108184751.GF6006@linux-1.site> References: <454FD63B.2080604@boosthardware.com> <45509EB4.1080701@colorado.edu> <20061107165407.GA2608@localhost.localdomain> <1162917761.22849.135.camel@mindpipe> <455122DA.1000908@superbug.co.uk> <20061108130923.GB6006@linux-1.site> <1162991529.30819.275307089@webmail.messagingengine.com> <20061108132430.GC6006@linux-1.site> <20061108144205.GD6006@linux-1.site> <1163005120.24421.275327352@webmail.messagingengine.com> <20061108184751.GF6006@linux-1.site> Message-ID: <1163061025.14505.275387538@webmail.messagingengine.com> Fons Adriaensen wrote: > On Wed, Nov 08, 2006 at 05:58:40PM +0100, Clemens Ladisch wrote: > > > In that case, how can one test if *all* pollfd for a given > > > pcm are ready ? > > > > You cannot. The state of the file descriptors is not necessarily > > related to the state of the PCM device (which is why this function > > exists). > > So a loop waiting for both capture and playback being ready > could be something like (cut down to the bare minimum): > [...] Yes. The various snd_pcm_poll* functions just make the descriptors look like a single poll descriptor. The logic should always be the same as if it were using a single fd. Regards, Clemens From dominique.michel at citycable.ch Thu Nov 9 04:15:17 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Thu Nov 9 04:16:30 2006 Subject: [linux-audio-dev] [ANN] kbdz 0.2.0a In-Reply-To: <455262D8.8000401@epitech.net> References: <45525062.9020500@epitech.net> <200611082159.41644.ce@christeck.de> <455257FD.2040900@epitech.net> <200611082244.30255.ce@christeck.de> <455262D8.8000401@epitech.net> Message-ID: <20061109101517.49c1de72@localhost> Le Thu, 09 Nov 2006 00:06:00 +0100, Elthariel a ?crit : > Christoph Eckert wrote: > > Hi, > > > > > > > >> You build problem looks quite strange, > >> is there any error message about other EV_XXX identifier missing. > >> > > > > The errors I posted have been the only ones. > > > > > >> EV_SW is a macro defined in linux/input.h > >> can you send me your version of the kernel > >> > > > > uname -a > > Linux Grandevitesse 2.6.14.2-20060917 #3 SMP PREEMPT Sun Sep 17 19:19:21 > > CEST 2006 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz GenuineIntel > > GNU/Linux > > > > It's not Genkernel, it was a vanilla custom kernel I build from source. > > Additionally, I compiled the module rt-lsm outside the kernel sources > > and installed it manually. It is loaded: > > > > lsmod | grep realtime > > realtime 5512 0 > > commoncap 7296 1 realtime > > > > > >> and your > >> /usr/include/linux/input.h > >> I don't know Gentoo so the place for linux/input.h may vary > >> > > > > There was one at that place, but attached you'll find the one as found > > in my kernel sources: > > /usr/src/linux-2.6.14.2/include/linux/input.h > > > > BTW: I only did test the compile for "fun", I currently don't have the > > time to play with the (though interesting) app. So there's no need to > > hurry about fixing this issue on my machine. Only if you feel like it. > > > > HTH, > > > > ce > > > > > This build error is quite strange since your input.h has EV_SW. This > define is also still in the 2.6.18 version of the kernel. > I'll try to buld it on a gentoo box at a friend. > > Thank you again for reporting this problem, I'll notice you when i'll > have found the solution. > > Elthariel. It build just fine here on gentoo 2006.1, gcc-4.1.1 and kernel 2.6.16-rt29 from the proaudio overlay: http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page I don't have the time to run and test it just now but will do it later. Cheers -- Dominique Michel -- N.B.: Tous les emails que je re?ois sont filtr?s par spamassassin avant de me parvenir. Si vous attendez une r?ponse de ma part et que vous ne la recevez pas, cela signifie qu'en toute vraisemblance, votre courrier ne m'est pas parvenu car vous figurez sur une des listes de http://www.spamhaus.org. From mikko.helin at luukku.com Thu Nov 9 05:28:33 2006 From: mikko.helin at luukku.com (mikko.helin@luukku.com) Date: Thu Nov 9 05:28:41 2006 Subject: [linux-audio-dev]Multiplexing 4 channels on SPDIF Message-ID: <1163068113345.mikko.helin.1948132.xN4UIw2l7GX1i4rgg8nsAA@luukku.com> Just wondering how the framing is specified in that protocol, does it use some lsb's just like the VST System Link protocol does? It would be also nice if you documented the protocol and made it PD so the support could be added also to ASIO4ALL drivers etc. (http://www.asio4all.com/). Btw. In theory you could support 8 x 24-bit (less the framing bit) / 48kHz audio transfer over the SPDIF if you used the 192 kHz sampling rate! Not bad, where do we need the ADAT protocol actually? - Mikko ................................................................... Luukku Plus paketilla p??set eroon tila- ja turvallisuusongelmista. Hanki Luukku Plus ja helpotat el?m??si. http://www.mtv3.fi/luukku From nettings at folkwang-hochschule.de Fri Nov 10 07:40:25 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Fri Nov 10 07:41:11 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... Message-ID: <45547339.5000102@folkwang-hochschule.de> hi everyone! over the last couple of months, i have not been able to tend to the lists very much - moderation latency on laa was sometimes as high as 5 days while i was on tour... sorry for that. since my workload is not likely to go down in the future, and since i have unfortunately lost some touch with the linux audio community (i haven't actually read the lists very much lately, as my main occupations were live audio and [YUCK!] web development), i'd like to pass on the baton of the list maintainer. a few months ago, some people have already volunteered - please drop me a mail again, i may have lost the old ones. if you think about taking on the job: we have 3 lists, linux-audio-[dev|user|announce], all run by mailman on a darwin server at columbia university, new york. you can have shell access on that box for admin tasks, and there is a neat web interface for common admin jobs. basic understanding of mail-related rfcs is certainly helpful, but i'm not exactly a mail god myself and found the job not too daunting :) some good spam filter will certainly help with the job - the admin addresses are getting spammed so heavily that i can't really process them anymore. please speak up if you're interested. best regards, j?rn -- j?rn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D From dlphillips at woh.rr.com Fri Nov 10 09:21:24 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Fri Nov 10 09:17:18 2006 Subject: [linux-audio-dev] M$/SuSE/ALSA ? Message-ID: <45548AE4.2080208@woh.rr.com> Greetings: As many of you already know, SuSE has entered into an interesting 5-year plan with Microsoft. You can find the details on Slashdot and elsewheres, so I won't rehash them here. What isn't mentioned is the ALSA/SuSE connection. I'm pretty sure some of the ALSA developers read these lists, and I'd like to hear from them regarding the significance of their employer's new connections and ALSA's IP and its continued development. Is this marriage happy news for Linux sound or is it an unholy alliance signifying doom and destruction for the world at large (and not just the Linux audio community ;) ? Or will things just cruise along in business-as-usual mode ? Any and all insight vastly appreciated. Best, dp From dlphillips at woh.rr.com Fri Nov 10 09:24:20 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Fri Nov 10 09:20:26 2006 Subject: [linux-audio-dev] M$/SuSE/ALSA ? In-Reply-To: <45548AE4.2080208@woh.rr.com> References: <45548AE4.2080208@woh.rr.com> Message-ID: <45548B94.4050201@woh.rr.com> My apologies, I should have written "Novell/SuSE". From rncbc at rncbc.org Fri Nov 10 11:11:41 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Fri Nov 10 11:08:40 2006 Subject: [linux-audio-dev] M$/SuSE/ALSA ? In-Reply-To: <45548AE4.2080208@woh.rr.com> References: <45548AE4.2080208@woh.rr.com> Message-ID: <4554A4BD.4090007@rncbc.org> Dave Phillips wrote: > Greetings: > > As many of you already know, SuSE has entered into an interesting 5-year > plan with Microsoft. You can find the details on Slashdot and > elsewheres, so I won't rehash them here. > > What isn't mentioned is the ALSA/SuSE connection. I'm pretty sure some > of the ALSA developers read these lists, and I'd like to hear from them > regarding the significance of their employer's new connections and > ALSA's IP and its continued development. Is this marriage happy news for > Linux sound or is it an unholy alliance signifying doom and destruction > for the world at large (and not just the Linux audio community ;) ? > > Or will things just cruise along in business-as-usual mode ? > > Any and all insight vastly appreciated. > Let's put this whole thing as a mental graph. SUSE has brought us ALSA and KDE support. Novell bought SUSE. MS accepts a (bilateral?) deal from Novell to make (old on new) Novell's customers happier, at least on the midterm (5 years). OTOH there's insiders among us that can speak for themselves. Now comes my personal thought: I will still do prefer openSUSE as my Linux distro of choice, and will do pass the message. But, ...be warned. At the slightest hint that ALSA and KDE is getting behind the community idea, I will step ahead (i.e flee :) But again, mind you, I have no problem in doing it all in the LFS way :D Cheers. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From mobarre at gmail.com Fri Nov 10 12:40:30 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Fri Nov 10 12:40:52 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <45547339.5000102@folkwang-hochschule.de> References: <45547339.5000102@folkwang-hochschule.de> Message-ID: <3c808a150611100940i65d4c0bfk76cf5f8e2712aecf@mail.gmail.com> On 11/10/06, Joern Nettingsmeier wrote: > hi everyone! > > > over the last couple of months, i have not been able to tend to the > lists very much - moderation latency on laa was sometimes as high as 5 > days while i was on tour... sorry for that. > > since my workload is not likely to go down in the future, and since i > have unfortunately lost some touch with the linux audio community (i > haven't actually read the lists very much lately, as my main occupations > were live audio and [YUCK!] web development), i'd like to pass on the > baton of the list maintainer. > > a few months ago, some people have already volunteered - please drop me > a mail again, i may have lost the old ones. > if you think about taking on the job: we have 3 lists, > linux-audio-[dev|user|announce], all run by mailman on a darwin server > at columbia university, new york. you can have shell access on that box > for admin tasks, and there is a neat web interface for common admin > jobs. basic understanding of mail-related rfcs is certainly helpful, but > i'm not exactly a mail god myself and found the job not too daunting :) > > some good spam filter will certainly help with the job - the admin > addresses are getting spammed so heavily that i can't really process > them anymore. > > please speak up if you're interested. > > > best regards, > > > j?rn > Hi, I could give a hand there. I am system engineer for Nokia in France. I'm used to working on distant UNIX servers. I have good experience with mail servers, big clustered system and other things like that. And more importantly, I could handle a spam filter if needed ;-) If being outside the US is not an issue, drop me an email, I'll be glad to help. __________________ Marc-Olivier Barre, (Markinoko) Kinoko en Orbite. From rncbc at rncbc.org Fri Nov 10 14:40:13 2006 From: rncbc at rncbc.org (Rui Nuno Capela) Date: Fri Nov 10 14:36:53 2006 Subject: [linux-audio-dev] Re: [linux-audio-user] Re: M$/SuSE/ALSA ? In-Reply-To: <200611101252.17159.lau@kudla.org> References: <45548AE4.2080208@woh.rr.com> <4554A4BD.4090007@rncbc.org> <200611101252.17159.lau@kudla.org> Message-ID: <4554D59D.2090404@rncbc.org> Rob wrote: > On Friday 10 November 2006 11:11, Rui Nuno Capela wrote: >> and will do pass the message. But, ...be warned. At the >> slightest hint that ALSA and KDE is getting behind the >> community idea, I will step ahead (i.e flee :) > > While SuSE may have contributed to KDE, Novell actually owns > Ximian, which for all intents and purposes created GNOME. I've > always been wary of the movement to incorporate Mono into GNOME, > and now I'm much, much more so. > you should have read between the lines that I'm not very found of gnome and all that. my reasoning is simple: miguel started it just because someone told KDE was evil because Qt wasn't pure GPL at the time; then a whole wasteful effort begun to make gnome as the official gnu/fsf desktop; then come ximian; then miguel found that not.net was some kind of bethelem star. go figure why people didn't stuck with (imho) higher brained C++ and KDE just for the doctrine, go figure. :)) (what a waste of great minds) ... and what we have now? Yes, we do still have JACK and Ardour, ALSA, KDE and Linux as true high-tech, open-source, top-of-the-notch projects in the whole known universe. Go catch it, corporate-BS-savvy-boys :))) > I don't see any particular threat to Linux audio users that isn't > also present for Linux users in general, though. > Nor do I. After all, we the guys/gals are few and numbered, but do it for the fun and love, not for the money. Bah, did I say "love" ? Ah, for you who that don't know me, I was a hardcore windows developer once before. Ah, read "once" with emphasis :) thing of the first-half-nineties, blerk! Bottom line is, and that's not an opinion, the F/OSS (r)evolution is already unstoppable. Evidence comes to that IBM knows it. Ultimately, MS knows it too. And you just got to face it now? If you stay with me, and I believe MS strategy cannot be far behind, the OS business is already a dead-end. People are in charge. If you speak BS-like, you can read: the customer is in charge. And don't reply that was RH who come original with that slogan. I do remember something of the sort from Hammer's "reengineering the corporation". Yes early nineties gone old :) Just for the topic, funny thing is, a copy of gamma's/GOF is still around here somewhere and being a mid-nineties foundation truth must be told,... I'm just an old donkey who doesn't learn new languages anymore :D Cheers. -- rncbc aka Rui Nuno Capela rncbc@rncbc.org From ico at vt.edu Fri Nov 10 15:57:09 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Fri Nov 10 15:57:21 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <3c808a150611100940i65d4c0bfk76cf5f8e2712aecf@mail.gmail.com> Message-ID: <000d01c7050a$ca5cf510$0302a8c0@64BitBadass> Is there any interest in the community to consolidate LA* lists in the linuxaudio.org? We could certainly port the lists over if that is something that may be of interest. Benefits of such a move would be consolidating resources, reinforcing the Linuxaudio.org initiative, and if all else fails, giving the lists a nice suffix :-) Best wishes, Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Marc-Olivier Barre > Sent: Friday, November 10, 2006 12:41 PM > To: The Linux Audio Developers' Mailing List > Cc: linux-audio-user@music.columbia.edu > Subject: Re: [linux-audio-dev] [admin] new linux-audio-* maintainer > wanted... > > On 11/10/06, Joern Nettingsmeier wrote: > > hi everyone! > > > > > > over the last couple of months, i have not been able to tend to the > > lists very much - moderation latency on laa was sometimes as high as 5 > > days while i was on tour... sorry for that. > > > > since my workload is not likely to go down in the future, and since i > > have unfortunately lost some touch with the linux audio community (i > > haven't actually read the lists very much lately, as my main occupations > > were live audio and [YUCK!] web development), i'd like to pass on the > > baton of the list maintainer. > > > > a few months ago, some people have already volunteered - please drop me > > a mail again, i may have lost the old ones. > > if you think about taking on the job: we have 3 lists, > > linux-audio-[dev|user|announce], all run by mailman on a darwin server > > at columbia university, new york. you can have shell access on that box > > for admin tasks, and there is a neat web interface for common admin > > jobs. basic understanding of mail-related rfcs is certainly helpful, but > > i'm not exactly a mail god myself and found the job not too daunting :) > > > > some good spam filter will certainly help with the job - the admin > > addresses are getting spammed so heavily that i can't really process > > them anymore. > > > > please speak up if you're interested. > > > > > > best regards, > > > > > > j?rn > > > > Hi, > > I could give a hand there. I am system engineer for Nokia in France. > I'm used to working on distant UNIX servers. I have good experience > with mail servers, big clustered system and other things like that. > And more importantly, I could handle a spam filter if needed ;-) > > If being outside the US is not an issue, drop me an email, I'll be > glad to help. > __________________ > Marc-Olivier Barre, > (Markinoko) > Kinoko en Orbite. From ballet_j at epitech.net Sat Nov 11 13:05:36 2006 From: ballet_j at epitech.net (Elthariel) Date: Sat Nov 11 12:05:00 2006 Subject: [linux-audio-dev] Just a question/idea Message-ID: <455610F0.6000306@epitech.net> Hello, Here is just a simple question about linux audio. I'm looking for some software which doesn't appear to exists. But it should be quite few projects which have not release any code for the moment. So I'm asking the question :) Is there any windows manager that supports jack and lash, in order to make the ''Desktop'' become a modular studio ? Is it possible at least ? If it is, is there anyone here with the time and knowledges to start a project of this kind ? Regards, Elthariel. From gene.heskett at verizon.net Sat Nov 11 21:41:10 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sat Nov 11 21:41:23 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: References: <4554FA6F.5020604@lakeinfoworks.com> <200611111621.29969.gene.heskett@verizon.net> Message-ID: <200611112141.10164.gene.heskett@verizon.net> On Saturday 11 November 2006 21:00, Tony Nelson wrote: >At 4:21 PM -0500 11/11/06, Gene Heskett wrote: > ... > This thread might be of interest to the linux-audio-dev group, so I've added them to the Cc: >>Yup, and its been a constant src of amazement to this old fart that >> when the midi spec was setup, they used a serial port, thats fine, but >> when they set the data rate at only 31,250 baud, ... >> >>Consistently attrocious timeing, with the horns always 1/16 beat late >>unless the actual output order of each instrument is scrambled in the >>order output. That would make it sound a heck of a lot less >> mechanical. And there isn't a heck of a lot that can be done until we >> put midi on an optical circuit running at several megabytes/sec. >> Something like TOS maybe? > >Firewire. Many products already, plenty of speed, almost robust enough. >1/8 millisecond isoch cycle times; each cycle can contain packets from > many senders; each packet can contain lots of notes. More robust IMO than the din connectors now used for midi interconnects, however the cabling itself can't help but be more fragile when subjected to the rigors of a jam session with bodies walking on them all night. And that has to be a consideration else the first users will get discouraged at the high cable failure rates and revert, particularly if they have a tin ear and can't hear what to many of us would be an extremely obvious improvement. But I like that idea, a lot. Maybe some enterprising LAD people could get together and spec something like a midi interface running over firewire, complete with the repeaters so it can be daisy-chained just like midi can be, and hopefully release it into the PD as a new midi-2 interface standard. And design it such that it never, ever gets into the snails trail of the 31,250 baud interface it uses today. -- Cheers, Gene From jens.andreasen at chello.se Sun Nov 12 06:16:37 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Sun Nov 12 06:18:19 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <200611112141.10164.gene.heskett@verizon.net> References: <4554FA6F.5020604@lakeinfoworks.com> <200611111621.29969.gene.heskett@verizon.net> <200611112141.10164.gene.heskett@verizon.net> Message-ID: <1163330197.9224.285.camel@c80-216-124-251.bredband.comhem.se> On Sat, 2006-11-11 at 21:41 -0500, Gene Heskett wrote: > But I like that idea, a lot. Maybe some enterprising LAD people could get > together and spec something like a midi interface running over firewire, > complete with the repeaters so it can be daisy-chained just like midi can > be, and hopefully release it into the PD as a new midi-2 interface > standard. And design it such that it never, ever gets into the snails > trail of the 31,250 baud interface it uses today. > MIDI over IEEE-1394 (aka firewire) exists and is spec'ed by the MMA midi-consortium as an official standard. Unlike other publications from the MMA, this is a free download: http://www.midi.org/about-midi/rp27v10spec(1394).pdf -- From gene.heskett at verizon.net Sun Nov 12 06:39:15 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Sun Nov 12 06:39:44 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <1163330197.9224.285.camel@c80-216-124-251.bredband.comhem.se> References: <4554FA6F.5020604@lakeinfoworks.com> <200611112141.10164.gene.heskett@verizon.net> <1163330197.9224.285.camel@c80-216-124-251.bredband.comhem.se> Message-ID: <200611120639.16022.gene.heskett@verizon.net> On Sunday 12 November 2006 06:16, Jens M Andreasen wrote: >On Sat, 2006-11-11 at 21:41 -0500, Gene Heskett wrote: >> But I like that idea, a lot. Maybe some enterprising LAD people could >> get together and spec something like a midi interface running over >> firewire, complete with the repeaters so it can be daisy-chained just >> like midi can be, and hopefully release it into the PD as a new midi-2 >> interface standard. And design it such that it never, ever gets into >> the snails trail of the 31,250 baud interface it uses today. > >MIDI over IEEE-1394 (aka firewire) exists and is spec'ed by the MMA >midi-consortium as an official standard. Unlike other publications from >the MMA, this is a free download: > >http://www.midi.org/about-midi/rp27v10spec(1394).pdf Great! I guess I hadn't been paying attention. Thank you very much for the link. -- Cheers, Gene From dominique.michel at citycable.ch Sun Nov 12 09:39:41 2006 From: dominique.michel at citycable.ch (Dominique Michel) Date: Sun Nov 12 09:45:09 2006 Subject: [linux-audio-dev] Just a question/idea In-Reply-To: <455610F0.6000306@epitech.net> References: <455610F0.6000306@epitech.net> Message-ID: <20061112153941.282e9c8b@localhost> Le Sat, 11 Nov 2006 19:05:36 +0100, Elthariel a ?crit : > Hello, > > Here is just a simple question about linux audio. I'm looking for some > software which doesn't appear to exists. But it should be quite few > projects which have not release any code for the moment. So I'm asking > the question :) > Is there any windows manager that supports jack and lash, in order to > make the ''Desktop'' become a modular studio ? > > Is it possible at least ? > If it is, is there anyone here with the time and knowledges to start a > project of this kind ? > > Regards, > Elthariel. The sound server is independant from the wm. Now, is it some wm that have they own sound server as arts in kde. But those sound server use some kind of audio drivers to work: alsa, oss, whatever. For jack support, all you need is a working alsa driver. I prefer myself a wm that doesn't have its own sound server as fvwm or fluxbox. My favorite at that time is fvwm-crystal. Fvwm is an incredibly flexible wm, and it is worth to learn it even if ti can be time consuming at the beginning. Debian and debian based distro have a menu system (package menu) that will incorporate all your applications in the menu of each single wm you have in the system and save you a lot of writing with wm as fvwm or crystal to incorporate the apps in the menu. For lash support, the best way is to use an audio focused distribution. The gentoo proaudio overlay: http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page have a very extensive lash support. Lash have nothing to do with the wm but only with the applications, some support it, some not. In this overlay, all the sound programs that have lash capability will have it after the package installation. Some ebuilds provide patches for some applications in order to get lash with more apps. I am not sure for the other audio distributions. Demudi is quite old now and doesn't have lash support. The next Demudi release must be ready with the next Debian release and must have lash support. But we have to want a few months for that. Or you can try the devel version of Demudi. Studio64 have both a 32 and a 64 bits distributions and is more up-to-date as Demudi, but I don't know the state of lash in this distribution. Other distributions that can maybe have lash support fot the applications at that time are Musix and PlanetCCRMA. (And maybe even the jacklab (opensuse) and/or ubuntu) I would recommend gentoo with the audiopro overlay, or Studio64. Both are very up-to-date and are fast moving, especially gentoo, but Studio64 will be easier to install and you can install Debian's menu system with it (The best menu system I know). Gentoo have the best docs and forum I know, but it can take some time to learn it because of the added complexity and flexibility that compiling all from the sources will give you. An advantage with gentoo and its proaudio overlay is at, if you want a software that is not in the overlay or in portage, you can drop a mail at the proaudio email list, and in most cases, the ebuild for this new program will be added in the overlay within a few days. (or you can even contribute with an ebuild, they are not so hard to write in many cases). -- Dominique Michel -- N.B.: Tous les emails que je re?ois sont filtr?s par spamassassin avant de me parvenir. Si vous attendez une r?ponse de ma part et que vous ne la recevez pas, cela signifie qu'en toute vraisemblance, votre courrier ne m'est pas parvenu car vous figurez sur une des listes de http://www.spamhaus.org. From pshirkey at boosthardware.com Sun Nov 12 10:02:23 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sun Nov 12 10:02:41 2006 Subject: [linux-audio-dev] M$/SuSE/ALSA ? In-Reply-To: <45548B94.4050201@woh.rr.com> References: <45548AE4.2080208@woh.rr.com> <45548B94.4050201@woh.rr.com> Message-ID: <4557377F.20801@boosthardware.com> Dave Phillips wrote: > > My apologies, I should have written "Novell/SuSE". > Well, their stated aim is to make Linux and MS work together so as they are about to start on the Zune marketing drive that could mean we will see some action otherwise there's probably nothing else that isn't already done or being done that M$ will want to add to Linux Audio. Oh, apart from native VST support but I can't really see that being a priority for Redmond. They might pay Stephane Letz some money to port JACK though ;-) -- 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 paul at linuxaudiosystems.com Sun Nov 12 10:07:54 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Sun Nov 12 10:08:18 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] M$/SuSE/ALSA ? In-Reply-To: <4557377F.20801@boosthardware.com> References: <45548AE4.2080208@woh.rr.com> <45548B94.4050201@woh.rr.com> <4557377F.20801@boosthardware.com> Message-ID: <1163344074.2846.122.camel@localhost.localdomain> On Sun, 2006-11-12 at 22:02 +0700, Patrick Shirkey wrote: > They might pay Stephane Letz some money to port JACK though ;-) Stephane has already ported JACK to windows. From pshirkey at boosthardware.com Sun Nov 12 10:47:05 2006 From: pshirkey at boosthardware.com (Patrick Shirkey) Date: Sun Nov 12 10:47:18 2006 Subject: [linux-audio-user] Re: [linux-audio-dev] M$/SuSE/ALSA ? In-Reply-To: <1163344074.2846.122.camel@localhost.localdomain> References: <45548AE4.2080208@woh.rr.com> <45548B94.4050201@woh.rr.com> <4557377F.20801@boosthardware.com> <1163344074.2846.122.camel@localhost.localdomain> Message-ID: <455741F9.6000600@boosthardware.com> Paul Davis wrote: > On Sun, 2006-11-12 at 22:02 +0700, Patrick Shirkey wrote: > >> They might pay Stephane Letz some money to port JACK though ;-) > > Stephane has already ported JACK to windows. > > Bummer huh... I guess that revenue stream has been lost by being pro-active and forward thinking... -- 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 pieterp at joow.be Sun Nov 12 11:28:39 2006 From: pieterp at joow.be (Pieter Palmers) Date: Sun Nov 12 11:28:57 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <200611120639.16022.gene.heskett@verizon.net> References: <4554FA6F.5020604@lakeinfoworks.com> <200611112141.10164.gene.heskett@verizon.net> <1163330197.9224.285.camel@c80-216-124-251.bredband.comhem.se> <200611120639.16022.gene.heskett@verizon.net> Message-ID: <45574BB7.2050209@joow.be> Gene Heskett wrote: >On Sunday 12 November 2006 06:16, Jens M Andreasen wrote: > > >>On Sat, 2006-11-11 at 21:41 -0500, Gene Heskett wrote: >> >> >>>But I like that idea, a lot. Maybe some enterprising LAD people could >>>get together and spec something like a midi interface running over >>>firewire, complete with the repeaters so it can be daisy-chained just >>>like midi can be, and hopefully release it into the PD as a new midi-2 >>>interface standard. And design it such that it never, ever gets into >>>the snails trail of the 31,250 baud interface it uses today. >>> >>> >>MIDI over IEEE-1394 (aka firewire) exists and is spec'ed by the MMA >>midi-consortium as an official standard. Unlike other publications from >>the MMA, this is a free download: >> >>http://www.midi.org/about-midi/rp27v10spec(1394).pdf >> >> > >Great! I guess I hadn't been paying attention. Thank you very much for >the link. > > Note that this is already implemented in FreeBob. There is nothing preventing us from setting up a (random number here)-channel MIDI link over Firewire between one or more devices. A major issue however is discovering the devices and negotiating a common stream format. This is not specified by the MMA, this spec only describes the actual transfer of the MIDI bytes. Another showstopper is that every sender will need his own firewire isochronous channel to send its data on, so that limits the number of devices to 16. Keep in mind that the Firewire bus is one single domain (for the Isochronous traffic), i.e. everybody sees everything. When using asynchronous traffic these restrictions don't apply but then you lose the 'broadcast' advantage, making everything more complex. Pieter From dsbaikov at gmail.com Sun Nov 12 11:45:06 2006 From: dsbaikov at gmail.com (Dmitry Baikov) Date: Sun Nov 12 11:45:14 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <45574BB7.2050209@joow.be> References: <4554FA6F.5020604@lakeinfoworks.com> <200611112141.10164.gene.heskett@verizon.net> <1163330197.9224.285.camel@c80-216-124-251.bredband.comhem.se> <200611120639.16022.gene.heskett@verizon.net> <45574BB7.2050209@joow.be> Message-ID: <70a871c80611120845q121562f7g84d27692a024f3f6@mail.gmail.com> What is a really major issue, that all hw synths still have that slow 31.5kbps link. Nonetheless, glad to hear FW-MIDI being that fast. And what about jitter there? According to RME guys, without special handling USB-MIDI can suffer delays about 6ms. And with FW, they state there are the same problems (no numbers here) and their Fireface has exceptional MIDI timing, comparing to all other FW-offerings. What do you think? Dmitry. From pieterp at joow.be Sun Nov 12 12:32:35 2006 From: pieterp at joow.be (Pieter Palmers) Date: Sun Nov 12 12:37:35 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <70a871c80611120845q121562f7g84d27692a024f3f6@mail.gmail.com> References: <4554FA6F.5020604@lakeinfoworks.com> <200611112141.10164.gene.heskett@verizon.net> <1163330197.9224.285.camel@c80-216-124-251.bredband.comhem.se> <200611120639.16022.gene.heskett@verizon.net> <45574BB7.2050209@joow.be> <70a871c80611120845q121562f7g84d27692a024f3f6@mail.gmail.com> Message-ID: <45575AB3.1020202@joow.be> Dmitry Baikov wrote: > What is a really major issue, that all hw synths still have that slow > 31.5kbps link. > > Nonetheless, glad to hear FW-MIDI being that fast. And what about > jitter there? > According to RME guys, without special handling USB-MIDI can suffer > delays about 6ms. true > And with FW, they state there are the same problems (no numbers here) > and their Fireface has exceptional MIDI timing, comparing to all other > FW-offerings. There is jitter on the firewire bus clock too, but not nearly as bad as USB. The timing resolution for a byte on a FW-MIDI channel is 125us (compared to 250us for normal MIDI). The jitter present on the ISO clock is magnitudes lower hence doesn not play a significant role. I'd like to see the technical motivation for this RME statement. Pieter From loki.davison at gmail.com Sun Nov 12 20:16:41 2006 From: loki.davison at gmail.com (Loki Davison) Date: Sun Nov 12 20:16:51 2006 Subject: [linux-audio-dev] Just a question/idea In-Reply-To: <455610F0.6000306@epitech.net> References: <455610F0.6000306@epitech.net> Message-ID: On 11/12/06, Elthariel wrote: > Hello, > > Here is just a simple question about linux audio. I'm looking for some > software which doesn't appear to exists. But it should be quite few > projects which have not release any code for the moment. So I'm asking > the question :) > Is there any windows manager that supports jack and lash, in order to > make the ''Desktop'' become a modular studio ? > > Is it possible at least ? > If it is, is there anyone here with the time and knowledges to start a > project of this kind ? > > Regards, > Elthariel. > I've been thinking about this myself. I might get on to coding something in the future and i'll give you a yell if anything comes of it. I'm thinking of something like the audio app being the WM as well, so there can be tracks for midi/audio/osc etc and also tracks which contain the actual window of the app. Zooming to any of these should be possible. Either being it up in more full sized audio editor/midi sequencer/bigger actual window. Could be a really neat way of doing stuff and quite easy to work out, as it would just be wrapping together a bunch of other apps. Lash etc making it all automagically work ;) Loki From drobilla at connect.carleton.ca Sun Nov 12 20:19:44 2006 From: drobilla at connect.carleton.ca (Dave Robillard) Date: Sun Nov 12 20:20:33 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <200611112141.10164.gene.heskett@verizon.net> References: <4554FA6F.5020604@lakeinfoworks.com> <200611111621.29969.gene.heskett@verizon.net> <200611112141.10164.gene.heskett@verizon.net> Message-ID: <1163380784.27080.1.camel@localhost.localdomain> On Sat, 2006-11-11 at 21:41 -0500, Gene Heskett wrote: > On Saturday 11 November 2006 21:00, Tony Nelson wrote: > >At 4:21 PM -0500 11/11/06, Gene Heskett wrote: > > ... > > > This thread might be of interest to the linux-audio-dev group, so I've > added them to the Cc: > > >>Yup, and its been a constant src of amazement to this old fart that > >> when the midi spec was setup, they used a serial port, thats fine, but > >> when they set the data rate at only 31,250 baud, ... > >> > >>Consistently attrocious timeing, with the horns always 1/16 beat late > >>unless the actual output order of each instrument is scrambled in the > >>order output. That would make it sound a heck of a lot less > >> mechanical. And there isn't a heck of a lot that can be done until we > >> put midi on an optical circuit running at several megabytes/sec. > >> Something like TOS maybe? > > > >Firewire. Many products already, plenty of speed, almost robust enough. > >1/8 millisecond isoch cycle times; each cycle can contain packets from > > many senders; each packet can contain lots of notes. > > More robust IMO than the din connectors now used for midi interconnects, > however the cabling itself can't help but be more fragile when subjected > to the rigors of a jam session with bodies walking on them all night. > And that has to be a consideration else the first users will get > discouraged at the high cable failure rates and revert, particularly if > they have a tin ear and can't hear what to many of us would be an > extremely obvious improvement. > > But I like that idea, a lot. Maybe some enterprising LAD people could get > together and spec something like a midi interface running over firewire, > complete with the repeaters so it can be daisy-chained just like midi can > be, and hopefully release it into the PD as a new midi-2 interface > standard. And design it such that it never, ever gets into the snails > trail of the 31,250 baud interface it uses today. Forget Firewire - Ethernet! Far cheaper, far more common, more hardware available (eg switches) -DR- From nettings at folkwang-hochschule.de Mon Nov 13 06:44:11 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Mon Nov 13 06:46:36 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <3c808a150611100940i65d4c0bfk76cf5f8e2712aecf@mail.gmail.com> References: <45547339.5000102@folkwang-hochschule.de> <3c808a150611100940i65d4c0bfk76cf5f8e2712aecf@mail.gmail.com> Message-ID: <45585A8B.7060105@folkwang-hochschule.de> Marc-Olivier Barre wrote: > On 11/10/06, Joern Nettingsmeier wrote: >> hi everyone! >> >> since my workload is not likely to go down in the future, and since i >> have unfortunately lost some touch with the linux audio community (i >> haven't actually read the lists very much lately, as my main occupations >> were live audio and [YUCK!] web development), i'd like to pass on the >> baton of the list maintainer. >> > Hi, > > I could give a hand there. I am system engineer for Nokia in France. > I'm used to working on distant UNIX servers. I have good experience > with mail servers, big clustered system and other things like that. > And more importantly, I could handle a spam filter if needed ;-) > > If being outside the US is not an issue, drop me an email, I'll be > glad to help. hi marc! thanks for your kind offer! being outside the u.s. is definitely not an issue (i'm from germany). i'll be on tour until wednesday, with scarce internet access - i'll get in touch afterwards. it might also be interesting to wait for one or two more volunteers, so that you can share the moderation task... ico's offer also sounds interesting - let's see what people think. regards, j?rn From nettings at folkwang-hochschule.de Mon Nov 13 06:49:26 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Mon Nov 13 06:50:59 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <000d01c7050a$ca5cf510$0302a8c0@64BitBadass> References: <000d01c7050a$ca5cf510$0302a8c0@64BitBadass> Message-ID: <45585BC6.4000201@folkwang-hochschule.de> Ivica Ico Bukvic wrote: > Is there any interest in the community to consolidate LA* lists in the > linuxaudio.org? We could certainly port the lists over if that is something > that may be of interest. Benefits of such a move would be consolidating > resources, reinforcing the Linuxaudio.org initiative, and if all else fails, > giving the lists a nice suffix :-) sounds like a nice idea to me, thanks ico for this offer. at this point, i should mention that douglas irving repetto at music.columbia.edu has always been very responsive and has kept a really neat shop as far as the list server is concerned, thanks doug! but i think he would not mind shedding some of its load :) what do other folks think? From dmidi at l4l.ie Tue Nov 14 16:40:36 2006 From: dmidi at l4l.ie (Jennifer Dillon) Date: Tue Nov 14 17:33:21 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <1163380784.27080.1.camel@localhost.localdomain> References: <4554FA6F.5020604@lakeinfoworks.com> <200611111621.29969.gene.heskett@verizon.net> <200611112141.10164.gene.heskett@verizon.net> <1163380784.27080.1.camel@localhost.localdomain> Message-ID: <20061114223313.C91D1412A94A@music.columbia.edu> Don't forget DMIDI IEEE P1639. Distributed MIDI over ethernet. It is still alive and well and I'm developing code for other Os's apart from Linux. Also working on a MIDI BOX with 32 MIDI ins and 32 MIDI outs all separately addressable and just plugs into a 10/100/1000 ethernet hub/switch. regards, Jennifer Dillon Dave Robillard writes: > On Sat, 2006-11-11 at 21:41 -0500, Gene Heskett wrote: >> On Saturday 11 November 2006 21:00, Tony Nelson wrote: >> >At 4:21 PM -0500 11/11/06, Gene Heskett wrote: >> > ... >> > >> This thread might be of interest to the linux-audio-dev group, so I've >> added them to the Cc: >> >> >>Yup, and its been a constant src of amazement to this old fart that >> >> when the midi spec was setup, they used a serial port, thats fine, but >> >> when they set the data rate at only 31,250 baud, ... >> >> >> >>Consistently attrocious timeing, with the horns always 1/16 beat late >> >>unless the actual output order of each instrument is scrambled in the >> >>order output. That would make it sound a heck of a lot less >> >> mechanical. And there isn't a heck of a lot that can be done until we >> >> put midi on an optical circuit running at several megabytes/sec. >> >> Something like TOS maybe? >> > >> >Firewire. Many products already, plenty of speed, almost robust enough. >> >1/8 millisecond isoch cycle times; each cycle can contain packets from >> > many senders; each packet can contain lots of notes. >> >> More robust IMO than the din connectors now used for midi interconnects, >> however the cabling itself can't help but be more fragile when subjected >> to the rigors of a jam session with bodies walking on them all night. >> And that has to be a consideration else the first users will get >> discouraged at the high cable failure rates and revert, particularly if >> they have a tin ear and can't hear what to many of us would be an >> extremely obvious improvement. >> >> But I like that idea, a lot. Maybe some enterprising LAD people could get >> together and spec something like a midi interface running over firewire, >> complete with the repeaters so it can be daisy-chained just like midi can >> be, and hopefully release it into the PD as a new midi-2 interface >> standard. And design it such that it never, ever gets into the snails >> trail of the 31,250 baud interface it uses today. > > Forget Firewire - Ethernet! > > Far cheaper, far more common, more hardware available (eg switches) > > -DR- > From steiner at block4.com Tue Nov 14 19:00:39 2006 From: steiner at block4.com (Malte Steiner) Date: Tue Nov 14 19:00:56 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <1163380784.27080.1.camel@localhost.localdomain> References: <4554FA6F.5020604@lakeinfoworks.com> <200611111621.29969.gene.heskett@verizon.net> <200611112141.10164.gene.heskett@verizon.net> <1163380784.27080.1.camel@localhost.localdomain> Message-ID: <455A58A7.7080501@block4.com> Some stuff to read for Ethernet Midi, here is a Real Time Transport protocol for Midi over network: http://tools.ietf.org/html/rfc4695 Cheers, Malte -- Malte Steiner media art + development -www.block4.com- From lars.luthman at gmail.com Wed Nov 15 16:43:14 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Wed Nov 15 16:43:35 2006 Subject: [linux-audio-dev] [ANN] GLASHCtl 0.4.0 Message-ID: <1163626995.11683.16.camel@c213-100-20-9.swipnet.se> This is a simple applet for controlling the LASH Audio Session Handler. When you run it it will appear as a small LASH icon in your "notification area" or "system tray" (if your desktop manager is compatible with freedesktop.org's "System tray" standard, http://www.freedesktop.org/Standards/systemtray-spec). This is typically somewhere in the panel in KDE or GNOME. There is also a front end for the WindowMaker dock (or compatible window managers). Changes since 0.2.0: * A DockApp front end (thanks to Nedko Arnaudov) * A "Recent" submenu for restoring recently saved sessions * A "Connect" submenu for connecting and disconnecting JACK ports * Doubleclicking session directories in the file selection dialog restores the session instead of going into the directory * The message window is removed Get it at http://dino.nongnu.org/glashctl -- 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/20061115/436c9c02/attachment.bin From tiwai at suse.de Thu Nov 16 12:31:58 2006 From: tiwai at suse.de (Takashi Iwai) Date: Thu Nov 16 12:35:32 2006 Subject: [linux-audio-dev] M$/SuSE/ALSA ? In-Reply-To: <45548AE4.2080208@woh.rr.com> References: <45548AE4.2080208@woh.rr.com> Message-ID: At Fri, 10 Nov 2006 09:21:24 -0500, Dave Phillips wrote: > > Greetings: > > As many of you already know, SuSE has entered into an interesting 5-year > plan with Microsoft. You can find the details on Slashdot and > elsewheres, so I won't rehash them here. > > What isn't mentioned is the ALSA/SuSE connection. I'm pretty sure some > of the ALSA developers read these lists, and I'd like to hear from them > regarding the significance of their employer's new connections and > ALSA's IP and its continued development. Well, my understanding is that the agreement doesn't change any situation. Novell argues that the whole packages _are_ patent-free and _will be_ in future, too. It means that we have no support for patent-protected WMV playback on Linux natively, and won't have a support in future, too, unless Microsoft explicitly licenses it. The agreement is not about allowing the patent for use. It's a kind of cold-war agreement, an assurace for world piece -- in theory :) The strange part is some exclusion meintioned in the agreement, and that confuses and angers people. I'm not sure how this deal influences in practice. But, the original idea isn't so spiteful as rumored everywhere... I hope. About the development in future: At least, I don't see any significant changes in the development inside Novell/SUSE. So is ALSA development, too. It's going on as it is now. We just need to keep our eyes more cafefully on the move of MS... Takashi From tiwai at suse.de Thu Nov 16 12:50:09 2006 From: tiwai at suse.de (Takashi Iwai) Date: Thu Nov 16 12:52:29 2006 Subject: [linux-audio-dev] Anyone to Desktop Architects Meeting 3? Message-ID: Hi, is anyone interested in participating in the third Desktop Architects Meething (DAM) on December 7-8 in Beaverton near Portland, Oregon? I'm not able to attend it (I'll be in vacation in Japan exactly at that time), and hope someone could be there as a linux audio developer... For details, please see: http://developer.osdl.org/dev/desktop_architects/index.php/Desktop_Architects_Meeting-3 Takashi From paul at linuxaudiosystems.com Thu Nov 16 13:09:11 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Thu Nov 16 13:10:48 2006 Subject: [linux-audio-dev] Anyone to Desktop Architects Meeting 3? In-Reply-To: References: Message-ID: <1163700551.2717.28.camel@localhost.localdomain> On Thu, 2006-11-16 at 18:50 +0100, Takashi Iwai wrote: > Hi, > > is anyone interested in participating in the third Desktop Architects > Meething (DAM) on December 7-8 in Beaverton near Portland, Oregon? > I'm not able to attend it (I'll be in vacation in Japan exactly at > that time), and hope someone could be there as a linux audio > developer... i was at DAM-1, i *might* be at DAM-3, not sure yet. From nettings at folkwang-hochschule.de Fri Nov 17 05:00:01 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Fri Nov 17 05:01:51 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <45547339.5000102@folkwang-hochschule.de> References: <45547339.5000102@folkwang-hochschule.de> Message-ID: <455D8821.3000809@folkwang-hochschule.de> hi marc-olivier, hi everyone! since there hasn't been any further discussion, i'm wrapping up the current state of affairs - from now on, "lazy consensus" is in effect, so if you disagree, holler now :) marc-olivier barre is volunteering to take over the job of list maintainer. thanks again for this kind offer! ico suggests to move the lists to linuxaudio.org. i like both ideas :) marc, if your offer still stands, please get in touch with me via private mail and send me an ssh key to grant you access to the list server account. (i will have to check with the site admin before installing it, but i'm sure there will be no objections.) to the others: i think it would be good to have another two list moderators for linux-audio-announce, in case people ever want to go on (gasp!) vacation, and to reduce the moderation lag... any takers? best regards, j?rn From tiwai at suse.de Fri Nov 17 07:15:51 2006 From: tiwai at suse.de (Takashi Iwai) Date: Fri Nov 17 07:16:06 2006 Subject: [linux-audio-dev] Anyone to Desktop Architects Meeting 3? In-Reply-To: <1163700551.2717.28.camel@localhost.localdomain> References: <1163700551.2717.28.camel@localhost.localdomain> Message-ID: At Thu, 16 Nov 2006 13:09:11 -0500, Paul Davis wrote: > > On Thu, 2006-11-16 at 18:50 +0100, Takashi Iwai wrote: > > Hi, > > > > is anyone interested in participating in the third Desktop Architects > > Meething (DAM) on December 7-8 in Beaverton near Portland, Oregon? > > I'm not able to attend it (I'll be in vacation in Japan exactly at > > that time), and hope someone could be there as a linux audio > > developer... > > i was at DAM-1, i *might* be at DAM-3, not sure yet. Oh, it would be best if you can attend DAM3. Takashi From jamesmichaelmcdermott at gmail.com Fri Nov 17 07:36:28 2006 From: jamesmichaelmcdermott at gmail.com (James McDermott) Date: Fri Nov 17 07:36:36 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <455D8821.3000809@folkwang-hochschule.de> References: <45547339.5000102@folkwang-hochschule.de> <455D8821.3000809@folkwang-hochschule.de> Message-ID: Hi J?rn and all, I was away and then ill for the past week, just coming to this mail now. > it would be good to have another two list moderators for linux-audio-announce [...] I'll continue to perform a spam-deletion-monkey role on LAA as often as I can, hopefully a bit more regularly than my xrun-ridden performance recently... James From nettings at folkwang-hochschule.de Fri Nov 17 07:57:48 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Fri Nov 17 07:59:45 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: References: <45547339.5000102@folkwang-hochschule.de> <455D8821.3000809@folkwang-hochschule.de> Message-ID: <455DB1CC.9040405@folkwang-hochschule.de> James McDermott wrote: > Hi J?rn and all, > > I was away and then ill for the past week, just coming to this mail now. > >> it would be good to have another two list moderators for >> linux-audio-announce [...] > > I'll continue to perform a spam-deletion-monkey role on LAA as often > as I can, hopefully a bit more regularly than my xrun-ridden > performance recently... ah, cool :) i was wondering how the mail queue got emptied while i was away! thanks :) From gene.heskett at verizon.net Fri Nov 17 09:49:44 2006 From: gene.heskett at verizon.net (Gene Heskett) Date: Fri Nov 17 09:50:23 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <455D8821.3000809@folkwang-hochschule.de> References: <45547339.5000102@folkwang-hochschule.de> <455D8821.3000809@folkwang-hochschule.de> Message-ID: <200611170949.44200.gene.heskett@verizon.net> On Friday 17 November 2006 05:00, Joern Nettingsmeier wrote: >hi marc-olivier, hi everyone! > > >since there hasn't been any further discussion, i'm wrapping up the >current state of affairs - from now on, "lazy consensus" is in effect, >so if you disagree, holler now :) > >marc-olivier barre is volunteering to take over the job of list >maintainer. thanks again for this kind offer! >ico suggests to move the lists to linuxaudio.org. >i like both ideas :) > >marc, if your offer still stands, please get in touch with me via >private mail and send me an ssh key to grant you access to the list >server account. (i will have to check with the site admin before >installing it, but i'm sure there will be no objections.) > >to the others: i think it would be good to have another two list >moderators for linux-audio-announce, in case people ever want to go on >(gasp!) vacation, and to reduce the moderation lag... any takers? > Will our subscriptions also move, or do we have to re-register at the new site? > >best regards, > >j?rn -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From ico at vt.edu Fri Nov 17 11:07:27 2006 From: ico at vt.edu (Ivica Ico Bukvic) Date: Fri Nov 17 11:07:53 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <200611170949.44200.gene.heskett@verizon.net> Message-ID: <00bd01c70a62$7a47ff40$0302a8c0@64BitBadass> AFAIK, there's no reason for the subscriptions to disappear if they are ported. In the worst case scenario, you may have to request a resend/regeneration of password should you decide to unsubscribe, but even that may not be necessary (depending how the listserv is set up on the old vs. new machine). Ico > -----Original Message----- > From: linux-audio-dev-bounces@music.columbia.edu [mailto:linux-audio-dev- > bounces@music.columbia.edu] On Behalf Of Gene Heskett > Sent: Friday, November 17, 2006 9:50 AM > To: linux-audio-dev@music.columbia.edu > Cc: Joern Nettingsmeier; linux-audio-user@music.columbia.edu > Subject: Re: [linux-audio-dev] [admin] new linux-audio-* maintainer > wanted... > > On Friday 17 November 2006 05:00, Joern Nettingsmeier wrote: > >hi marc-olivier, hi everyone! > > > > > >since there hasn't been any further discussion, i'm wrapping up the > >current state of affairs - from now on, "lazy consensus" is in effect, > >so if you disagree, holler now :) > > > >marc-olivier barre is volunteering to take over the job of list > >maintainer. thanks again for this kind offer! > >ico suggests to move the lists to linuxaudio.org. > >i like both ideas :) > > > >marc, if your offer still stands, please get in touch with me via > >private mail and send me an ssh key to grant you access to the list > >server account. (i will have to check with the site admin before > >installing it, but i'm sure there will be no objections.) > > > >to the others: i think it would be good to have another two list > >moderators for linux-audio-announce, in case people ever want to go on > >(gasp!) vacation, and to reduce the moderation lag... any takers? > > > Will our subscriptions also move, or do we have to re-register at the new > site? > > > > >best regards, > > > >j?rn > > -- > Cheers, Gene > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Yahoo.com and AOL/TW attorneys please note, additions to the above > message by Gene Heskett are: > Copyright 2006 by Maurice Eugene Heskett, all rights reserved. From mobarre at gmail.com Fri Nov 17 16:35:00 2006 From: mobarre at gmail.com (Marc-Olivier Barre) Date: Fri Nov 17 16:35:25 2006 Subject: [linux-audio-dev] [admin] new linux-audio-* maintainer wanted... In-Reply-To: <00bd01c70a62$7a47ff40$0302a8c0@64BitBadass> References: <200611170949.44200.gene.heskett@verizon.net> <00bd01c70a62$7a47ff40$0302a8c0@64BitBadass> Message-ID: <3c808a150611171335m3bcb5d9eoe8fc2b48ff5a5372@mail.gmail.com> On 11/17/06, Ivica Ico Bukvic wrote: > AFAIK, there's no reason for the subscriptions to disappear if they are > ported. In the worst case scenario, you may have to request a > resend/regeneration of password should you decide to unsubscribe, but even > that may not be necessary (depending how the listserv is set up on the old > vs. new machine). > > Ico > If we plan it properly, there should be no problem. Normally passwords should be migrated transparently with the rest. Except if I am wrong of course ;-) __________________ Marc-Olivier Barre, (Markinoko) Kinoko en Orbite. From dlphillips at woh.rr.com Tue Nov 21 08:33:12 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue Nov 21 08:27:19 2006 Subject: [linux-audio-dev] C++ guru needed (again) Message-ID: <45630018.8090400@woh.rr.com> Greetings: The following message is produced by Debian's GCC4 in 64Studio when compiling Csound5 for AMD64: g++ -o frontends/fltk_gui/CsoundGlobalSettings.o -c -fexceptions -Wall -g -gstabs -O2 -fPIC -DLINUX -DPIPES -DHAVE_LIBSNDFILE=1016 -DHAVE_FLTK -DBETA -DHAVE_FCNTL_H -DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_TERMIOS_H -DHAVE_SOCKETS -DHAVE_DIRENT_H -I. -IH -I/usr/local/include -I/usr/include -I/usr/X11R6/include -Iinterfaces -I/usr/include/freetype2 frontends/fltk_gui/CsoundGlobalSettings.cpp frontends/fltk_gui/CsoundGlobalSettings.cpp: In constructor 'CsoundGlobalSettings::CsoundGlobalSettings()': frontends/fltk_gui/CsoundGlobalSettings.cpp:47: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. See for instructions. For Debian GNU/Linux specific bug reporting instructions, see . Preprocessed source stored into /tmp/ccDt1tHZ.out file, please attach this to your bugreport. scons: *** [frontends/fltk_gui/CsoundGlobalSettings.o] Error 1 scons: building terminated because of errors. John ffitch has successfully compiled Cs5 for AMD64 with FLTK support, but he used GCC3. I've tried the various options for scons, but got no joy whenever I used Word64=1, the build always dies at the same point. Yes, I do see the compiler report request, but when I searched Google I found documents stating that this particular error was supposed to be resolved already by GCC4. Does anyone see what needs to be done to get past this point with the FLTK stuff in Cs5 ? Any suggestions for a fix ? I'll gladly furnish any other imformation required, just let me know what's needed. Best, dp From capocasa at gmx.net Tue Nov 21 11:40:27 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Tue Nov 21 11:41:38 2006 Subject: [linux-audio-dev] The Linux Audio Vision Message-ID: Hi, all! Contact me at: theman-AT-carlocapocasa.com As you might know I am a full time linux audio musician, and in the process of forming a company to produce music with linux audio exclusively and release it licensed CreativeCommons Attribution ShareAlike in OGG Vorbis format exclusively. (With the option to keep up with whatever standard the Free Community agrees on) I had one of my first sessions with Carlo, my partner today, and there is no doubt on my mind we will be very well received by a LOT of people. Lyrics are along the lines of the practical new age movement, which focuses on achieving goals using the mind as a primary tool. My goal is to create a company, that is a little bit different than other companies in that it has a broader definition of profit motive. The primary profit motive is satisfaction, while it is trusted that money will find itself a way to follow as well. Currently, this means specifically to simply sell some products on a musician's web site that has a lot of traffic because word of mouth draws people who want to download free music there. Contact me at: theman-AT-carlocapocasa.com To make linux audio more attractive, I am looking for developers to partner with me in building a "Just Works" device one can plug in the wall, and hear the latest and greatest of the Free Audio community. Ideally, the device would simply have an 'I Like It' button that would Cache whatever song is playing and direct the listener's preference profile toward similar songs. I would like to see this device be engineered using 'Free Engineering' principles, along the line of the Free Software community, being "funded" entirely by donated work efforts, all the way to the assembly line. This is an ambitious project, but I'm an ambitious kind of guy, and so our you when you let yourself be. I find it completely irrelevant what experience you have had in this field so far, as long as you feel a deep urge in yourself to be part of this project. Please contact me, right now! It doesn't matter if you don't know yet what exactly your participating what form it may take. Just contact me if you resonate with this idea and would be willing to donate a LOT of your time for this, for the reward of satisfaction, and probably some quite physical rewards as well; however these will be left to take care of themselves, which I trust they will. Contact me at: theman-AT-carlocapocasa.com I am also looking for developers who would like to fine-tune and even out current linux software synthesizers to make them completely rock-solid for live use, so anyone can use them to play a gig with 10'000 people without thinking once that there might be dropouts. Of course number of possible voices is limited by processing speed, however CPU cycles need to be managed in such a way that limitations in processing power are reported and can be dealt with off-stage. Most specifically, I am talking about ZynAddSubFX, and to some extent Om/Ingen. Another area that needs development power is transparency; ZynAddSubFX is a fantastic sounding synth, however its interface can be cumbersome for some purposes, specifically automation. Additionally, these sounds should be accessible in a standard way, without requiring but optionally enabling MIDI. The best way to accomplish these goals would be to create a ZynAddSubFX DSSI plugin with a complete redesign of the interface; in addition, a set of LADSPA plugins for use in modular synths would be excessively helpful. Again, it doesn't matter if you have development experience, it is plenty if you have the will and the dedication to invest your time and energy. I will work closely with you and your reward will be that YOU were the guy who made it possible for tens of thousands of people, heck, millions of people to enjoy the sound of the Free Software synthesizers played live and in realtime in the most advanced way possible. Contact me. Contact me at: theman-AT-carlocapocasa.com The company is not really a company in the conventional sense, just people working together on a common goal. There will be no central authority and no orders; just suggestions and mutual service. There will be no guaranteed rewards, however there is deep satisfaction that this project will be the only way for you to attain, you being the right person for this project. It will be your key to salvation if you will, your holy grail, your life's mantra. Devoting yourself fully to it you will open the possibility for "All the ways you haven't thought of yet" to come together and make it possible for you to continue living. And I'm not talking about just any living, I'm talking about living in TREMENDOUS WEALTH. Again, you will probably not receive your "rewards" directly in the form of a bribe, and you will certainly not be lead around by the nose with petty rewards. You will do what you do to accomplish your goals that satisfy you, and you will learn how to do that. Simultaneously, you will learn from me how to attract into your life whatever (material or not) you need to enjoy your life more, and how to open your channels for good to "happen to you". (Yes, money cars and women can "Happen To You", I will be more than happy to explain exactly how that works to you, all you need to do is ask.) So I'm looking for passionate software developers and engineers! Please contact me. Contact me at: theman-AT-carlocapocasa.com We will change how the world works. Money is a wonderful thing, if you don't let it dictate what you do and what you don't do. You can simply use it like you would use other shiny things, as a token of appreciation. You can also use it to encourage services where there would otherwise be ambivalence. Money is a good thing! And money definitely does not have to be a reason to do anything else than what YOU are passionate about; and this, as parts of the free software community, we will demonstrate to the world in undeniable clarity. Have any of you noticed how sleek and, in short, how amazingly good the Mozilla browser is? I mean three platforms, and this software quality, that is nothing short of a miracle. Linux Audio can be that way too! We just need to get a little more organized, and I will be more than happy to serve as a usability expert, since I'm a guy who uses the software professionally and I have the technical skills to communicate what needs to be changed and what most realistically can be changed (while still keep a "No Limits" attitude. Contact me at: theman-AT-carlocapocasa.com Join me! Help me create good free software AND free hardware. You don't need to know how, and I don't need to know how. Faith and action will take care of the rest. Whatever techniques you will need to accomplish these goals will come to you as soon as you have made a definitive decision to accomplish them. All you need do is decide that it WILL happen and never think back. The free hardware is so sexy you would hardly believe it. Think of it! We can be giving away "music boxes" that are constantly loaded with the latest in the free music community, according to the listener's preferences, which he can communicate with a big red button. Lit with a high-powered LED. Man this is so sexy I almost have to change my underwear after even thinking about this. Join me, guys! Contact me at: theman-AT-carlocapocasa.com Carlo From lars.luthman at gmail.com Tue Nov 21 12:47:50 2006 From: lars.luthman at gmail.com (Lars Luthman) Date: Tue Nov 21 12:48:37 2006 Subject: [linux-audio-dev] The Linux Audio Vision In-Reply-To: References: Message-ID: <1164131270.11717.34.camel@c213-100-20-9.swipnet.se> On Tue, 2006-11-21 at 17:40 +0100, Carlo Capocasa wrote: > I had one of my first sessions with Carlo, my partner today Your partner is also named Carlo? =) > Another area that needs development power is transparency; ZynAddSubFX > is a fantastic sounding synth, however its interface can be cumbersome > for some purposes, specifically automation. Additionally, these sounds > should be accessible in a standard way, without requiring but optionally > enabling MIDI. The best way to accomplish these goals would be to create > a ZynAddSubFX DSSI plugin with a complete redesign of the interface; There is a disabled build option for a DSSI interface in ZynAddSubFX, so it looks like Paul Nasca also has been thinking about this. I managed to get it to build as a plugin with some minor hacks, but I couldn't get any sound from it. > in addition, a set of LADSPA plugins for use in modular synths would be > excessively helpful. Nedko Arnaudov is working on rewriting the ZynAddSubFX synthesis engines as separate LV2 plugins. I don't know if he's planning to do all the effects as well. -- 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/20061121/123ba931/attachment.bin From capocasa at gmx.net Tue Nov 21 14:06:24 2006 From: capocasa at gmx.net (Carlo Capocasa) Date: Tue Nov 21 14:08:20 2006 Subject: [linux-audio-dev] Re: The Linux Audio Vision In-Reply-To: <1164131270.11717.34.camel@c213-100-20-9.swipnet.se> References: <1164131270.11717.34.camel@c213-100-20-9.swipnet.se> Message-ID: > Your partner is also named Carlo? =) When people want to talk to both us, they can yell "Hey, Carlos!" > There is a disabled build option for a DSSI interface in ZynAddSubFX, so > it looks like Paul Nasca also has been thinking about this. I managed to > get it to build as a plugin with some minor hacks, but I couldn't get > any sound from it. So did I, it wasn't actually usable though. I couldn't get my host (Om) to recognize it. >> in addition, a set of LADSPA plugins for use in modular synths would be >> excessively helpful. > > Nedko Arnaudov is working on rewriting the ZynAddSubFX synthesis engines > as separate LV2 plugins. I don't know if he's planning to do all the > effects as well. Sweeeeet! That's just insanely wonderful. Since you replied here, you might be interested in getting involved somehow (which, if you happen to be developing linux audio, you already are :). But feel free to share any ideas. Carlo From paniq at paniq.org Tue Nov 21 19:30:10 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Tue Nov 21 19:31:41 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed Message-ID: <1164155410.12714.11.camel@localhost> hi everybody, i'm looking for a sampler instrument file format similar to .nki, .sf2 or akai instruments. is there an open standard existing already, perhaps even accompanied by some sort of library? -- -- Leonard Ritter -- http://www.leonard-ritter.com -- http://www.paniq.org From ce at christeck.de Tue Nov 21 19:45:28 2006 From: ce at christeck.de (Christoph Eckert) Date: Tue Nov 21 19:44:30 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <1164155410.12714.11.camel@localhost> References: <1164155410.12714.11.camel@localhost> Message-ID: <200611220145.29299.ce@christeck.de> > is there an open standard existing already at least I remember that there has been a discussion about exactly this topic (creating an open format) on one of the lists, but I don't know on which list it was and if it lead to any result. I know this doesn't really help :) , ce From t_w_ at freenet.de Wed Nov 22 04:27:43 2006 From: t_w_ at freenet.de (Thorsten Wilms) Date: Wed Nov 22 04:28:24 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <1164155410.12714.11.camel@localhost> References: <1164155410.12714.11.camel@localhost> Message-ID: <20061122092743.GA5635@charly.SWORD> On Wed, Nov 22, 2006 at 01:30:10AM +0100, Leonard paniq Ritter wrote: > hi everybody, > > i'm looking for a sampler instrument file format similar to .nki, .sf2 > or akai instruments. is there an open standard existing already, perhaps > even accompanied by some sort of library? http://resonance.org:8000/openinstruments/show/HomePage (Didn't take off) -- Thorsten Wilms From paniq at paniq.org Wed Nov 22 06:43:22 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Nov 22 06:43:35 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <20061122092743.GA5635@charly.SWORD> References: <1164155410.12714.11.camel@localhost> <20061122092743.GA5635@charly.SWORD> Message-ID: <1164195802.5641.7.camel@localhost> from what i see, sf2 seems to be quite popular, due to fluidsynth, so i will start off there. i suppose any open format should be based on sf2 lingo, with perhaps an bin/xml-in-zip based structure. we recently created a new tracker module file format based on that, and it works out pretty well... i believe svgz works quite the same way (not quite tho). so i suppose the best way would be to reimplement sf2 as some kind of xsfz format, write a forth-back conversion library/utility and release the whole work under a bsd licence to make it easy for free and commercial developers to catch up... On Wed, 2006-11-22 at 10:27 +0100, Thorsten Wilms wrote: > On Wed, Nov 22, 2006 at 01:30:10AM +0100, Leonard paniq Ritter wrote: > > hi everybody, > > > > i'm looking for a sampler instrument file format similar to .nki, .sf2 > > or akai instruments. is there an open standard existing already, perhaps > > even accompanied by some sort of library? > > http://resonance.org:8000/openinstruments/show/HomePage > (Didn't take off) > > > -- > Thorsten Wilms -- -- Leonard Ritter -- http://www.leonard-ritter.com -- http://www.paniq.org From cuse at users.sourceforge.net Wed Nov 22 08:17:34 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Wed Nov 22 08:18:30 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <1164195802.5641.7.camel@localhost> References: <1164155410.12714.11.camel@localhost> <20061122092743.GA5635@charly.SWORD> <1164195802.5641.7.camel@localhost> Message-ID: <200611221417.34834.cuse@users.sourceforge.net> Am Mittwoch, 22. November 2006 10:27 schrieb Thorsten Wilms: > > i'm looking for a sampler instrument file format similar to .nki, .sf2 > > or akai instruments. is there an open standard existing already, perhaps > > even accompanied by some sort of library? > > http://resonance.org:8000/openinstruments/show/HomePage > (Didn't take off) We started discussion on that list a while ago, but not really with a consensus. It fell asleep majorly due to priorites. Am Mittwoch, 22. November 2006 12:43 schrieb Leonard "paniq" Ritter: > from what i see, sf2 seems to be quite popular, due to fluidsynth, so i > will start off there. i suppose any open format should be based on sf2 > lingo, with perhaps an bin/xml-in-zip based structure. we recently > created a new tracker module file format based on that, and it works out > pretty well... i believe svgz works quite the same way (not quite tho). > > so i suppose the best way would be to reimplement sf2 as some kind of > xsfz format, write a forth-back conversion library/utility and release > the whole work under a bsd licence to make it easy for free and > commercial developers to catch up... Sound Font is a dead end. One of the few things that was agreed by the majority on that list, was to use an XML based format for the articulation informations, probably encapsulated into a common compression format. Which makes sense, considering where we all come from. You know.... command line fetishists, light-weight text editor freaks. CU Christian From conrad.berhoerster at gmx.de Wed Nov 22 09:40:08 2006 From: conrad.berhoerster at gmx.de (conrad =?iso-8859-1?q?berh=F6rster?=) Date: Wed Nov 22 09:38:38 2006 Subject: [linux-audio-dev] restarting jack Message-ID: <200611221540.09848.conrad.berhoerster@gmx.de> Hello all, is there a way to restart jack out of an application, or is this the reason, why ardour need a running jackd. i want to write an application with a "reinit app" button and need a way to restart jackd, if it has been crashed. thanks c~ From fons.adriaensen at skynet.be Wed Nov 22 09:52:44 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 22 09:50:32 2006 Subject: [linux-audio-dev] Yet Another Scrolling Scope Message-ID: <20061122145244.GC5941@linux-1.site> A first release of Yass is now avaiable at . Yass is a 'scrolling scope' jack client. It has been hanging around in prototype form for some time. This is a first beta release. Main features: - up to 32 channels, - variable scrolling speed, - configurable trace colors, - automatic gain control, - very light on CPU use. Enjoy ! -- FA Lascia la spina, cogli la rosa. From paul at linuxaudiosystems.com Wed Nov 22 09:54:56 2006 From: paul at linuxaudiosystems.com (Paul Davis) Date: Wed Nov 22 09:55:05 2006 Subject: [linux-audio-dev] restarting jack In-Reply-To: <200611221540.09848.conrad.berhoerster@gmx.de> References: <200611221540.09848.conrad.berhoerster@gmx.de> Message-ID: <1164207296.2717.406.camel@localhost.localdomain> On Wed, 2006-11-22 at 15:40 +0100, conrad berh?rster wrote: > Hello all, > > is there a way to restart jack out of an application, or is this the reason, > why ardour need a running jackd. > i want to write an application with a "reinit app" button and need a way to > restart jackd, if it has been crashed. please the documentation for jack_client_open() From fons.adriaensen at skynet.be Wed Nov 22 09:52:44 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 22 10:36:26 2006 Subject: [linux-audio-dev] Yet Another Scrolling Scope Message-ID: <20061122145244.GC5941@linux-1.site> A first release of Yass is now avaiable at . Yass is a 'scrolling scope' jack client. It has been hanging around in prototype form for some time. This is a first beta release. Main features: - up to 32 channels, - variable scrolling speed, - configurable trace colors, - automatic gain control, - very light on CPU use. Enjoy ! -- FA Lascia la spina, cogli la rosa. From pcoccoli at gmail.com Wed Nov 22 12:14:40 2006 From: pcoccoli at gmail.com (Paul Coccoli) Date: Wed Nov 22 12:15:49 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <200611221417.34834.cuse@users.sourceforge.net> References: <1164155410.12714.11.camel@localhost> <20061122092743.GA5635@charly.SWORD> <1164195802.5641.7.camel@localhost> <200611221417.34834.cuse@users.sourceforge.net> Message-ID: <8d27a0610611220914k4204ddbeob21f22df2a7db0af@mail.gmail.com> On 11/22/06, Christian Schoenebeck wrote: > Am Mittwoch, 22. November 2006 10:27 schrieb Thorsten Wilms: > > > i'm looking for a sampler instrument file format similar to .nki, .sf2 > > > or akai instruments. is there an open standard existing already, perhaps > > > even accompanied by some sort of library? > > > > http://resonance.org:8000/openinstruments/show/HomePage > > (Didn't take off) > > We started discussion on that list a while ago, but not really with a > consensus. It fell asleep majorly due to priorites. > Ah, Design By Committee. From cuse at users.sourceforge.net Wed Nov 22 12:41:20 2006 From: cuse at users.sourceforge.net (Christian Schoenebeck) Date: Wed Nov 22 12:42:12 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <8d27a0610611220914k4204ddbeob21f22df2a7db0af@mail.gmail.com> References: <1164155410.12714.11.camel@localhost> <200611221417.34834.cuse@users.sourceforge.net> <8d27a0610611220914k4204ddbeob21f22df2a7db0af@mail.gmail.com> Message-ID: <200611221841.20292.cuse@users.sourceforge.net> Am Mittwoch, 22. November 2006 18:14 schrieb Paul Coccoli: > > > http://resonance.org:8000/openinstruments/show/HomePage > > > (Didn't take off) > > > > We started discussion on that list a while ago, but not really with a > > consensus. It fell asleep majorly due to priorites. > > Ah, Design By Committee. Hey, don't throw such words at me! A committee usually involves exclusion of people (and is often a playground for people with profile neurosis). That mailing list was public though and without any pseudo "official" attitude. From paniq at paniq.org Wed Nov 22 14:12:19 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Nov 22 14:12:29 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <200611221417.34834.cuse@users.sourceforge.net> References: <1164155410.12714.11.camel@localhost> <20061122092743.GA5635@charly.SWORD> <1164195802.5641.7.camel@localhost> <200611221417.34834.cuse@users.sourceforge.net> Message-ID: <1164222739.5641.24.camel@localhost> On Wed, 2006-11-22 at 14:17 +0100, Christian Schoenebeck wrote: > > so i suppose the best way would be to reimplement sf2 as some kind of > > xsfz format, write a forth-back conversion library/utility and release > > the whole work under a bsd licence to make it easy for free and > > commercial developers to catch up... > > Sound Font is a dead end. One of the few things that was agreed by the > majority on that list, was to use an XML based format for the articulation > informations, probably encapsulated into a common compression format. Which > makes sense, considering where we all come from. You know.... command line > fetishists, light-weight text editor freaks. which is exactly what i was suggesting. i'm not calling to use sf2 as a standard, but using merely the order, metaphors and lingo of the format description so people feel at home, and mental mapping becomes easier. the new format will be extensible, so it's not bad to start off with a known feature set. it will take a few weeks until i have time for this, so be prepared :) -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com From paniq at paniq.org Wed Nov 22 14:13:50 2006 From: paniq at paniq.org (Leonard "paniq" Ritter) Date: Wed Nov 22 14:14:39 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <200611221841.20292.cuse@users.sourceforge.net> References: <1164155410.12714.11.camel@localhost> <200611221417.34834.cuse@users.sourceforge.net> <8d27a0610611220914k4204ddbeob21f22df2a7db0af@mail.gmail.com> <200611221841.20292.cuse@users.sourceforge.net> Message-ID: <1164222830.5641.27.camel@localhost> On Wed, 2006-11-22 at 18:41 +0100, Christian Schoenebeck wrote: > Hey, don't throw such words at me! A committee usually involves exclusion of > people (and is often a playground for people with profile neurosis). That > mailing list was public though and without any pseudo "official" attitude. i usually prefer designs where someone takes the benevolent dictator position, pulls out a whack prototype and shapes it by community comments on it. ;) -- -- Leonard Ritter -- http://www.leonard-ritter.com -- http://www.paniq.org From dominic.sacre at gmx.de Wed Nov 22 14:14:11 2006 From: dominic.sacre at gmx.de (Dominic =?iso-8859-1?q?Sacr=E9?=) Date: Wed Nov 22 14:17:01 2006 Subject: [linux-audio-dev] Yet Another Scrolling Scope In-Reply-To: <20061122145244.GC5941@linux-1.site> References: <20061122145244.GC5941@linux-1.site> Message-ID: <200611222014.11840.dominic.sacre@gmx.de> On Wednesday 22 November 2006 15:52, Fons Adriaensen wrote: > A first release of Yass is now avaiable at > > . Thanks! Got one problem though: high CPU load (I'm not kidding). At small window sizes everything's fine, but when it exceeds a certain size (a little less than fullscreen on my machine), CPU load immediately goes up from ~5% to 100%, drawing starts to lag behind, and X becomes very sluggish... Dominic From fons.adriaensen at skynet.be Wed Nov 22 16:06:31 2006 From: fons.adriaensen at skynet.be (Fons Adriaensen) Date: Wed Nov 22 16:04:32 2006 Subject: [linux-audio-dev] Yet Another Scrolling Scope In-Reply-To: <200611222014.11840.dominic.sacre@gmx.de> References: <20061122145244.GC5941@linux-1.site> <200611222014.11840.dominic.sacre@gmx.de> Message-ID: <20061122210631.GE5941@linux-1.site> On Wed, Nov 22, 2006 at 08:14:11PM +0100, Dominic Sacr? wrote: > Got one problem though: high CPU load (I'm not kidding). At small window > sizes everything's fine, but when it exceeds a certain size (a little > less than fullscreen on my machine), CPU load immediately goes up from > ~5% to 100%, drawing starts to lag behind, and X becomes very sluggish... How much is fullscreen or your system ? This looks like insufficient pixmap space on the X-server. I've noticed another lock-up problem: yass stops scrolling and takes 100% CPU. Happened once here after many hours of running. The two may be related. Here is the real .yassrc: % Configuration file for Yass % Everything in this file can also be put in a system-wide % configuration file '/etc/yass.conf'. % % Instances started with -name NAME will read '~/.NAMErc' % instead of this file. % % The same options can also be put in '~/.Xdefaults', and % will then apply to all instances started by the same user. % Default number of channels and connections. % Modify as required % Yass.nchan: 8 Yass.trace.colors: 11223344 Yass.input_1: alsa_pcm:capture_1 Yass.input_2: alsa_pcm:capture_2 Yass.input_3: alsa_pcm:capture_3 Yass.input_4: alsa_pcm:capture_4 Yass.input_5: alsa_pcm:capture_5 Yass.input_6: alsa_pcm:capture_6 Yass.input_7: alsa_pcm:capture_7 Yass.input_8: alsa_pcm:capture_8 % Alternate colors, uncomment and modify to taste. % %Yass.color.main.bg: black %Yass.color.trace.bg: white %Yass.color.trace.c0 gray50 %Yass.color.trace.c1 blue %Yass.color.trace.c2 coral %Yass.color.trace.c3 darkgreen %Yass.color.trace.c4 black -- FA Lascia la spina, cogli la rosa. From dominic.sacre at gmx.de Wed Nov 22 17:32:41 2006 From: dominic.sacre at gmx.de (Dominic =?iso-8859-1?q?Sacr=E9?=) Date: Wed Nov 22 17:35:48 2006 Subject: [linux-audio-dev] Yet Another Scrolling Scope In-Reply-To: <20061122210631.GE5941@linux-1.site> References: <20061122145244.GC5941@linux-1.site> <200611222014.11840.dominic.sacre@gmx.de> <20061122210631.GE5941@linux-1.site> Message-ID: <200611222332.41061.dominic.sacre@gmx.de> On Wednesday 22 November 2006 22:06, Fons Adriaensen wrote: > How much is fullscreen or your system ? This looks like insufficient > pixmap space on the X-server. Fullscreen would be 1280x960, problems start at roughly 1000x900 or something. But even at somewhat smaller window sizes, just slightly resizing the window causes an increase in CPU load for up to a few seconds. Drawing then lags behind for a while, but eventually catches up, and CPU load goes back to normal. An then, when I increase the window size a little more, somewhere it reaches the point where it just never catches up, and eats 100% CPU indefinitely. > I've noticed another lock-up problem: yass stops scrolling and > takes 100% CPU. Happened once here after many hours of running. > The two may be related. From parumi at iua.upf.edu Fri Nov 24 10:03:33 2006 From: parumi at iua.upf.edu (Pau Arumi) Date: Fri Nov 24 10:11:52 2006 Subject: [linux-audio-dev] The best LV2 examples Message-ID: <456709C5.4090900@iua.upf.edu> Hi all! I want to learn LV2 to integrate the architecture in clam. (http://clam.iua.upf.edu) What examples of plugins and hosts do you recommend me? Thanks, Pau -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From danni.coy at gmail.com Sat Nov 25 20:56:50 2006 From: danni.coy at gmail.com (Danni Coy) Date: Sat Nov 25 20:57:24 2006 Subject: [linux-audio-dev] Annouce: initial release of Miditoys... Message-ID: <8459c9dc0611251756ra4ae924m669c426ce9c26f98@mail.gmail.com> Miditoys is a small program I wrote so I could use some of my more interesting peripheral devices as midi instruments.... So far I have a reasonable attempt at a midi control surface using a playstation 2 style gamepad... and the beginings of a drumkit using the same device... This program is still very much in its infancy... There is very little in the way of documentation - If you are interested or you run into problems I please contact me More details at: http://miditoys.sourceforge.net From danni.coy at gmail.com Sat Nov 25 21:11:30 2006 From: danni.coy at gmail.com (Danni Coy) Date: Sat Nov 25 21:11:36 2006 Subject: [linux-audio-dev] Re: alsa, oss , efficiency? Message-ID: <8459c9dc0611251811p52617513je443821643552781@mail.gmail.com> cool it guys... It sounds like the person who asked the question only really needs to use sound in a really simple way and that performance is not a huge issue.... I would like to ask what other libraries are being used in your application.. how portable you want it to be... From conrad.berhoerster at gmx.de Sun Nov 26 05:59:08 2006 From: conrad.berhoerster at gmx.de (conrad =?utf-8?q?berh=C3=B6rster?=) Date: Sun Nov 26 05:58:42 2006 Subject: [linux-audio-dev] restarting jack In-Reply-To: <1164207296.2717.406.camel@localhost.localdomain> References: <200611221540.09848.conrad.berhoerster@gmx.de> <1164207296.2717.406.camel@localhost.localdomain> Message-ID: <200611261159.09636.conrad.berhoerster@gmx.de> Am Mittwoch 22 November 2006 15:54 schrieb Paul Davis: > On Wed, 2006-11-22 at 15:40 +0100, conrad berh?rster wrote: > > Hello all, > > > > is there a way to restart jack out of an application, or is this the > > reason, why ardour need a running jackd. > > i want to write an application with a "reinit app" button and need a way > > to restart jackd, if it has been crashed. > > please the documentation for jack_client_open() thanks paul, everywhere this small prints B=) this seems to work, but .... i need to start jack with rtlimits. somewhere i have read, that i can restart jack with an specified command. Does this include the rtlimit command? Do you have an example ? sizu c~ From doj at cubic.org Sun Nov 26 06:23:18 2006 From: doj at cubic.org (Dirk Jagdmann) Date: Sun Nov 26 06:23:45 2006 Subject: [linux-audio-dev] C++ guru needed (again) In-Reply-To: <45630018.8090400@woh.rr.com> References: <45630018.8090400@woh.rr.com> Message-ID: <45697926.5010904@cubic.org> Hello Dave, those internal compiler errors are often triggered only when you optimize. As a workaround I would suggest you try compiling this particular source file with -O1 or without any -O options. If you don't want your complete program be compiled with optimization, which would occur if you disable it when calling ./configure you can compile this file manually by going into the frontends/ directory and pasting the command line with -O2. Then continue compiling with scons. > g++ -o frontends/fltk_gui/CsoundGlobalSettings.o -c -fexceptions -Wall > -g -gstabs -O2 -fPIC -DLINUX -DPIPES -DHAVE_LIBSNDFILE=1016 -DHAVE_FLTK > -DBETA -DHAVE_FCNTL_H -DHAVE_UNISTD_H -DHAVE_STDINT_H -DHAVE_SYS_TIME_H > -DHAVE_SYS_TYPES_H -DHAVE_TERMIOS_H -DHAVE_SOCKETS -DHAVE_DIRENT_H -I. > -IH -I/usr/local/include -I/usr/include -I/usr/X11R6/include > -Iinterfaces -I/usr/include/freetype2 > frontends/fltk_gui/CsoundGlobalSettings.cpp > frontends/fltk_gui/CsoundGlobalSettings.cpp: In constructor > 'CsoundGlobalSettings::CsoundGlobalSettings()': > frontends/fltk_gui/CsoundGlobalSettings.cpp:47: internal compiler error: > output_operand: invalid expression as operand > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > For Debian GNU/Linux specific bug reporting instructions, > see . > Preprocessed source stored into /tmp/ccDt1tHZ.out file, please attach > this to your bugreport. > scons: *** [frontends/fltk_gui/CsoundGlobalSettings.o] Error 1 > scons: building terminated because of errors. -- ---> Dirk Jagdmann ^ doj / cubic ----> http://cubic.org/~doj -----> http://llg.cubic.org From mail at jensgulden.de Mon Nov 27 06:42:21 2006 From: mail at jensgulden.de (Jens Gulden) Date: Mon Nov 27 06:43:46 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <1164222830.5641.27.camel@localhost> References: <1164155410.12714.11.camel@localhost> <200611221417.34834.cuse@users.sourceforge.net> <8d27a0610611220914k4204ddbeob21f22df2a7db0af@mail.gmail.com> <200611221841.20292.cuse@users.sourceforge.net> <1164222830.5641.27.camel@localhost> Message-ID: <456ACF1D.6080102@jensgulden.de> Hello, > open standard existing already ...? > We started discussion on that list a while ago, > http://resonance.org:8000/openinstruments/show/HomePage (Didn't take off) The mailing-list archive http://resonance.org/pipermail/open-instruments/ says there have been no posts to the list yet. This is not completely true, on 2005-09-20 I wrote to open-instruments@resonance.org: > I have written down some ideas on modeling 'Time', 'Positions' and 'Parts' of audio waveforms in XML: > > http://swiki.hfbk-hamburg.de:8888/MusicTechnology/786 > > (...) > The approach tries to capture the notions of time, positions and parts > as 'musically' as possible. For example, 'Time' can be handled either as > clock-seconds, as beats, as sample-frames, or relative to the length > of a 'Part'. 'Positions' can be declared relative to other 'Positions', > 'Parts' may be nested inside other 'Parts', etc. > > Includes a prototype implementation for SuperCollider3 with BBCut 1.3, using a SuperCollider > library for XML (http://swiki.hfbk-hamburg.de:8888/MusicTechnology/747). Maybe this is still interesting to somebody... best Jens Leonard "paniq" Ritter schrieb: > On Wed, 2006-11-22 at 18:41 +0100, Christian Schoenebeck wrote: > >>Hey, don't throw such words at me! A committee usually involves exclusion of >>people (and is often a playground for people with profile neurosis). That >>mailing list was public though and without any pseudo "official" attitude. > > > i usually prefer designs where someone takes the benevolent dictator > position, pulls out a whack prototype and shapes it by community > comments on it. ;) > From _ at whats-your.name Mon Nov 27 07:48:28 2006 From: _ at whats-your.name (carmen) Date: Mon Nov 27 07:48:36 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <456ACF1D.6080102@jensgulden.de> References: <1164155410.12714.11.camel@localhost> <200611221417.34834.cuse@users.sourceforge.net> <8d27a0610611220914k4204ddbeob21f22df2a7db0af@mail.gmail.com> <200611221841.20292.cuse@users.sourceforge.net> <1164222830.5641.27.camel@localhost> <456ACF1D.6080102@jensgulden.de> Message-ID: <20061127124828.GA27008@replic.net> > >library for XML (http://swiki.hfbk-hamburg.de:8888/MusicTechnology/747). > > Maybe this is still interesting to somebody... nice start. care to port it to an RDF schema? From mail at jensgulden.de Mon Nov 27 10:32:50 2006 From: mail at jensgulden.de (Jens Gulden) Date: Mon Nov 27 10:46:35 2006 Subject: [linux-audio-dev] sampler instrument definition standard needed In-Reply-To: <20061127124828.GA27008@replic.net> References: <1164155410.12714.11.camel@localhost> <200611221417.34834.cuse@users.sourceforge.net> <8d27a0610611220914k4204ddbeob21f22df2a7db0af@mail.gmail.com> <200611221841.20292.cuse@users.sourceforge.net> <1164222830.5641.27.camel@localhost> <456ACF1D.6080102@jensgulden.de> <20061127124828.GA27008@replic.net> Message-ID: <456B0522.4090801@jensgulden.de> carmen schrieb: > nice start. care to port it to an RDF schema? The model is verbally described in a file 'proposal.html' inside http://swiki.hfbk-hamburg.de:8888/MusicTechnology/uploads/786/spec-slices-0_1.zip (together with some schematic drawing). So this could be used to implement it with other syntaxes than XML, too. If you want to do this it's nice - please let me know if you do so. But I don't have plans to further work on this now. best Jens From dlphillips at woh.rr.com Mon Nov 27 11:32:48 2006 From: dlphillips at woh.rr.com (Dave Phillips) Date: Mon Nov 27 11:26:15 2006 Subject: [linux-audio-dev] C++ guru needed (again) In-Reply-To: <45697926.5010904@cubic.org> References: <45630018.8090400@woh.rr.com> <45697926.5010904@cubic.org> Message-ID: <456B1330.6090109@woh.rr.com> Dirk Jagdmann wrote: > those internal compiler errors are often triggered only when you > optimize. As a workaround I would suggest you try compiling this > particular source file with -O1 or without any -O options. > If you don't want your complete program be compiled with optimization, > which would occur if you disable it when calling ./configure you can > compile this file manually by going into the frontends/ directory and > pasting the command line with -O2. Then continue compiling with scons. Hi Dirk, I did as you suggested and built the module without problems. But when I ran scons again it recompiled the object with the -O2 optimization (and failed again, of course). So I changed the default in the SConstruct file and built Csound5 without optimization. It compiled without trouble and appears to be working okay. I'm still testing, but thank you for the direction. :) Best, dp From musound at jps.net Tue Nov 28 12:19:27 2006 From: musound at jps.net (Sean Bolton) Date: Tue Nov 28 12:17:43 2006 Subject: [linux-audio-dev] [ANN] ghostess 20061127 release Message-ID: <7c6e73b222c88e20a28ab9958314e82b@jps.net> Announcing the latest release of ghostess, a lightweight Gtk+ host for DSSI plugins: http://home.jps.net/~musound/ghostess-20061127.tar.gz New in this release: - bug fixes, build enhancements and code cleanups. - code to export patch lists to Freewheeling. - support for the latest JACK MIDI transport. - blinky lights indicating MIDI activity. ghostess is written by Sean Bolton, and copyright (c)2006 under the GNU General Public License, version 2 or later. DSSI is an audio plugin API for software instruments and effects, based on LADSPA, the ALSA sequencer event types, and OSC (Open Sound Control) communications. Learn more about it here: http://dssi.sourceforge.net/ Enjoy! -Sean From jens.andreasen at chello.se Thu Nov 30 13:44:10 2006 From: jens.andreasen at chello.se (Jens M Andreasen) Date: Thu Nov 30 13:44:21 2006 Subject: [linux-audio-dev] Re: MIDI In-Reply-To: <45574BB7.2050209@joow.be> References: <4554FA6F.5020604@lakeinfoworks.com> <200611112141.10164.gene.heskett@verizon.net> <1163330197.9224.285.camel@c80-216-124-251.bredband.comhem.se> <200611120639.16022.gene.heskett@verizon.net> <45574BB7.2050209@joow.be> Message-ID: <1164912250.9224.494.camel@c80-216-124-251.bredband.comhem.se> On Sun, 2006-11-12 at 17:28 +0100, Pieter Palmers wrote: [regarding midi over firewire] > Note that this is already implemented in FreeBob. There is nothing > preventing us from setting up a (random number here)-channel MIDI link > over Firewire between one or more devices. > > A major issue however is discovering the devices and negotiating a > common stream format. This is not specified by the MMA, this spec only > describes the actual transfer of the MIDI bytes. > Pieter, I am not sure that I follow you correctly here. Using bad car-anology: Is this like as if you have already build "The Golden Gate Bridge", but there are still no "Highways" connecting to it? That there is a sinc to throw the bytes into but no way for alsa to know about it? In other words; is a device like M-Audio's 4ch audio in/out + 3 octave keyboard useful as a performance instrument under Linux, or will the keyboard be dead? > Another showstopper is that every sender will need his own firewire > isochronous channel to send its data on, so that limits the number of > devices to 16. Keep in mind that the Firewire bus is one single domain > (for the Isochronous traffic), i.e. everybody sees everything. > Uhmm yes, but as I read from the paper, the midi transfer rate is (or can be) quadrupled. Given that a home/stage setup with a single player on a single cable works just fine latency-wise, wouldn't then 16*4 be quite enough? At the risk of paraphrazing Bill Gates, but 64 staves ought to be enough for anyone ... You could fit in two symphonic orchestras, mixed choir, a couple of organs, a big band as well as an extended Irish folk-group into that budget (and then some.) Jokes aside: I don't see any external firewire computing devices where one could send all those midi2 messages to. Anyone else? > When using asynchronous traffic these restrictions don't apply but then > you lose the 'broadcast' advantage, making everything more complex. > > > Pieter -- From nettings at folkwang-hochschule.de Thu Nov 30 15:15:19 2006 From: nettings at folkwang-hochschule.de (Joern Nettingsmeier) Date: Thu Nov 30 15:24:50 2006 Subject: [linux-audio-dev] [admin] maintainership passes on... Message-ID: <456F3BD7.3090507@folkwang-hochschule.de> hi everyone! i'm very happy to announce that marc-olivier barre will be maintaining the linux-audio-* lists from now on. let me take this opportunity to ask for a few more volunteers to moderate linux-audio-announce. get this: for years, brilliant minds like ingo molnar, robert love and lee revellhave been toiling with the kernel for a few measly microseconds gain - as a linux-audio-announce moderator, you can cut latencies by hours if not days. how is that for a claim to fame? please get in touch with marc-olivier. it's been a pleasure to participate in this linux audio community for all those years, and i have profited immensely from the great work done here! thanks everyone, and i hope to see you around at LAC 2007! best wishes, j?rn -- j?rn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D