-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi all,
(apologies if this is the wrong mailing list, but i'm currently only
subscribed to LAD and not LAU. anyhow:)
i'm having serious troubles using zita-ajbridge with alsa loopback
devices.
my basic requirement is, to allow *any* ALSA-only application to be
"jackified".
i'm on debian, and my current tests are done on i386 resp. x86_64, but
my target platform is armel (wandboard solo, powered by a single-core
ARM cortex-A9)
the basic problem i'm facing is, that i don't get much output.
occasionally i do get output (e.g. with mplayer)
so here's what i did:
# modprobe snd-aloop (with all the default parameters)
which gives me:
$ cat /proc/asound/cards
0 [Generic ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xf0244000 irq 43
1 [SB ]: HDA-Intel - HDA ATI SB
HDA ATI SB at 0xf0240000 irq 16
2 [Loopback ]: Loopback - Loopback
Loopback 1
$ zita-a2j -v -d hw:Loopback,0 -L
playback : not enabled
capture :
nchan : 2
fsamp : 48000
fsize : 256
nfrag : 2
format : S16_LE
Starting synchronisation.
0.460 0.999864
[...]
on another terminal i do:
$ mplayer -ao alsa:device=hw=Loopback.1 STE48.wav
and after connecting zita-a2j to my system's output, i can hear sound.
cool!
ok, so i stop mplayer, and start some other application e.g. Pd (what
else). hooking it up to the loopback device, i start my testpatch:
silence :-(
ok, so mabye Pd is broken, i try some zita app, e.g. zita_delay (from
libzita-alsa-pcmi)
$ alsa_delay hw:Loopback,0 hw:Loopback,0 48000 1024 2
playback :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
capture :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
synced
Signal below threshold...
Signal below threshold...
[...]
not very surprisingly, it doesn't detect any input signal (zita-j2a is
not running), but i also don't hear any output signal.
hmm.
stopping jack (which quits zita-a2j), i try a alsa_delay on my soundcard:
$ alsa_delay hw:SB,0 hw:SB,0 48000 1024 2
playback :
nchan : 2
fsamp : 48000
fsize : 1024
nfrag : 2
format : S32_LE
capture :
nchan : 2
fsamp : 48000
fsize : 1024
nfrag : 2
format : S32_LE
synced
2176.341 frames 45.340 ms ??
2176.405 frames 45.342 ms ??
and i hear nice sine-tones.
checking the output of alsa_delay vs that of zita-a2j, i notice that
one uses latter S32_LE whereas the former uses FLOAT_LE.
since i cannot change the format of alsa_delay without recompilation,
i try to match the two formats with zita-a2j, by running:
$ zita-a2j -v -d hw:Loopback,0 -p 1024
$ zita-a2j -v -d hw:Loopback,0 -p 1024
playback : not enabled
capture :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
Starting synchronisation.
3.716 0.999042
2.713 0.998499
[...]
which gives me pretty much the same config as is used with alsa_delay.
re-starting `alsa_delay`: still no sound.
just in case: starting zita-j2a as well:
$ zita-j2a -v -d hw:Loopback,0 -p 1024
playback :
nchan : 32
fsamp : 48000
fsize : 1024
nfrag : 2
format : FLOAT_LE
capture : not enabled
Starting synchronisation.
-2.919 1.000933
-1.457 1.001286
[...]
and making sure that zita-*2* are jack-connected to system, but still
no luck.
hmm, what is going on here?
currently the *only* application that i can convince to use
zita-ajbridge seems to be mplayer, and only in S16_LE mode.
what are the requirements for an application to use zita-ajbridge?
shouldn't other zita applications (like alsa_delay) automagically
fullfill these requirements through libzita-alsa-pcmi?
do my application either have to support FLOAT_LE or be stuck with
S16_LE/2channels forever?
is there a tutorial out there on how to use zita-ajbridge with snd-aloop?
masdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlHeuicACgkQkX2Xpv6ydvRT+ACcC0ZW07gHvW6ub3HXhWG8sXR8
TYcAn1SALKnlTeFYJmtPz8gkvpX+aLNB
=BuNd
-----END PGP SIGNATURE-----
Hello everyone!
I was wondering, is there a direct way to do a transport locate in sync with
klick? Or can one at least tell klick to relocate to 0, so that the metronome
is back in line with everything else. I've tried this:
tty1> klick -i -t # interactive and JACK transport aware
tty2> ecasound -i null -o jack_alsa -G:jack,eca,sendrecv # Transport master
Klick reacts to start and stop. But it doesn't react at all to a setpos 0
(relocate to 0) in Ecasound.
Warm regards
Julien
----------------------------------------
http://juliencoder.de/nama/music.html
Hello all,
I'm trying to add Alsa support to an application with mixed results.
When using the default audio output it sounds fine (my dac display 48KHz
as sampling rate, which doesn't equal the source signal of 44.1) but
when using hw:0 it is heavily distorted and with plughw:0 the sound
stutters at a steady interval of about 2Hz (in these last two cases my
dac display 44.1kHz as the sampling rate). When using libao plughw:0
sound fine (and my dac always display 44.1kHz).
Can anyone give me a direction (or answer) where I might go wrong here.
Unfortunately I'm a bit out of my league here and I do not yet
understand the data that fills buf[]. However, I do know that the data
it supplies works fine with libao, so I do suspect it is something with
the code below.
Thanks in advance, Maarten
ps. it is supposed to add Alsa to the following:
https://github.com/abrasive/shairport/tree/1.0-dev
static void start(int sample_rate) {
if (sample_rate != 44100)
die("Unexpected sample rate!");
int ret, dir = 0;
snd_pcm_uframes_t frames = 32;
ret = snd_pcm_open(&alsa_handle, alsa_out_dev,
SND_PCM_STREAM_PLAYBACK, 0);
if (ret < 0)
die("Alsa initialization failed: unable to open pcm device:
%s\n", snd_strerror(ret));
snd_pcm_hw_params_alloca(&alsa_params);
snd_pcm_hw_params_any(alsa_handle, alsa_params);
snd_pcm_hw_params_set_access(alsa_handle, alsa_params,
SND_PCM_ACCESS_RW_INTERLEAVED);
snd_pcm_hw_params_set_format(alsa_handle, alsa_params,
SND_PCM_FORMAT_S16);
snd_pcm_hw_params_set_channels(alsa_handle, alsa_params, 2);
snd_pcm_hw_params_set_rate_near(alsa_handle, alsa_params, (unsigned
int *)&sample_rate, &dir);
snd_pcm_hw_params_set_period_size_near(alsa_handle, alsa_params,
&frames, &dir);
ret = snd_pcm_hw_params(alsa_handle, alsa_params);
if (ret < 0)
die("unable to set hw parameters: %s\n", snd_strerror(ret));
}
static void play(short buf[], int samples) {
int err = snd_pcm_writei(alsa_handle, (char*)buf, samples);
if (err < 0)
err = snd_pcm_recover(alsa_handle, err, 0);
if (err < 0)
die("Failed to write to PCM device: %s\n", snd_strerror(err));
}
Hi all,
I'm working on a wavetable oscillator class, and I'm wondering about how to
best go about bandlimiting. I see two ways to achieve bandlimiting, i'll
detail as A and B.
A) Create different wavetables for each octave. Base octave includes all
harmonics. Octave 1 has the top half of the harmonics removed by FFT. Oct 2
has the harmonic content halved again.
B) Oversample the single waveform x8. Play the oversampled audio back, and
lowpass with a steep rolloff just below the nyquist of the output
samplerate. Removal of the otherwise aliasing harmonics is done at the
higher samplerate, so its not aliased yet at that stage.
I'm asking in terms of quality and CPU usage: this is for a synth which has
3 oscillators per voice, and 16 / 32 voices..
Cheers, -Harry
Hey everybody,
Its my pleasure to announce that the next OpenAV Productions LV2 plugin is
finished!
Its called Fabla, and its a performance sampler.
Page: http://openavproductions.com/fabla
Demo reel: https://vimeo.com/70122957
One year from today Fabla will be released, and each donation motivates the
release to be one month earlier. -Harry
PS: The release system is the same as the previous OpenAV release for
Sorcer, details available here: http://openavproductions.com/support
Hello all,
Some maintenance updates are available on
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads>
* libclxclient 3.9.0: bugfixes
* aeolus, aliki, jaaa, japa: all now use zita-alsa-pcmi instead
of clalsadrv.
* The aliki package now includes the manual.
That means that clalsadrv is now deprecated. It will remain available
for a few months and then disappear forever.
Note to AMS devs: zita-alsa-pcmi is a near drop-in replacement
for clalsadrv-2.0.0:
* Change the library name in the build files
* s/#include<clalsadrv>/#include<zita-alsa-pcmi>/
* s/Alsa_driver/Alsa_pcmi/
* s/->stat()/->state()/
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hello all,
The incredible happens.
The electronics of the 'Lampadario' at the Casa del Suono in
Parma consists of a rack with an RME ADI468 converting MADI
to 8 ADAT outputs, 8 Behringer ADA8000 converters, and 8 QSC
amplifiers of 8 channels each. The rack was wired (very neatly)
by a firm specialising in this sort of work.
When I installed the software four years ago, I found out
that 25 of the 64 channels had their phase inverted. For one
of those it was an error in the speaker wiring, which was easy
to correct. The other 24 corresponded exactly to 3 groups of 8,
and the speaker wiring was OK. I assumed that the cables between
the ADA8000 and the amps were to blame - this is a non-standard
cable which had to be hand-made by the whoever did the wiring.
If two technicians had worked on that, they could have had
different ideas of what were the correct connections.
Since I didn't want to take the rack apart, resolder 24 wires
and put it all back, and since there was only one SW app driving
the installation at that time, those 24 inversions were corrected
for by that software. So far so good.
Recently I re-measured the IRs of the whole thing. There
were again 24 channels out of phase. But not the same ones.
One of the groups of 8 had turned in-phase, and another
one was now inverted.
The only thing that has happened to the installation over
the last years is that some of the Behringers failed (power
supply blown up, one per year on average) and were replaced.
So I checked those separately. And yes, some of them had their
output phase inverted w.r.t. the others. Apparently the thing
exists in two versions, but apart from measuring there's no
way to tell which is which. So I'll have to recheck things
each time any of them are replaced again. Thank $GOD we didn't
use those for the WFS system.
The incredible happens.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
I'm listening to music from an AROS virtual machine in VirtualBox. The
audio setup is the following:
AROS -> ALSA (loopback) -> zita-a2j -> JACK
VirtualBox has no direct support for JACK. A bug was opened 3 years
ago asking for jack support https://www.virtualbox.org/ticket/6049
This seam pretty hopeless, unless someone competent enough, which I
am not, contribute with some patch.
However, when listening to music, it works fabulous with my setup.
The main advantage of VirtualBox is that the guest OS is really
installed in a virtual machine, and any software compatible with this
OS can be installed and will run. VirtualBox is also a little bit
faster than wine.
So my question is, are there anyone who tested VirtualBox with windows
and some VST?
Dominique
--
"We have the heroes we deserve."
