Hi,
GNUsound 0.7.2 was released. This release fixes a few naggling issues
and incorporates support for the gmerlin avdecoder, which provides the
ability to load .AAC and Musepack formats (among many others).
Changes from 0.7.1:
Fixed undo issues with Mix Tool, Move Tool, Pencil Tool.
Fixed ILLEGAL_MID_SIDE_FORCE error when saving a FLAC file at
compression level 4.
Fixed a few make/autoconf snags (Jens Koerber)
Added support for gmerlin avdecoder (Burkhard Plaum)
Updated config.sub/config.guess.
GNUsound 0.7.2 is available here:
ftp://ftp.gnu.org/gnu/gnusound/gnusound-0.7.2.tar.bz2
The GNUsound homepage:
http://www.gnu.org/software/gnusound
Thanks,
Pascal.
Hi,
QjackCtl 0.2.17 update release is out.
Directly from the change log:
- Systemic I/O Latency settings are now featured for the alsa, oss and
coreaudio backends, letting you specify the known latency of external
hardware for client aware compensation purposes (thanks to Wolfgang Woehl,
for the reminder).
- Update on last backstage changes to the coreaudio backend options (due
to Stéphane Letz. Thanks).
As always, you can grab the source tarball from the usual place:
http://qjackctl.sourceforge.net/http://sourceforge.net/projects/qjackctl
Enjoy!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Hi there.
>Actually a correct explanation isn't that simple. Yours is much
>_too_ simple. Theoretically a 20 kHz bandlimited signal can be
>represented _exactly_ as a 40 kHz PCM stream. In order to not
>have to use a very steep lowpass filter in the DAC it is better
>to use a somewhat higher sampling frequency. 48 kHz should be
>enough most of the time.
No. Nyquist frequency allow original _sampled_ signal to be
fully reconstructed using a IDFT. It does not mean that the
reconstructed signal will have anything more than the original
samples.
If you sample an incoming analog signal at 2 samples per second
(sps), you'll definitely not be able to reconstruct ALL the
phases and ALL the frequencies between 0 and 1 Hz. You'll get,
however, a correct reconstruction of a periodic signal if it
lasts long enough. This is due to the inherent impossibility,
using a DFT, to get both accurate space and time resolutions
at the same time.
Just try this "simple" experience: sample a 1 Hz pulse that
is triggered after a random non-quantized delay that is less
than four seconds. Sample it at a rate of 2 sps and then,
try to get the original signal back with all its components
(phase and frequency). Good luck.
This is just as impossible as saying that you can compress the
information stored in any analog signal in a finite number
of samples.
Mickael Vardo
Modulating "Magic" Numbers.
----------------------------
Given two instances of the rude pseudo sine fuction S:
#define S(n)(((n)*((n)^0x8000))>>13)^(((short)((n)^0x8000))>>15)
.. and offset them some 60 degrees with the "magic number" 0x14D4, then
they will partially cancel each other out to get you something that
*looks* like a sine wawe (but actually still have lots of harmonics.)
Now, what then if one was to change the offset, I thought. That should
result in different blends of harmonics, right?
So I made this new tiny button between the waweform selector and the
detune slider. Activating this button will do the following:
Frequency offset (detune) will detune the two instances against each
other.
Phase parameters will change, not only the phase relative to the other
oscillators, but also the offset between the two instances of S().
I've set up oscillator one in patch H3 ready for experimentation. Forgot
to change the name though, so the title "op 1 on quack" is a reference
to the sound in H2, which is actually pretty amusing ... but only If you
are five years old! :D
Old and deaf R&R farts will probably prefer the "fat boy" in E8.
However, the implication is that I from this week can offer you two
oscillators for the price of one only.
Get'em from:
http://mx44.linux.dk
mvh // Jens M Andreasen
Hi, Anyone knows how can I use callback builtin functions to
operations like capture, playback and events using ALSA API?
For a while I'd implemented calls to callback functions in each return
of 'writei' and 'readi'.
Thank you.
Hi,
Why not solve this kinds of problems.
Soulutions:
1) Remove OSS drivers from kernel - then all problems will be alsa
problems.
2) Remove OSS emulation from alsa - then all problems will be OSS
problems.
Otherways this will be newer end.
Peter Zubaj
___________________________________________________________________________
Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete.
http://www.wanda.sk/
by Kjetil Svalastog Matheussen <k.s.matheussen@notam02.no>
Erik de Castro Lopo:
>
> Kjetil Svalastog Matheussen wrote:
>
>> I was primarily testing speed, but both libraries where using the sinc
>> routine, so...
>
> Yes, but you can design a sinc filter with 10 coefficients and one
> with 10000. The one with 10000 coefficients will have a steeper
> transition band and a better signal to noise ratio.
>
Yes. But back to the point, I think there is an extremely good chance that
mus_src (even by setting the width-argument to 5 (default value is 10
which is also faster than SRC_SINC_FASTEST)) will sound better than whats
being produced by a linear resampler, and might be exactly be what the
person asking the question is looking for.
Lee Revell wrote:
> On Fri, 2005-06-10 at 11:12 -0700, Ian wrote:
> > Can anyone tell me *very briefly* what is the current
> > state of play regarding realtime-lsm in the 2.6.*
> > kernels and whether this feature (or something like it
> > ) is likely to be introduced into the kernel anytime
> > soon.
>
> realtime-lsm should be considered deprecated. The solution accepted by
> Linus is rlimit based. I think this will be in 2.6.12 (seems to be in
> the release candidates). Check the archives for "rlimit".
>
> This will require patching PAM and bash.
In the interim you could try set_rtlimit:
http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz
It allows you to access the enhanced rlimits (ie: RT scheduling and nice
levels) under 2.6.12 kernel or later without needing to patch anything. In
fact, even once PAM/etc are patched this might be preferred by some since it
allows you to control the limits based on the program being run; so for
example you can allow /usr/local/bin/ardour to run at realtime priority 50
while /usr/bin/yes (for example) can't.
Regards
jonathan
Erik de Castro Lopo:
> >
> > I recently did a lot of benchmarking between libsamplerate and mus_src
> > in clm/sndlib. My result was quite interesting, the fastest mus_src sinc
> > resampler where a lot faster than the fastest libsamplerate resampler.
>
> I think most people would agree that speed is not the most important
> aspect when measuring the quality of a sample rate converter.
>
I was primarily testing speed, but both libraries where using the sinc
routine, so...
> With libsamplerate, I can state that the three sinc based converters
> have the following characteristics:
>
> SNR Bandwidth
> SRC_SINC_FASTEST 102.42 dB 80.23 %
> SRC_SINC_MEDIUM_QUALITY 98.99 dB 90.68 %
> SRC_SINC_BEST_QUALITY 97.43 dB 96.96%
>
> where SNR is signal to noise ratio and Bandwidth its a percentage of
> the theoretical best bandwidth (ie half of the minimum of the source
> and desination sample rate).
>
> > A third program is the original sinc-resampler from Julius Smith:
> > http://ccrma-www.stanford.edu/~jos/resample/
> > I don't know how this one performs compaired to the other two though.
>
> libsamplerate the same algorithm as this one. I think Julius O. Smith
> developed this algorithm.
>
He did, and Bil Schottstaedt used this algorithm as well for mus_src.
When I compaired mus_src with width=5, and libsamplerate with
SRC_SINC_FASTEST, the first one is much faster, I don't know what kind of
SNR/Bandwidth you get with your way of measuring when using mus_src with
width=5, but the source is easy to read so I guess you can figure it out.
--