Hello,
Does anyone know what sort of timer is used by the ALSA
loop device, and if this can be changed in some way ?
On the system I'm working on now, wakeup times while waiting
for a period to be available (as done by Jack and zita-alsa-pcmi)
seem to be quantised in steps of 3.3ms or so. Which means it
sometimes wakes up 3/4 or more of a period too late. Next one
will be xrun in that case.
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 first official release of zita-ajbridge is now available at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads>.
Quoting the README:
This package provides two applications, zita-a2j and zita-j2a.
They allow to use an ALSA device as a Jack client, to provide
additional capture (a2j) or playback (j2a) channels.
Functionally these are equivalent to the alsa_in and alsa_out
clients that come with Jack, but they provide much better audio
quality. The resampling ratio will typically be stable within
1 PPM and change only very smoothly. Delay will be stable as
well even under worse case conditions, e.g. the Jack client
running near the end of the cycle.
You will also need the latest zita-resampler and zita-alsa-pcmi
libraries.
All feedback welcome.
Ciao,
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Le 19 mars 2012 à 16:25, Nedko Arnaudov a écrit :
> Stéphane Letz <letz(a)grame.fr> writes:
>
>> Le 19 mars 2012 à 16:15, Nedko Arnaudov a écrit :
>>
>>> Stéphane Letz <letz(a)grame.fr> writes:
>>>
>>>> Le 19 mars 2012 à 15:20, Fons Adriaensen a écrit :
>>>>
>>>>> On Mon, Mar 19, 2012 at 01:19:25PM +0100, Stéphane Letz wrote:
>>>>>
>>>>>> I'm wondering how your code could replace the "adapter" mechanism
>>>>>> that I did in JACK2 for that never worked fully
>>>>>> reliably. Basically the "adapter" idea is a bit more general in
>>>>>> the sense that it aims at "adapting" streams in different
>>>>>> context: like network <==> Audio API (CoreAudio for OSX, ALSA for
>>>>>> Linux, PortAudio for Windows...), or several ALSA devices..etc..
>>>>>> (The adapters are also developed as "in server" clients, this
>>>>>> make a bit more easy to add them in a running session using
>>>>>> "ladish" kind of studio management approaches...)
>>> In fact, ladish doesnt manage in-server clients at all. It can only
>>> restore jack settings, and they could include stuff like in-process
>>> clients and slave drivers. jackdbus provides engine parameter for
>>> the latter but doesnt for the former.
>>>
>>> --
>>
>> Well there is a control API to load/unload in-sever client. I was
>> thinking this API could be used with ladish...
>
> ladish could be made to use this API. But it is not the case. At least
> not yet.
>
> --
> Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>
Well this could be interesting to have access to "netjack2" components : netmanager, netadapter, audioadapters....
Stéphane
On Mon, Mar 19, 2012 at 06:58:29PM +0100, Robin Gareus wrote:
> # mplayer -ao alsa,device=hw=1,0 some_music.wav
> # zita-a2j -dhw:1,1
>
> I get endless messages:
> Starting synchronisation.
> Detected excessive timing errors, waiting 15 seconds.
> This may happen with current Jack1 after freewheeling.
(meanwhile I'm back home, the loopback device is hw:3 here)
[terminal 1]
fons@zita1:/audio/audiofiles/tracks> mplayer -ao alsa:device=hw=3.1 diana-krall-almost-blue-44.wav
MPlayer SVN-r34426-4.6.2 (C) 2000-2011 MPlayer Team
181 audio & 384 video codecs
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing diana-krall-almost-blue-44.wav.
Audio only file format detected.
Load subtitles in ./
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 4.0 (04.0) of 244.0 (04:04.0) 0.1%
...
[terminal 2]
fons@zita1:~> zita-a2j -d hw:3,0 -r 44100
Starting synchronisation
/me makes connections in qjackctl and hears lovely piano intro...
So this just works. I do indeed have to start mplayer first, but
only the first time. After that I can stop and restart mplayer
without problem. This is probably some quirk of the loopback
device. There is no such thing as 'requesting exclusive access'
in the ALSA pcm API - it depends only on the device.
> The message is repeated every ~15 sec; and it does not stop.
> Each time a message is printed there's a short very jittery sound (I can
> discern the music) but it remains silent for the remaining time.
The silence is intentional - the app waits for the dust to
settle down after it has detected 'impossible' timing info
from either Jack's DLL or from the one tracking the ALSA device.
There was a bug in the loopback device - it returned the wrong
type of event when using poll() in some cases. It's fixed in
1.0.24. That would certainly explain what you see.
> How do you conduct this test?
>
> I assume that there is no other ALSA-client involved and you use the
> loopback in float/32 mode, w/native samplerate.
Zita-a2j and j2a use libzita-alsa-pmci to access ALSA devices.
It uses exactly the same methods as Jack's backend - very early
versions (libclalsadrv 7 years ago) were in fact a C++ copy
of Jack's backend. That means that whatever works with Jack
will work with zita-a2j and j2a or any of my apps using ALSA.
AFAIK Jack doens't run well with dmix/dsnoop either. And anyway
there's no reason to use them with Jack.
To run the delay test (assuming hw:3 is the loopback device):
[Terminal 1]
zita-a2j -d hw:3,0
[Terminal 2]
zita-j2a -d hw:3,1
[Terminal 3]
jack_delay
and make the required connections.
The off-list reply was a typo - back on LAD now.
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,
A bugfix update of zita-ajbridge is now available at the
usual place.
Thanks to Robin Gareus who discovered the bug: the typical
last-minute-after-testing-added-line-typo. In this case
it meant that both apps would use the lowest resampling
quality in all cases...
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)
Le 19 mars 2012 à 16:15, Nedko Arnaudov a écrit :
> Stéphane Letz <letz(a)grame.fr> writes:
>
>> Le 19 mars 2012 à 15:20, Fons Adriaensen a écrit :
>>
>>> On Mon, Mar 19, 2012 at 01:19:25PM +0100, Stéphane Letz wrote:
>>>
>>>> I'm wondering how your code could replace the "adapter" mechanism
>>>> that I did in JACK2 for that never worked fully reliably. Basically
>>>> the "adapter" idea is a bit more general in the sense that it aims
>>>> at "adapting" streams in different context: like network <==> Audio
>>>> API (CoreAudio for OSX, ALSA for Linux, PortAudio for Windows...),
>>>> or several ALSA devices..etc.. (The adapters are also developed as
>>>> "in server" clients, this make a bit more easy to add them in a
>>>> running session using "ladish" kind of studio management
>>>> approaches...)
>
> In fact, ladish doesnt manage in-server clients at all. It can only
> restore jack settings, and they could include stuff like in-process
> clients and slave drivers. jackdbus provides engine parameter for the
> latter but doesnt for the former.
>
> --
Well there is a control API to load/unload in-sever client. I was thinking this API could be used with ladish...
Stephane
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 18 Mar 2012 21:22:28 +0000
> From: Fons Adriaensen <fons(a)linuxaudio.org>
> Subject: [LAD] First release of zita-ajbridge
> To: Linux Audio Users <linux-audio-user(a)lists.linuxaudio.org>, Linux
> Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
> Message-ID: <20120318212228.GA19153(a)linuxaudio.org>
> Content-Type: text/plain; charset=us-ascii
>
> Hello all,
>
> The first official release of zita-ajbridge is now available at
> <http://kokkinizita.linuxaudio.org/linuxaudio/downloads>.
>
> Quoting the README:
>
> This package provides two applications, zita-a2j and zita-j2a.
> They allow to use an ALSA device as a Jack client, to provide
> additional capture (a2j) or playback (j2a) channels.
> Functionally these are equivalent to the alsa_in and alsa_out
> clients that come with Jack, but they provide much better audio
> quality. The resampling ratio will typically be stable within
> 1 PPM and change only very smoothly. Delay will be stable as
> well even under worse case conditions, e.g. the Jack client
> running near the end of the cycle.
>
> You will also need the latest zita-resampler and zita-alsa-pcmi
> libraries.
>
> All feedback welcome.
>
> Ciao,
>
> --
> FA
Really interesting....
I'm wondering how your code could replace the "adapter" mechanism that I did in JACK2 for that never worked fully reliably. Basically the "adapter" idea is a bit more general in the sense that it aims at "adapting" streams in different context: like network <==> Audio API (CoreAudio for OSX, ALSA for Linux, PortAudio for Windows...), or several ALSA devices..etc..
(The adapters are also developed as "in server" clients, this make a bit more easy to add them in a running session using "ladish" kind of studio management approaches...)
How complex do you think it would be?
Thanks.
Stéphane
(apologies for cross posting)
The Hydrogen team is excited to announce the first 'Hyrdogen Spring Drum
Kit Contest' !
As you all know, a drum machine is only as good as the sounds it produces
-no matter how many whistles and bells it boasts.
Some time ago there was a small poll on the Hydrogen site asking the
Hydrogen users (aka 'you' ;-) what feature they wanted more than anything
else.
The answer was clear : "more and better drum kits".
The goal of this fun contest is simple : with your help we can expand
Hydrogen's sound library with some great new drum kits, and since this is a
contest there are some really neat prizes to win!
So if you have been playing with samples and thinking about creating a drum
kit, but then decided not to do so after all : now is the perfect time to
push yourself and go that extra mile. Once it's done you'll feel so much
better ;-) Or maybe you have already made a drum kit in the past but
didn't think it was worth submitting? Think again and share your hard work
with the rest of the world!
Curious ? Check out the details on the contest page
<http://hydrogen.popez.org/hcms/node/2035>
Hope to hear from you soon !
The Hydrogen team
I am forwarding a mail and sample code from Ed Sweeney
(with permission).
He'd appreciate any comments.
---------------------------------------------------------------------
Joel,
Programming jack is fun.
Check out the attached, it is jack's simple_session_client.c in perl.
I don't know how to test the savequit session events but support for
them is coded and the sample processing totally works. I rewrote
metro.c metronome in perl too, works.
I have generated API libs for perl, python, ruby, and lua. Each of
them has a reworked simple_client that works. Ruby has a bug with the
metronome I haven't been able to find yet.
I'm sure there are lots of bugs and wrong design choices and poorly
chosen names but it is a start!
The build system is messy. I'll put a tarball on a server and tar up
a binary installable perl module today. If this looks like it will be
usable, I'll put it on github.
-- simple_client.pl --
#!/usr/bin/perl
use jackscript;
use strict;
use warnings;
use Cwd 'abs_path';
my $jc;
if (defined($ARGV[0])) {
print("restarting with uuid $ARGV[0]\n");
$jc = jackscript::JsClient->new("simpler", $ARGV[0], $jackscript::JackSessionID);
} else {
$jc = jackscript::JsClient->new("simpler", undef, $jackscript::JackNullOption);
}
my $in = $jc->registerPort("input", $jackscript::JackPortIsInput);
my $out = $jc->registerPort("output", $jackscript::JackPortIsOutput);
$jc->activate();
my $done = undef;
until($done) {
my $jsevent = $jc->getEvent(-1);
if ($jsevent->getType() == $jackscript::PROCESS) {
my $inbuffer = $in->getBuffer();
my $outbuffer = $out->getBuffer();
my $nframes = $outbuffer->length();
for (my $i = 0; $i < $nframes; $i++) { #copy input to putput
my $s = $inbuffer->getf($i);
$outbuffer->setf($i,$s);
}
} elsif ($jsevent->getType() == $jackscript::SAMPLE_RATE_CHANGE) {
my $sr = $jc->getSampleRate();
print("sample rate change event: sample rate is now $sr\n");
} elsif ($jsevent->getType() == $jackscript::SHUTDOWN) {
print("jack shutdown event\n");
$done = "done!";
} elsif ($jsevent->getType() == $jackscript::SESSION) {
my $dir = $jsevent->getSessionDir();
my $uuid = $jsevent->getUuid();
my $se_type = $jsevent->getSessionEventType();
my $setypeTxt = $se_type == $jackscript::JackSessionSave ? "save" : "quit";
print("session notification: path $dir, uuid $uuid, type: $setypeTxt\n");
if ($se_type == $jackscript::JackSessionSaveAndQuit) {
$done = "done!";
}
my $script_path = abs_path($0);
my $cmd = "perl $script_path $uuid";
$jsevent->setCommandLine($cmd); #tell jackd how to restart us
} else {
die("unknown event type\n");
}
$jsevent->complete();
}
print("simple_client.pl ended\n");
--
Joel Roth
Hello. I'm using portaudio19 to write an app that connects to jack (and
alsa) and I can't find anywhere in the portaudio api a way to ask jack
for the current samplerate and buffersize.
¿Am I missing something obvious?
¿Do I have to use the jack api to get these params and then be able to
use the portaudio api for starting a stream, implementing the audio
callback, etc?
