Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Fons Adriaensen

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)

13 years, 9 months

First release of zita-ajbridge

by Fons Adriaensen

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.

13 years, 9 months

Re: [LAD] [Jack-Devel] First release of zita-ajbridge

by Stéphane Letz

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

13 years, 9 months

Re: [LAD] First release of zita-ajbridge

by Fons Adriaensen

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)

13 years, 9 months

update of zita-ajbridge

by Fons Adriaensen

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)

13 years, 9 months

Re: [LAD] [Jack-Devel] First release of zita-ajbridge

by Stéphane Letz

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

13 years, 9 months

Re: [LAD] First release of zita-ajbridge

by Stéphane Letz

> ---------------------------------------------------------------------- > > 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

13 years, 9 months

Announcing the first 'Hydrogen Spring Drum Kit Contest'

by thijs van severen

(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

13 years, 9 months

forward: jack session api in perl, python, ruby, and lua

by Joel Roth

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

13 years, 9 months

Getting jack samplerate and buffersize with portaudio.

by Rafael Vega

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?

13 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev