Hi all,
I am using the latest 2.6.7 kernel (tried also 2.6.5) but with hdsp I cannot select anything lower than 1024x2 buffer settings in jackd without having massive xruns.
Asoundrc is fine, modprobe.conf is fine too.
The hdsp runs fine with the aforementioned settings but anything lower simply is horrible.
The kernel is patched with all kinds of mm patches but I am not currently using -r option nor the realtime module (a bit scared of freezing my machine :-). Is this the best one can do in user-space?
Any help is greatly appreciated!
Best wishes,
Ico
I thought it might worth mentioning 2 days of intense LAD-friendly
talks at the Libre Software Meeting on July 7th and 8th. The program
will include:
Dave Phillips on "The Scene"
Yann Orlarey on Faust
Takashi Iwai on ALSA
Steve Harris on RDF & Audio
Julien Villain on Gestural/Listening training
Paul Davis on Ardour (talk + 2hr workshop)
Julien Ottavi on APODIO
Damien Cirotteau on AGNULA
If you're in the Southwest corner of France and want to come and fill
the rooms just a little more, not to mention sample of the "young
upstart" red and white wines of the region (quite a political battle
in the region, apparently), check with lsm2004.abul.org. A glass of
decent wine will be considered partial downpayment on your copy of the
Ardour manual :)
--p
Hi everyone,
It's been a while, although this time there's not much. Just minor fixes,
nothing very outstanding. However here it is, a new public release for
QjackCtl, the little Qt (cutie:) application to control the JACK sound
server daemon, specific for the Linux Audio Desktop infrastructure.
Check it out from the usual place:
http://qjackctl.sourceforge.net
>From the changelog:
- Patchbay socket dialog client and plug list option items are now
properly escaped as regular expressions.
- JACK callbacks are now internally mapped to QCustomeEvent's instead
of using the traditional pipe notifications.
- The system tray popup menu is now featured as a context menu on the
main application window too.
- The reset status option is now included in the system tray popup menu.
- Server stop command button now enabled during client startup interval;
this makes it possible to stop the server just in case the client
can't be activated for any reason.
- Top level sub-windows are now always raised and set with active focus
when shown to visibility.
Hope you enjoy.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Hi all,
People who play around with floating point code (especially on x86)
quickly learn about the evils of comparing the equality of one floating
point value with another.
There are other related evils with floating point one of which I was
bitten by just recently and I thought I'd share it with y'all. If it
helps just one person from spending 20 odd hours chasing an elusive
bug like I did, I will have acheived something.
The evil I speak of is the difference between 32 and 64 bit floating
point representations (types float and double) and the x86 CPU's
internal 80 bit representation.
The most common trap is something like:
if (x == y)
do_something ();
where x and y are say double flotaing point numbers. Also lets just say
that the value of x is already in the CPU's FPU register as a result of
a previous operation and the other y, is not. What happens is that the
result of the previous operation can have a full 80 bits (part mantissa,
part exponent and a sign bit) of precision while y, loaded from memory
does not have this extra precision. The comparison therefore fails, even
though when printed out (or when compiler optimisation is switched off)
the two values are equal. This is the reason why the above if statement
is better written as:
if (fabs (x - y) < 1e-20)
do_something ();
The reason I am writing this email is that I was recently bitten by a
similar problem. I was keeping a running index into a table, and keeping
the integer part separate from the fractional part which was kept in a
double floating point:
double fractional = 0.0, increment = 0.1;
int integer = 0;
for (;;)
{
/* Bunch of other code. */
fractional += increment ;
integer += lrint (floor (fractional));
fractional -= floor (fractional);
}
The above code can produce very odd results for certain values of
increment. The problem in this case manifested itself in the
integer/fractional losing counts when compiled with gcc-3.4 while
the same code had worked perfectly with previous versions of the
compiler. The problem seems to be caused by the fact that the other
code in the loop was pushing at least some of the relevant values
out of the FPU stack into double floating point variables and that
when they were reloaded they had lost precision.
The fix in this case was this:
for (;;)
{
/* Bunch of other code. */
fractional += increment ;
rem = fmod (fractional, 1.0); /* floating point modulus */
integer += lrint (round (fractional - rem));
fractional = rem;
}
which is far more robust.
HTH,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The X-files is too optimistic. The truth is not out there."
-- Anthony Ord
>
> From: Takashi Iwai <tiwai(a)suse.de>
> Date: 2004/07/02 Fri PM 01:15:46 GMT
> To: <ico(a)fuse.net>
> CC: <alsa-devel(a)lists.sourceforge.net>,
> <linux-audio-dev(a)music.columbia.edu>
> Subject: Re: [Alsa-devel] Re: [linux-audio-dev] snd-hdsp oddities
>
> At Fri, 2 Jul 2004 12:56:06 +0000,
> <ico(a)fuse.net> wrote:
> >
> > > Shouting "DON'T USE 2.6" isn't a good solution. Though, we need to
> > > inform to "set LD_ASSUME_KERNEL as a workaround"...
> >
> > Pardon my ignorance but how does one do this? As a part of the
> > config before compiling kernel or?
>
> No, just set the environment variable like
> export LD_ASSUME_KERNEL=2.4.19
> (better globally) and start jack. That's all.
>
> In this way, glibc chooses LinuxThreads instead of NPTL.
>
> > Also, any ideas on the odd behavior of the hdspmixer? (see my other post)
>
> Not checked yet... Did hdspmixer work on any versions correctly on
> your system?
>
Well not really since this notebook is only a couple months old so I never had the chance to test anything pre 1.0.2. But anything 1.0.2 and greater behaves the same.
Ico
> Shouting "DON'T USE 2.6" isn't a good solution. Though, we need to
> inform to "set LD_ASSUME_KERNEL as a workaround"...
Pardon my ignorance but how does one do this? As a part of the config before compiling kernel or?
Also, any ideas on the odd behavior of the hdspmixer? (see my other post)
Ico
Hi,
A friend of mine owns a Roland vs-1680 harddiskrecorder. It has a
feature that allows for recording and playing back a midi clock signal
alongside the audio tracks. This makes it possible to create a tempo
map with a (hardware) sequencer, record it on the vs-1680, and use it
to keep the sequencer in sync with subsequently recorded audio tracks .
We work together on a project, and i would like to be able to record
and play back the audio mix from the vs-1680 to my computer together
with the midi clock data (he takes his machine home to work on the
audio part). That way i can work on the sequences on my mpc1000, and
play back the audio whith the sequences synced midi clock slave.
I believe there is currently no linux app that can do that, so i am
considering to try to create a utility for it. But i have little
programming experience and none regarding alsa and jack, so i would
like feedback on my ideas.
My plan is to write a little program that opens 2 midi ports (in and
out) and 2 jack ports (in and out). The program wil monitor the midi
input port for midi clock messages. It will write zero's to the jack
output port but when it recieves a midi clock message it will write a
value of 1 to the jack port. This way i can store the midi clock
signal in a audio file, for example with ecasound. I know, this is
ugly! For playback i would have the program monitor the jack input port and
output a midi clock message when a sample value of 1 passes by.
I hope this explains my plan clear enough. I have looked at the
example programs for alsa and jack and to me it looks like i could
copy and paste something together, that could be my lack of
experience. What do you think? Is this possebly going to work or do i
overlook major difficulties?
Any advice would be very welcome!
--
Greetings, Gerrit
Hi all!
I've been messing with hdsp (again :-) and found out that my hdspmixer has very oddly behaving sound meters. While the input (2nd row) appears to be more or less ok (the yellow peak things kind of fly all over the place and often drop off below green lines or even completely dissapear), the analog outputs as well as combined monitoring output (front 1/4" phono jack on the multiface) only occassionally spike with a line input (usually only one channel). I am wondering why this is so since the audio is definitely working ok, but the monitoring of the outputs simply isn't working (at least not visually).
I am using Mdk10.0 community with lots of updates.
Alsa 1.0.4rc2 as well as 1.0.5 (libs are from 1.0.4rc2 at this point).
Could this be the version of fltk I am using or something more serious?
I am using 2.6.5 and 2.6.7 kernels.
Any help is greatly appreciated!
Best wishes,
Ico
Hi everyone,
How should I perform resampling at runtime ? Like : I load samples with
different bitrates, then JACK calls my process() callback function using
its own bitrate... If the JACK bitrate and the sample one match, there's
nothing to do, but if they differ, there's a need for resampling.
Do you have an example algorithm, or some pointers, like some app that
does this in a nice manner ?
Thanks.
--
Olivier