Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
Juhana Sadeharju hat gesagt: // Juhana Sadeharju wrote: I tried to contribute my developments to Snd, but heard nothing back from its author. Not a thanks, nothing. If you're not able to suggest and develop features to the editor, it is not that good for the _user_. I am not involved in SND development, but reading Dave Phillips' SND/CoolEdit articles on O'Reilly Net, I get the impression, that SND is moving in a more user friendly direction. If the editors would be placed on the shelf because they look good, then I would have no complaints; however, editors are really meant as tools for artists/users. I don't get that: Are you saying, that SND looks good? It's a joke, isn't it ;) Ciao, -- ____ Frank Barknecht __ __ trip\ \ / /wire __ / __// __ /__/ __// // __ \ \/ / __ \\ ___\ / / / / / / / // // /\ \\ ___\\ \ /_/ /_/ /_/ /_//_// / \ \\_\\_\ /_/\_\
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
On Tuesday 23 Oct 2001 8:18 am, Frank Barknecht wrote: Juhana Sadeharju hat gesagt: // Juhana Sadeharju wrote: I tried to contribute my developments to Snd, but heard nothing back from its author. Not a thanks, nothing. If you're not able to suggest and develop features to the editor, it is not that good for the _user_. I am not involved in SND development, but reading Dave Phillips' SND/CoolEdit articles on O'Reilly Net, I get the impression, that SND is moving in a more user friendly direction. I think that must have been an oversight, Juhana: I contributed a really, really dirty hack to do (very limited) esd compatibility, and got more thanks than I deserve. Maybe some email got lost in a delete-fest. I do that from time to time 8-) Nick/
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
I don't get that: Are you saying, that SND looks good? It's a joke, isn't it ;) It does look good ; ) As an editor I equate it with SoundEdit for the Mac. However I've never found it to be comprehensive or flexible enough to satisfy projects that requiring deeper editing. EG: broad sample and bit-rate conversion with noise shaping and dithering, filter preview, infinite undos, high bit-rate non-destructive editing, spectral analysis, midi time-code import, extensive right click menus and a comprehensive multitrack studio with panning and amplitude envelopes and broad mixdown capability. Cool-Edit Professional for windows, this is a fine editor - a good benchmark for developments under linux. So far GSMP looks like a good contender..though I've only spent a day with it so far de| Interactive Information Institute R.M.I.T Melbourne Australia
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
I tried to contribute my developments to Snd, but heard nothing back from its author. This is a lie -- I never received anything from you except a copy of some complaints you sent to SoundForge.
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
delire wrote: [re: Snd] It does look good ; ) As an editor I equate it with SoundEdit for the Mac. However I've never found it to be comprehensive or flexible enough to satisfy projects that requiring deeper editing. EG: broad sample and bit-rate conversion with noise shaping and dithering, filter preview, infinite undos, high bit-rate non-destructive editing, spectral analysis, midi time-code import, extensive right click menus and a comprehensive multitrack studio with panning and amplitude envelopes and broad mixdown capability. I guess you haven't seen it lately. Certainly the undo can be as deep as you prefer and spectral analysis features have been there for a while. Editing is non-destructive, even at 32 bits (unless I'm not understanding you correctly ?). Right-click popup menus are now available for whole file and selected area. Panning and amplitude enveloping is also available (always has been, I think). O'Reilly Network recently published my status report on my work with Bill Schottstaedt to externalize more of Snd's possibilities. We've added dozens of GUI components for effects (Snd and LADSPA), cursor control, popup menus, and so forth. If you're interested in the O'Reilly article you can check it out here: http://linux.oreillynet.com/pub/a/linux/2001/10/05/snd_partone.html http://linux.oreillynet.com/pub/a/linux/2001/10/05/snd_parttwo.html MIDI support is on Bill's TODO list. IMO, the issue of multitrack recording seems better left to dedicated multitrack recorders (Ardour, ecasound). Snd is an editor, that's what it aims to do and that's all it does. Cool-Edit Professional for windows, this is a fine editor - a good benchmark for developments under linux. So far GSMP looks like a good contender..though I've only spent a day with it so far I've been spending more time with other Linux audio editors, including GSMP, Audacity, DAP, and others. I'm still inclined to keep working to expose more of Snd's power rather than contribute to another project either stalled or coming in at version 0.0.1a. Just my preference, of course... Best regards, == Dave Phillips The Book Of Linux Music Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://sound.condorow.net Currently listening to: O presul vere (Hildegard von Bingen)
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
MIDI support is on Bill's TODO list. IMO, the issue of multitrack recording seems better left to dedicated multitrack recorders (Ardour, ecasound). Snd is an editor, that's what it aims to do and that's all it does. [ ... ] I've been spending more time with other Linux audio editors, including GSMP, Audacity, DAP, and others. I'm still inclined to keep working to expose more of Snd's power rather than contribute to another project either stalled or coming in at version 0.0.1a. Just my preference, of course... Yay! for sanity. Most people have no idea what Snd is capable of. So to fix it, they sit down and write another editor. Dave is encouraging/helping Bill to do a much more sensible thing: exposing the things Snd can do so that you're less likely to run off and do this. I claim an exemption for myself, having spent quite a bit of time deep inside Snd as I attempted to use it as the editor for Ardour. As Dave notes, and others would do well to heed, editing an audio file is one thing, multichannel work and/or audio sequencing is something else. --p
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
just trying to install GSMP on a suse 7.1 box at another studio and ./configure produces the error: cannot find STL file sstream i've never come across this before..any solutions? has all the same gtkmm / alsa / and libsigc++ libs etc as the debian box it compiled successfully on.. de|
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
From: Bill Schottstaedt [EMAIL PROTECTED] I tried to contribute my developments to Snd, but heard nothing back from its author. This is a lie -- I never received anything from you except a copy of some complaints you sent to SoundForge. I have not sent any complaints to SoundForge. The two mails I mailed both to you and to David described my observations on what features an editor needs for being usable (for editing audio files I prefer to edit) --- with my wish that those features would find their way to Snd before I have a change to move to Snd. Also, pointing out problems and giving a solution is not a complaint. AND, I did _not_ get any reply from you. Does the same complaints apply to Snd too? Lets get the ball rolling: here are a couple of features needed for succesful basic editing (no need to reread my mails!): -Software volume (up to +64 dB, say); this feature is needed for listening cut points between quiet fades, but also in noise reduction software where one needs to find the background- noise-only areas (i.e., the noise floor) [ as discussed here, Wavelab implements this with a plug-in at output path; good idea ] -Play feature where the region between the mouse pointer and the nearest edge of the selection is played; this makes it possible to play the ends of the selection, and check if anything important was accidentally left outside the selection [such a feature is in XWave2 (which is my version of XWave)] -Recording dropouts marked as red colored regions to waveform display so that one can see both if dropouts occured and if a dropout landed on the important part of the take; a close encounter with Alsa needed SoundForge misses both two first features which makes it impossible (IMHO) to make accurate edits. But I repeat my question: how people do it without those features? I'm puzzled. (Actually, a friend mastering CDs professionally turned volumes high up when listening cut points near fades; occasionally he forgot to turn the volume down, eek --- doesn't make good to speakers, nor ears.) Bill, what is your opinion on people who don't contribute code but only feature ideas and design? I just want to make sure I don't waste time here. Best regards, Juhana
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
Emiliano Grilli wrote: I read part one of your tutorial and found it *very* interesting. Thank you also for your site, which is a cornerstone in my bookmarks. Unfortunately, I can't find the part two of the snd tutorial, and the link you provided in this email seems to be broken. Please tell me the correct URL of the article, if you have time... My bad, sorry. Here's the URL for Part 2 of my article: http://linux.oreillynet.com/pub/a/linux/2001/10/18/snd_parttwo.html Best regards, == Dave Phillips The Book Of Linux Music Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://sound.condorow.net Currently listening to: Vos flores rosarum (Hildegard von Bingen)
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
Hi. On Tue, 23 Oct 2001 23:18:49 +1000 delire [EMAIL PROTECTED] wrote: just trying to install GSMP on a suse 7.1 box at another studio and ./configure produces the error: cannot find STL file sstream i've never come across this before..any solutions? has all the same gtkmm / alsa / and libsigc++ libs etc as the debian box it compiled successfully on.. This is a check if the STL (Standard Template Library) of C++ is up to date. It seems that it is at a wrong location on this SuSE system (or not all c++ development packages are installed ??) (Since I use ROCKLinux (www.rocklinux.org) I expected such compile errors and I like to be cc'ed in private, too ...) de| k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) eMail:[EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.rene.rebe.myokay.net/ Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.
Re: [linux-audio-dev] low latency + mp3
On Mon, Oct 22, 2001 at 10:34:11PM +1000, David Burrows wrote: The bonus question is about pitch control. I understand that this can be achieved by simply changing the sampling rate, however, I'm wondering if anyone has knowledge of fast or high quality resampling algorithms? I think you can do spectral encoding with loads of bands to get very high quality resampling plus you can do all kinds of other funky stuff with it. however, this technique is nearly impossible to do realtime on std computer hardware, atleast with a load of bands. to do spectral encoding you seperate the freq spectrum into a load of bands and analize the sample and record the amplitude for each band at time t. then you can play back that recording resynthesizing the original sample using sine waves but with a altered speed. you can stop time and stuff like that. i suppose bspline interpolation works equally well ;) cheers -- jelle herold (defekt) http://defekt.nl/ seeing digital http://channelthree.net/
[linux-audio-dev] Audio streaming over network
Hi all Does anyone here know of a library or API for streaming audio over a network? The library should take into account the inevitable clock drift between the machine generating the stream and the machine receiving it. I presume this would involve resampling/reclocking of some kind. Thanks for all replies! Ryan
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
Hi. On Tue, 23 Oct 2001 07:01:20 -0700 Bill Schottstaedt [EMAIL PROTECTED] wrote: IMO, the issue of multitrack recording seems better left to dedicated multitrack recorders (Ardour, ecasound). I agree completely -- I haven't had time yet to try out ecasound, but Fernando showed me Ardour and it is beautiful. I'm very tempted to remove the Record option from Snd! As a bit of boring history, that dialog dates back to the SGI days, and was ported to Linux at a time when Soundblaster cards were about as good as you could get; I was trying at the time to fill an obvious need. Some short points about why I developed another Audio Editor (and to end the discussion why another one). 1. I started to play with such stuff in the i386 times under DOS 2. When I started to use Linux (3? years ago) there was no audio editor solution 3. All the other applicatoins that came up during this time had a few probelms: a) not powerfull enough b) not useable The exceptions are at least Ardour and snd. Ardour never compiled on my system and targets another area (seems to be everything-in-one-place(tm) hard-disk- recorder emulation). SND was one of the not-powerfull/not-useable tools some years ago and I took a look onit a few month ago - and I gave up compiling it. gcc -c -DHAVE_CONFIG_H -g -O2 -I/usr/include -I/usr/X11R6/include clm.c clm.c:40: gsl/gsl_complex_math.h: No such file or directory In file included from clm.c:5955: /usr/include/gsl/gsl_sf_bessel.h:8: gsl_mode.h: No such file or directory /usr/include/gsl/gsl_sf_bessel.h:9: gsl_precision.h: No such file or directory /usr/include/gsl/gsl_sf_bessel.h:10: gsl_sf_result.h: No such file or directory make: *** [clm.o] Error 1 (Yes I have a development system (and my whole distribution compiles on this system!) - and the only programs I have compile prolems with, were Ardour and SND ... ?!) We would have contributed to a project - if there would have been one (not C hacked) one year ago. GSMP would have been released last autumn - if the book C++ TPL from Bjarne Stroustrup hadn't sliped through my hands ... IMO this is the most interesting point on GSMP. Is is fully obejct-oriented, features a very cool plugin and activator system, many GUI componets are generated dynamically ... It is not just another wave-editor, and we WILL continue developing it. (BTW: We have already produced a CD with it ;-) k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) eMail:[EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.rene.rebe.myokay.net/ Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.
RE: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
-Original Message- From: delire [mailto:[EMAIL PROTECTED]] just trying to install GSMP on a suse 7.1 box at another studio and ./configure produces the error: cannot find STL file sstream i've never come across this before..any solutions? has all the same gtkmm / alsa / and libsigc++ libs etc as the debian box it compiled successfully on.. on a debian unstable: jojda:~locate sstream /usr/include/g++-3/sstream jojda:~dpkg -S sstream libstdc++2.10-dev: /usr/include/g++-3/sstream jojda:~ erik
Re: [linux-audio-dev] Audio streaming over network
On Tue, 23 Oct 2001, Ryan Mitchley wrote: Hi all Does anyone here know of a library or API for streaming audio over a network? The library should take into account the inevitable clock drift between the machine generating the stream and the machine receiving it. I presume this would involve resampling/reclocking of some kind. Thanks for all replies! Ryan Check out sfront at http://www.cs.berkeley.edu/~lazzaro/sa/ -- [EMAIL PROTECTED] (M. Edward Borasky) http://www.aracnet.com/~znmeb Relax! Run Your Own Brain with Neuro-Semantics! http://www.aracnet.com/~znmeb/Flyer.htm What phrase will you *never* hear Miss Piggy use? You can't make a silk purse out of a sow's ear!
Re: [linux-audio-dev] Audio streaming over network
On Tue, 23 Oct 2001, Ryan Mitchley wrote: Hi all Does anyone here know of a library or API for streaming audio over a network? M. Edward (Ed) Borasky writes Check out sfront at http://www.cs.berkeley.edu/~lazzaro/sa/ Soon, but not quite yet -- at the moment, sfront networking does MIDI resilently for low-latency situations, and while you could concievably hack this to do audio (sending samples encoded as MIDI change-control events, and reassmbling on the other side), you really don't want to go there. I'm actively working on SASL networking for sfront at the moment -- SASL is the more general-purpose control language for Structured Audio, provided as a companion to MIDI control. SASL is well suited for writing custom audio codecs in Structured Audio, so once the SASL packetization is ready, sfront should be a viable platform for these sorts of experiments. But not for another few months ... --jl
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
Rene Rebe wrote: On Tue, 23 Oct 2001 13:47:34 -0600 D. Stimits [EMAIL PROTECTED] wrote: [...] If it is a matter of location, use locate g++-3/sstream to find it It shouldn't be a matter of location. We use: configure.in: AC_CHECK_HEADER(sstream,,AC_MSG_ERROR(missing STL file sstream)) and in the sources: #include sstream So his Linux system hasn't one in the paths the cpp searches through. - So there is even no STL on it ?? (or an really old one containing sstream.h??) Until recently, there wasn't *any* sstream. He can have STL, but upgrades have to be done on Redhat 6.2 and earlier to get this particular one. I guess the key is that if there is an include subdirectory g++-3 then it should be there. Before this version, sstream did not exist on Linux. D. Stimits, [EMAIL PROTECTED] (run updatedb if needed before this). D. Stimits, [EMAIL PROTECTED] k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) eMail:[EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.rene.rebe.myokay.net/ Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.
Re: [linux-audio-dev] Audio streaming over network
On Tue, 23 Oct 2001, John Lazzaro wrote: Soon, but not quite yet -- at the moment, sfront networking does MIDI resilently for low-latency situations, and while you could concievably hack this to do audio (sending samples encoded as MIDI change-control events, and reassmbling on the other side), you really don't want to go there. I'm actively working on SASL networking for sfront at the moment -- SASL is the more general-purpose control language for Structured Audio, provided as a companion to MIDI control. SASL is well suited for writing custom audio codecs in Structured Audio, so once the SASL packetization is ready, sfront should be a viable platform for these sorts of experiments. But not for another few months ... Sorry ... I guess I was getting ahead of you :-). I just wish there were more publicly available SASL-controlled instruments available. Almost everything I've found so far uses MIDI control, which is a pain to hack around. -- [EMAIL PROTECTED] (M. Edward Borasky) http://www.aracnet.com/~znmeb Relax! Run Your Own Brain with Neuro-Semantics! http://www.aracnet.com/~znmeb/Flyer.htm What phrase will you *never* hear Miss Piggy use? You can't make a silk purse out of a sow's ear!
Re: [linux-audio-dev] W64 file format
On Tuesday 23 October 2001 04:00 pm, Erik de Castro Lopo wrote: Hi People, I currently have one example of this file format and I need more. The single file I have is a 16 bit stereo file. I need some more files and what I'm looking for (if they are available) is as follows: - a mono file of any bitwidth - files containing more than 2 channels - files containing 8, 24 or 32 bit PCM data - files containing float or double data - files containing looping and other information - files containing encoded data (ie not PCM nor float/double) If anybody wishes to help this Free Software project by supplying examples files I would be very pleased to hear from them. Please don't email files to me without asking first as I would like to prevent my mail box from overflowing with multiple copies of the same file. I can send you some, it appears that theres no support for multi channel 64 bit wave files. Looks like these are supported : ACELP.net A-law U-law True Speech GSM6.10 IAC2 IEEE float (uncompressed) IMA ADPCM LH CELP 4.8kbit/s LH SBC 12 LH SBC 16LH SBC 8 MS ADPCM MS G.723.1 mp3 PCM which ones do you want? What length? Can't do multi channel ljp
Re: [linux-audio-dev] multitrack and editor separate?
As Dave notes, and others would do well to heed, editing an audio file is one thing, multichannel work and/or audio sequencing is something else. ...sure, but Cool-Edit Professional for windows shows how often a static mixing [multitrack] environment is used as an intergral part of the overall editing project - you make a mix of several samples and dump it back in the editor for further processing. maybe afterwards you send it back to the multitracker to layer it up with other samples. sequencing, well that is for a very particular kind of composition. syntrillium [producer] obviously recognises that a multitracker should in fact come with the editor, and does a very fine job of making this work. in work that i do, for instance [and i am not an exception] , it isn't uncommon to have 70 or 80 samples open simultaneously in a composition; by being able to double-click a wave in the multitrack window to take me over to the waveform where i edit it further [without saving] and then return to the multitrack, provides for a highly efficient working environment. having to open up the file in a separate editor, then save it, then re-open it up in the multitrack makes larger compositional projects, like electroacoustic work, special fx and film scores very difficult. they don't have to be together in the same window [as in SoundEdit16 on the mac for instance], so much as a click apart; as in many other application environments where you have eg: a 'objects' [editor] and 'scenes' [multitrack]. for this reason the ABC in my country, and several universities are replacing other professional editing/multitrack packages with Cool-Edit Pro..it is testimony that there is a wide demand for an editor and multitracker to be put together in an intuitive relation. if you are, however, lucky enough to be one of those rare composers that can produce all their samples first before taking them over to the multitracker - then a separation of these two parts of the composition process is not a problem. for the rest of us howver, composition is so often about trying out arrangements of timbres, textures, acoustics, amplitudes, harmonics and noise beds during the working process. for this reason a multiracker / editor combination is ideal. de| Interactive Information Institute R.M.I.T Melbourne Australia
Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
fair enough, must admit i haven't looked at snd in quite a while... what's promised in the o'reilly articles looks amazing - i'll download the latest version and check it out. de| - Original Message - From: Dave Phillips [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, 23 October 2001 10:46 Subject: Re: [linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1 I guess you haven't seen it lately. Certainly the undo can be as deep as you prefer and spectral analysis features have been there for a while. Editing is non-destructive, even at 32 bits (unless I'm not understanding you correctly ?). Right-click popup menus are now available for whole file and selected area. Panning and amplitude enveloping is also available (always has been, I think).
[linux-audio-dev] alsa latency statistics
i just finished testing several different patched and unpatched linux kernels, and was surprised by the results: all basically the same. alsarange = 33.4% to 33.8%1.336 ms to 1.352 msdiff = 0.016 ms oss-emu range = 91.6% to 91.9%3.664 ms to 3.676 msdiff = 0.012 ms as you can see, the differences are negligible and probably irrelevant if more tested were done, and a standard 2.4.12 kernel is just as good as any patched kernel. one note: when i did a real-world test of latency by looping a signal through my card and dividing the difference in time by 2 (because of input and output latency), i got 3.675 ms latency using kernel 2.4.8-ll with oct 1 alsa-cvs, and that corresponds with the oss-emu latency for some reason instead of the alsa latency. i don't know why, and i'll test this on other kernels soon. my system is an amd athlon 900 mhz running at 1006 mhz with redhat 7.1 and an m-audio delta audiophile 2496 soundcard. i used alsa-cvs from october 20 and takashi iwai's modified version of latencytest0.42+alsa. the kernels tested are 2.4.8-ll, 2.4.9-ll, 2.4.10-ll, 2.4.10-pe, 2.4.12, 2.4.12-ac2, 2.4.12-ac2-ll, 2.4.12-ac3, and 2.4.12-ac3-pe. ll = low-latency pe = pre-emptive ac2 and ac3 are alan cox's patches latencytest was ran as follows: ./latencytest -t alsa -d hw -q none 3 256 ./latencytest -t oss -q none 3 256 -dave details below: --- sample rate = 48000 NUMBER of OVERRUNS = 0 PIXEL_PER_MS=112 fragment latency = 1.33 ms buffer latency= 4.000 ms fragment size=256 total buffer size=768 cpu_load= 80.% cpu latency = 1.07 ms with alsa, 100% of samples are within 1ms of buffer used alsa-cvs from oct 20, oss = alsa's oss-emu 2.4.10-ll output type = ALSA max latency=1.3 ms factor=33.4 % of buffer output type = OSS max latency=3.7 ms factor=91.6 % of buffer 1MS factor=83.4679932MS factor=99.937850 2.4.10-pe output type = OSS max latency=3.7 ms factor=91.9 % of buffer 1MS factor=83.3676982MS factor=99.965636 output type = ALSA max latency=1.3 ms factor=33.6 % of buffer 2.4.12-ac2-ll output type = ALSA max latency=1.3 ms factor=33.7 % of buffer output type = OSS max latency=3.7 ms factor=91.7 % of buffer 1MS factor=83.4008102MS factor=99.932524 2.4.12-ac2 output type = ALSA max latency=1.3 ms factor=33.4 % of buffer output type = OSS max latency=3.7 ms factor=91.7 % of buffer 1MS factor=83.3729222MS factor=99.966067 2.4.12-ac3 output type = ALSA max latency=1.4 ms factor=33.8 % of buffer output type = OSS max latency=3.7 ms factor=91.7 % of buffer 1MS factor=83.3613922MS factor=99.971942 2.4.12-ac3-pe output type = ALSA max latency=1.3 ms factor=33.5 % of buffer output type = OSS max latency=3.7 ms factor=91.7 % of buffer 1MS factor=83.3902162MS factor=99.943117 2.4.12 output type = ALSA max latency=1.3 ms factor=33.4 % of buffer output type = OSS max latency=3.7 ms factor=91.7 % of buffer 1MS factor=83.3728282MS factor=99.960506 2.4.8-ll output type = ALSA max latency=1.3 ms factor=33.6 % of buffer output type = OSS max latency=3.7 ms factor=91.6 % of buffer 1MS factor=83.4028362MS factor=99.972199 2.4.9-ll output type = ALSA max latency=1.3 ms factor=33.4 % of buffer output type = OSS max latency=3.7 ms factor=91.7 % of buffer 1MS factor=83.3850932MS factor=99.948240
Re: [linux-audio-dev] multitrack and editor separate?
...sure, but Cool-Edit Professional for windows shows how often a static mixing [multitrack] environment is used as an intergral part of the overall editing project - you make a mix of several samples and dump it back in the editor for further processing. maybe afterwards you send it back to the multitracker to layer it up with other samples. sequencing, well that is for a very particular kind of composition. syntrillium [producer] obviously recognises that a multitracker should in fact come with the editor, and does a very fine job of making this work. except that this is linux, where fork(2) is cheap, and IPC is the most efficient available. what reason is there for requiring a user to use *your* sample editor when your main focus was on multitrack editing and sequencing? why not let the user choose a 3rd party editor? suppose i prefer bias peak to cool edit for sample editing, for example? in work that i do, for instance [and i am not an exception] , it isn't uncommon to have 70 or 80 samples open simultaneously in a composition; by being able to double-click a wave in the multitrack window to take me over to the waveform where i edit it further [without saving] and then return to yep. just fork snd, or audacity, or gsmp, or sweep, or gnoise, or DAP or whatever you want. the downside is that you don't get non-destructive editing. see, the dedicated waveform editor in your windows tool isn't really doing sound *file* editing, its doing the same kind of non-destructive editing that the rest of the program is doing (i.e. just rearranging playlists). for this reason the ABC in my country, and several universities are replacing other professional editing/multitrack packages with Cool-Edit Pro..it is testimony that there is a wide demand for an editor and multitracker to be put together in an intuitive relation. the relationship, as you noted, has more to do with 1 click away than it does with anything else. however, i would agree that it is harder to make them work together if the relationship has to be based around a stored audiofile rather than a playlist/EDL. personally speaking, i might just hack this feature in ardour tonight :) --p
[linux-audio-dev] What version of Broadcast that is still available is the least buggy?
Hi, I've recently installed Mdk 8.1 and Bcast2000 (c version) is having problems displaying waveforms (it is completely out of whack displaying it way beyond the reasonable range, so I need to zoom out the y axis all the way in order to get somewhat of a visible waveform). Is this the case with all of the versions or is there a version that has this working properly. In another words, which version is the best out there (since it has been pulled I am looking for the best remaining version)? Thanks for your help! Sincerely, Ico Bukvic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andre Pang Sent: Sunday, October 21, 2001 3:37 AM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] preemptive kernel patch On Sat, Oct 20, 2001 at 02:33:09PM -0500, dave willis wrote: where can i get the preemptive kernel patch? i've tried searches but get everything but... http://www.tech9.net/rml/linux/ -- #ozone/algorithm [EMAIL PROTECTED] - trust.in.love.to.save
[linux-audio-dev] RE: What version of Broadcast that is still available is the least buggy?
Crap, please disregard this last post, it seems I was trying to import a non-normalized file (DOH!). Sorry for cluttering your mailboxes! -Original Message- From: Ivica Bukvic [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 24, 2001 12:21 AM To: [EMAIL PROTECTED] Subject: What version of Broadcast that is still available is the least buggy? Hi, I've recently installed Mdk 8.1 and Bcast2000 (c version) is having problems displaying waveforms (it is completely out of whack displaying it way beyond the reasonable range, so I need to zoom out the y axis all the way in order to get somewhat of a visible waveform). Is this the case with all of the versions or is there a version that has this working properly. In another words, which version is the best out there (since it has been pulled I am looking for the best remaining version)? Thanks for your help! Sincerely, Ico Bukvic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andre Pang Sent: Sunday, October 21, 2001 3:37 AM To: [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] preemptive kernel patch On Sat, Oct 20, 2001 at 02:33:09PM -0500, dave willis wrote: where can i get the preemptive kernel patch? i've tried searches but get everything but... http://www.tech9.net/rml/linux/ -- #ozone/algorithm [EMAIL PROTECTED] - trust.in.love.to.save
[linux-audio-dev] Re: [Alsa-user] gsmp release 0.0.1
I wrote: You really should announce this on linux-audio-dev, too. Uhm, you did. Procmail outsmarted me. -- Frank Barknecht
[linux-audio-dev] anyone using code based on audioengine
i just uncovered a subtle bug in the audioengine inner loop. it might not affect you, but then again, if it does, it will be nasty. when i wrote audioengine, the idea was to guarantee that all clients would never be asked to process more frames than was specified in the last call to their set_block_size() method. unfortunately, the engine does not honor this guarantee: in the event of a scheduling delay which causes us to be notified of N periods worth of data/space at once, rather than a single period's worth, the clients are asked to process it all at once, instead of subdividing into N calls to process(). i have fixed the sources, and a fix will be in CVS tonight. it would be worth thinking about whether any code you might be using that was based on this stuff is affected. i know that i have to fix JACK as well, for identical reasons. i'll put out a new version of JACK tomorrow. --p
