Re: [linux-audio-dev] JAAA Bandw parameter
On Sun, Dec 12, 2004 at 06:54:46AM +0300, Andrew Gaydenko wrote: 1. Can anybody explain me (I think, Fons Adriaensen can :-) the JAAA Bandw parameter meaning? The bandwidth determines how much detail you see on the frequency scale. If you have a small bandwidth, you will be able to separate two signals that are very close together in frequency, while for a larger bandwidth they will merge into a single peak. So why not use a very small bandwidth all the time ? The reason is that small bandwidth requires a longer FFT, and you will see less detail in time. So there is a tradeoff to be made between resolution in time and in frequency. 2. When Bandw parameter is rather small, I see two spectrums - main (blue) and, below the first, - the second one (gray). What is the last spectre spectrum meaning? From the README : 'Bandw' sets the FFT length, and hence the bandwidth of the analyser. Depending on this value, the size of the display and the frequency range, you may sometimes see two traces. This happens when the resolution of the analyser is better than the display, so that one pixel contains more than one analyser value. In that case, the blue trace is the peak value over the frequency range represented by each pixel, and the gray one is the average value. The first one is correct for discrete frequencies, and the latter should be used to read noise densities. To see this, switch on both the sine and noise generators, and loop back into JAAA. Set a bandwidth and frequency range that gives you the two separate traces. Now put a peak marker on the tone, and a noise marker somewhere on the noise. You will see that the noise marker is on the gray trace. -- FA
[linux-audio-dev] aubio - library for audio labelling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI, i spotted the first announcement of this library on freshmeat today aubio is a library for audio labelling. Features include onset detection (the complex task of labelling the beginning of notes and other sound events), silence detection (an easier but very useful task) and pitch detection (the estimation of the fundamental frequency of the sound). The aim is to add these automatic labelling features to other audio softwares. Functions can be used offline in sound editors and software samplers, or online in audio effects and virtual instruments. http://aubio.piem.org i think that Paul Brossier is not in this list... ciao - -- jaromil, dyne.org rasta coder, http://rastasoft.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Cryptographically signed mail, see http://gnupg.org iD8DBQFBvBxbWLCC1ltubZcRAgcQAKDP/4ZPU8qaCrbY53uvisHVnmt+xgCg1iWJ RCOu0vEnDt76eTM7UfUnWy8= =Vbf8 -END PGP SIGNATURE-
Re: [linux-audio-user] Re: [linux-audio-dev] RME is no more
Frank Barknecht [EMAIL PROTECTED] writes: So basically they want to protect their investment in getting knowledge of how to implement a powerful firewire interface from the eyes of other hardware manufacturers. A society where you put money higher than cooperating with other people is not a good society, in my opinion. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
[linux-audio-dev] announce-list policy
Hello everybody, when linux-audio-announce was created, it was agreed that announcements should be crossposted to all three lists. The reasoning was that this way people wouldn't have to subcsribe to LAA if they were already on LAD+LAU. Now when you look at LAA archives, some people post only to LAA, some (like me) to all three lists, and some to either LAA+LAD or LAA+LAU. My suggestion is that we drop this policy altogether: announcements should be sent to LAA and optionally to LAD and/or LAU. At least I've always had the nasty feeling that I'm spamming LAD+LAU with my Ecasound release announcements. Of course, when announcing conferences, major new versions (JACK-1.0.0 maybe? :)), etc, I see no harm in cross-posting to all the three lists. So in other words, if you really want to see _all_ the announcements, you should subcsribe to LAA. Any comments? If no objections, at least I will from now on send non-major release announcements only to LAA. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] JAAA Bandw parameter
Thanks! I'll try to say the same from user point of view :-) So, if I understand well, gray drawing is some kind of noise filtering which is possible when analysis takes place some period of time. In othe words, a card SNR is blue, as our ears do not integrate a sound during such long period of time. But for more o less constant noise spectrum (which is true for any card), noise integration alow us to expand measurement range (about 20db in my case) - gray spectrum. Andrew === On Sunday 12 December 2004 13:20, Fons Adriaensen wrote: === On Sun, Dec 12, 2004 at 06:54:46AM +0300, Andrew Gaydenko wrote: 1. Can anybody explain me (I think, Fons Adriaensen can :-) the JAAA Bandw parameter meaning? The bandwidth determines how much detail you see on the frequency scale. If you have a small bandwidth, you will be able to separate two signals that are very close together in frequency, while for a larger bandwidth they will merge into a single peak. So why not use a very small bandwidth all the time ? The reason is that small bandwidth requires a longer FFT, and you will see less detail in time. So there is a tradeoff to be made between resolution in time and in frequency. 2. When Bandw parameter is rather small, I see two spectrums - main (blue) and, below the first, - the second one (gray). What is the last spectre spectrum meaning? From the README : 'Bandw' sets the FFT length, and hence the bandwidth of the analyser. Depending on this value, the size of the display and the frequency range, you may sometimes see two traces. This happens when the resolution of the analyser is better than the display, so that one pixel contains more than one analyser value. In that case, the blue trace is the peak value over the frequency range represented by each pixel, and the gray one is the average value. The first one is correct for discrete frequencies, and the latter should be used to read noise densities. To see this, switch on both the sine and noise generators, and loop back into JAAA. Set a bandwidth and frequency range that gives you the two separate traces. Now put a peak marker on the tone, and a noise marker somewhere on the noise. You will see that the noise marker is on the gray trace. -- FA
[linux-audio-dev] Re: [linux-audio-user] Re: adm: list archives at eca.cx going away
Hi, a quick update on this issue. On Fri, 29 Oct 2004, Joern Nettingsmeier wrote: Kai Vehmanen wrote: this is not an urgent issue, but I'd like to warn in advance that the laa/lad/lau list archiving at www.eca.cx/la[adu] will stop some time next year. I'm not sure of the exact date, but sooner or later anyway. Note Ok, I've been now testing a new, semi-realtime, mechanism to archive the lists. What's important is that this is something I can support also in the future, so the archiving can continue for all three lists. What I'm missing now is web space. I'd need: * around +0.5G of web space - the LAA/LAD/LAU archives are currently 0.5G, growing by 15M each month - I'll have to move eca.cx to a new server soon and I won't have enough web space on the new server :( * update via rsync-over-ssh - mirroring the whole eca.cx/la[adu] tree * if at all possible, a separate host name like lists.foobar.org - possibility to use google to search the lists (by searching with site:lists.foobar.com keywords) - htdig is a bit painful to maintain, I'd rather use google ... I will build some server-side magic to make redirects from eca.cx/la[adu] to the new archive location so that existing links to the archived mails will continue to work (and not just temporarily). Now if anyone here is willing to donate some webspace for this purpose (only the list archives, nothing else), please contact me privately. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] announce-list policy
hi *, On Sun, Dec 12, 2004 at 01:58:08PM +0200, Kai Vehmanen wrote: My suggestion is that we drop this policy altogether: announcements should be sent to LAA and optionally to LAD and/or LAU. At least I've always had totally agreed. being subscribed to another mailing list does not harm as long as the policy is clear and respected by everybody. i'd vote for an announce-only list and very few major announcements on LAD and LAU as well. i am currently not subscribed to LAU, but when i used to, the announcement crosspostings between LAD and LAU were already much more tedious than a single announce list would have been. bests, martin
[linux-audio-dev] Re: announce-list policy
Kai Vehmanen [EMAIL PROTECTED] writes: My suggestion is that we drop this policy altogether: announcements should be sent to LAA and optionally to LAD and/or LAU. At least I've always had the nasty feeling that I'm spamming LAD+LAU with my Ecasound release announcements. Of course, when announcing conferences, major new versions (JACK-1.0.0 maybe? :)), etc, I see no harm in cross-posting to all the three lists. So in other words, if you really want to see _all_ the announcements, you should subcsribe to LAA. Any comments? If no objections, at least I will from now on send non-major release announcements only to LAA. why not subscribe LAD and LAU to LAA? then policy will be enforced automagically, no? -- Artem Baguinski: http://www.artm.org/ V2_Lab: http://lab.v2.nl/ V2_ Organisation for the Unstable Media: http://www.v2.nl/
Re: [linux-audio-dev] JAAA Bandw parameter
On Sun, Dec 12, 2004 at 03:04:31PM +0300, Andrew Gaydenko wrote: So, if I understand well, gray drawing is some kind of noise filtering which is possible when analysis takes place some period of time. In othe words, a card SNR is blue, as our ears do not integrate a sound during such long period of time. But for more o less constant noise spectrum (which is true for any card), noise integration alow us to expand measurement range (about 20db in my case) - gray spectrum. No, this is not correct. The difference between the two traces has nothing to do with averaging over time. There is nothing magical about it - it's just an artefact of the limitied display resolution. In case the combination of bandwidth, display range and display size is such that there is more than one measurement per displayed pixel, the blue trace is the maximum over the frequency range represented by a pixel, and the gray one is the average over the same range. An example should make this clear. Suppose the sample frequency is 48 kHz, and the FFT length is 4096. The FFT will give a measurement every 48000 / 4096 = 11.72 Hz. JAAA interpolates the spectrum at half the FFT step, so we really have a measurement every 11.72 / 2 = 5.86 Hz. If we display the full range of 0..24 kHz, and the picture is 500 pixels wide, then each pixel represents 24000 / 500 = 48 Hz. So there are 48 / 5.86 = 8.2 measurements per pixel. In this case each pixel will represent 8 or 9 measurements. The blue line shows the maximum of these 8 or 9 values, and the gray trace the average. The two traces are displayed because you need them both, depending on what you want to measure. An analog spectrum analyser would show a wide band, with the average somewhere near the middle. This can be done as well, but the current method provides a more accurate display. The Video Average function (VidAv) does averaging over time. This reduces the variation for noise signals, so they can be read and measured more accurately. The reduced variation also means that peak and average value will come closer, as you can see on the traces. To measure the SNR of your card: - Disconnect all input signals. - Set the display range so you can see the noise. This spectrum should be flat, except at the lowest frequencies. - Switch on the VidAv function and put a noise marker in the flat part of the spectrum. - Read the noise density value, No, in the upper left corner. Now compute -(No + 10 * log10 (Fsample / 2)), this is the SNR. Example: you read No = -130 dB/Hz, and the sample frequency is 48 kHz. 10 * log10 (24 kHz) = 43.8 dBHz, so the SNR is -(-130 + 43.8) = 86.2 dB. This assumes the noise spectrum is flat. If it isn't you need to integrate No over the frequency range. Future versions of JAAA will probably contain a function to do this, together with A-weigthing. -- FA
Re: [linux-audio-user] Re: [linux-audio-dev] announce-list policy
On Sun, Dec 12, 2004 at 02:08:58PM +0100, Robert Jonsson wrote: Currently there are 924 subscribers to LAU, 806 to LAD but only 355 to the announce list. First, I believe most announcements deserve a larger audience i just subscribed to laa in order to benefit from the new policy :-) the reason why i wasn't subscribed to laa until now is the old policy (everything should get announced at lad/lau as well). the only possibility to avoid massive crosspostings is to not subscribe to laa. may be this applies not just to me. bests, martin
Re: [linux-audio-dev] JAAA Bandw parameter
Probably, the last questions today :-) 1. What is the meaning of the 10 * log10 (Fsample / 2) part? 2. When noise spectrum is approximately flat - is there a common correlation with A-weighted value (say, about 10db)? Andrew === On Sunday 12 December 2004 17:05, Fons Adriaensen wrote: === On Sun, Dec 12, 2004 at 03:04:31PM +0300, Andrew Gaydenko wrote: In othe words, a card SNR is blue, as our ears do not integrate a sound during such long period of time. But for more o less constant noise spectrum (which is true for any card), noise integration alow us to expand measurement range (about 20db in my case) - gray spectrum. ... To measure the SNR of your card: - Disconnect all input signals. - Set the display range so you can see the noise. This spectrum should be flat, except at the lowest frequencies. - Switch on the VidAv function and put a noise marker in the flat part of the spectrum. - Read the noise density value, No, in the upper left corner. Now compute -(No + 10 * log10 (Fsample / 2)), this is the SNR. Example: you read No = -130 dB/Hz, and the sample frequency is 48 kHz. 10 * log10 (24 kHz) = 43.8 dBHz, so the SNR is -(-130 + 43.8) = 86.2 dB. This assumes the noise spectrum is flat. If it isn't you need to integrate No over the frequency range. Future versions of JAAA will probably contain a function to do this, together with A-weigthing. -- FA
Re: [linux-audio-dev] JAAA Bandw parameter
On Sun, Dec 12, 2004 at 09:03:32PM +0300, Andrew Gaydenko wrote: Probably, the last questions today :-) 1. What is the meaning of the 10 * log10 (Fsample / 2) part? It's just the frequency range expressed in dB. No = noise density = power per Hertz. No * frequency_range = noise_power. In dB, the multiply becomes an addition. And since the maximum signal level is O dB, SNR = -noise_power. 2. When noise spectrum is approximately flat - is there a common correlation with A-weighted value (say, about 10db)? I have no exact value at hand, but yes, it will be something like 10 dB. Most manufacturers of sound cards give the A-weighted figure (if anything at all) -- it looks better :-) -- FA
Re: [linux-audio-dev] JAAA Bandw parameter
Thanks for all today lessons! Andrew === On Monday 13 December 2004 00:18, Fons Adriaensen wrote: === On Sun, Dec 12, 2004 at 09:03:32PM +0300, Andrew Gaydenko wrote: Probably, the last questions today :-) 1. What is the meaning of the 10 * log10 (Fsample / 2) part? It's just the frequency range expressed in dB. No = noise density = power per Hertz. No * frequency_range = noise_power. In dB, the multiply becomes an addition. And since the maximum signal level is O dB, SNR = -noise_power. 2. When noise spectrum is approximately flat - is there a common correlation with A-weighted value (say, about 10db)? I have no exact value at hand, but yes, it will be something like 10 dB. Most manufacturers of sound cards give the A-weighted figure (if anything at all) -- it looks better :-) -- FA
[linux-audio-dev] rosegarden, alsa_seq and usx2y rawusb
Hello, have now figured out how to drive my audio and midi with tascam us-122 on SuSE 9.2 -- and (after disabling all tv thingies) it works very reliable and with very few xruns. The following software seems to be involved: - linux-2.6.8-24.3 (SuSE Standard kernel -- heavily patched) patched with linux-2.6.8-24-usx2y-0.8.6.patch from rncbc (CONFIG_HPET_RTC_IRQ=n) - realtime-lsm-0.8.5 - ruis jack jack-0.99.21.1usx2y-17.suse92 - qjackctl-0.2.13-1 - rosegarden4-0.9.9-2 - ZynAddSubFX-1.4.3-141 With this configuration I have found a weird problem: When starting jack with driver 'alsa' (from qjackctl) I am able to play my alsa instruments (for example ZynAddSubFX) from within rosegarden: - start ZynAddSubFX - start rosegarden - choose ZynAddSubFX for the active track - play the keyboard an listen to nice ZynAddSubFX sounds ... But when starting jack with driver 'usx2y' the midi seems not to arrive at ZynAddSubFX (or Hydrogen or fluidsynth or ...) Even ASeqView doesn't show any incoming events if chosen as instrument in rosegarden. Restarting jack with driver alsa -- and all went well ... What is the problem? And what can I do to help with this problem? Are there any missing facts? Yours Uwe Koloska
Re: [linux-audio-dev] aubio - library for audio labelling
Hi all, On Sun, Dec 12, 2004 at 11:24:27AM +0100, jaromil wrote: http://aubio.piem.org Thanks for the forward Jaromil, and to Jan for his blog entry. i think that Paul Brossier is not in this list... i am but i should read it at a higher pace :) aubio is still in a proof of concept state, comments much appreciated. ciao, paul
Re: [linux-audio-dev] Patents on some Linux OS code
On Thu, Dec 09, 2004 at 05:39:50PM +1100, Erik de Castro Lopo wrote: Look, the patenting of stupid things is to be encouraged as strongly as possible. The US (and other) patent systems will soon colapse under their own weight and then be discarded. Apart from encouraging stupid patents, the best thing you can do is ignore it completely. When and if you get a cease and desist letter you do the following: 0) Get the patent holder to provide enough information for you to figure out if you might infinge or not. 1) If you are out of jurisdiction you may want to disregard the patent anyway. 2) Get the patent documents and see if the patent can be challenged. 3) If you think it can be challenged, state so publicly in the web page for the software and tell the patent holder that you will challenge the patent validity if they try to bring it to court. 4) If it can't be overturned, say sorry to the patent holder and pull the software for the 2-3 weeks it takes to reimplement the code working around the patent. i like this approach, especially the 'encouraging stupid ones'. a few weeks ago, i looked at Yin, an f0 estimation algorithm. i wrote to the author to know if it was ok to release it under the GPL. he replied 'the algorithm is patented but i think there should be no problem'. i am not qualified to judge on point 2, but i seriously doubt on its validity, besides we do not have software patents in Europe. and i went to point 3 (updated): http://aubio.piem.org/news/YIN_patented_and_GPL.html now i wonder when someone will get a patent on making additions. bye, paul
Re: [linux-audio-user] Re: [linux-audio-dev] announce-list policy
Hi, I have mixed feelings about this. It sounds like the right thing to do having a specific announce list and the crossposting can be a bit tideous at times... But, looking at the current statistics of the mailinglists makes me feel this policy won't work. Currently there are 924 subscribers to LAU, 806 to LAD but only 355 to the announce list. First, I believe most announcements deserve a larger audience than that. Secondly, I'd think that pretty much everybody subscribed to LAU would be interested. So, what to do, should we force subscribe everybody on the LAU list to the announce list? It's possible but possibly it would offend someone. It would be interesting to know if there are people on the announce list that are not subscribed to either LAD or LAU? If that is the case the announce list does serve a purpose (it also means that even more people on LAU/LAD do not subscribe to it). If the announce subscribers also subscribe to either LAU or LAD I think it would be best to drop the announce list all together, then it does not work as I think it was intended. My 2 cents. /Robert söndagen den 12 december 2004 13.45 skrev martin rumori: hi *, On Sun, Dec 12, 2004 at 01:58:08PM +0200, Kai Vehmanen wrote: My suggestion is that we drop this policy altogether: announcements should be sent to LAA and optionally to LAD and/or LAU. At least I've always had totally agreed. being subscribed to another mailing list does not harm as long as the policy is clear and respected by everybody. i'd vote for an announce-only list and very few major announcements on LAD and LAU as well. i am currently not subscribed to LAU, but when i used to, the announcement crosspostings between LAD and LAU were already much more tedious than a single announce list would have been. bests, martin -- http://spamatica.se/music/
Re: [linux-audio-user] Re: [linux-audio-dev] announce-list policy
On Sun, Dec 12, 2004 at 04:10:00PM +0100, martin rumori wrote: On Sun, Dec 12, 2004 at 02:08:58PM +0100, Robert Jonsson wrote: Currently there are 924 subscribers to LAU, 806 to LAD but only 355 to the announce list. First, I believe most announcements deserve a larger audience i just subscribed to laa in order to benefit from the new policy :-) i agree this is the best thing to do: announcing the new policy to lau and ask the suscribers to suscribe laa should do the trick. 'auto'-subscribing could well make some run away. ciao, paul
