Linux-audio-user September 2013

linux-audio-user@lists.linuxaudio.org

99 participants
90 discussions

[Fwd: Re: [LAD] forking (was Re: Aeolus)]

by Ralf Mardorf

-------- Forwarded Message -------- From: Ralf To: linux-audio-dev(a)lists.linuxaudio.org Subject: Re: [LAD] forking (was Re: Aeolus) Date: Sat, 21 Sep 2013 07:40:42 +0200 Here is a statement of Maurizio M. Gavioli: https://github.com/mgavioli/oscAeolus/issues/1 My impression is that he didn't do something bad, that he has got no evil intention and that he is pleasant-natured, IOW what he seems to be a win for the community. However, I didn't read the mails from yesterday 21:35 to today. Perhaps I'll win new insights when reading them now and understand whats bad with Maurizio M. Gavioli and his fork. At the moment my impression is, that it's Fons fault to chose the wrong license and he tries to blame another man for his own mistake. Just an impression. I'll start reading now.

11 years, 3 months

Some linux keyboard and bass jamming

by Ken Restivo

I'm in the mix playing my linux netbook keyboard rig live from around 03:30:00 after the Sun Ra tracks, through until the bitter end when it transitions into the Zardoz soundtrack. http://spazradio.bamfic.com/2013-09-18-all.ogg (warning: 5 hours of music). Most of the linux synth work is between 03:55:00 or so until 04:41:00. The MPC drums and loops (on Ableton, sorry) is Spukkin Faceship. The rapper at 03:35:00 or so is Letter D from Guadalajara http://letterd.net/ The bass is me (fluidsynth) pretty much throughout. Lots of bass in this jam. You can hear fluidsynth clavinet with Fons's autowah at various points. Also Rhodes fluidsynth with JACK RACK, and plenty of Monosynth too. The echo I use excessively throughout is a LADSPA plugin too. -ken

11 years, 3 months

Re: [LAU] [LAD] Community Interaction and Working Together

by Harry van Haaren

On Fri, Sep 20, 2013 at 4:18 PM, Brian Sorahan <bsorahan(a)haivision.com>wrote: > I've been wishing for a free Reason-killer ever since starting to use > linux. I actually haven't used Reason since version 4-ish so that is my > reference point (I'm sure it is much more [powerful|bloated] now) > I've never had a proper go at Reason, but I know that Carla is a "rack" type plugin-host: perhaps combining that with Seq24 might get you quite far along? Anyway, noted! -Harry

11 years, 3 months

Re: [LAU] [LAD] Community Interaction and Working Together

by Ralf Mardorf

On Fri, 2013-09-20 at 15:11 +0200, michel dominique wrote: > A monophonic real time note to MIDI converter. Rackarrak

11 years, 3 months

Music with Linux - Nepali Dub

by James Stone

Hi All, Just finished a dub version of "Mayalu Mayalu" by my friend Manoj. Recorded in Ardour and mixed in Mixbus. Here is the original version: https://soundcloud.com/jmstone/mayalu-mayalu-manoj download link: https://soundcloud.com/jmstone/mayalu-mayalu-manoj/download Here is the (new) Dub version: https://soundcloud.com/jmstone/mayalu-dub/s-Tr8ic download link: https://soundcloud.com/jmstone/mayalu-dub/download/s-Tr8ic/ Enjoy! James

11 years, 3 months

Aeolus

by Fons Adriaensen

Hello all, It has come to my attention that there are ATM at least two 'forks' of Aeolus. The first by the MuseScore team, the second by one Maurizio Gavioli. Neither of them even had the decency to let me know of their work, and both are taking Aeolus in a direction I do not approve of. Gavioli has even added his 'copyright' to the sources of the libraries that Aeolus depends on but which are not part of its source distribution. Apparently the intention is to release incompatible versions of those as well. If this is typical for the attitude taken by the Linux Audio community then my motivation to contribute to it will take a serious blow. As announced previously, there will be a fully reworked release of Aeolus next year (on the occasion of its 10th birthday). Apart from major improvements to the audio code it will be completely OSC controlled. None of this will be compatible with the forks of course, they'll find themselves instantly obsolete. And I will make sure that this sort of thing won't happen again, even if that means a more restrictive license. 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)

11 years, 3 months

jack - ardour - CPU

by Fero Kiraly

hi list, when I start Jack, there is in transport RT 2%, then when I start ardour the percentage rise up to 34% - is that ok ? (i am asking becaouse i have some problems & I am trying to resolve them) thak you, fero

11 years, 3 months

Re: [LAU] jack - ardour - CPU

by Fero Kiraly

yes, it is fresh ardour session. my cpu is intel i3 2.xGHz, so i think spomething is wrong... ;( fero

11 years, 3 months

Re: [LAU] Testing JACK and PA latency

by Patrick Shirkey

Resending as the first one appears to have been blocked. On Thu, September 19, 2013 8:46 pm, Fons Adriaensen wrote: > On Thu, Sep 19, 2013 at 08:04:04PM +1000, Patrick Shirkey wrote: > >> > 1. Measure the round-trip latency of your sound card (with an external analog loop). >> > >> >> Can I use jack_delay running on a second computer connected to the external i/o of the first computer to get this value? > > You'd measure something different... > > But you could use two computers as follows: > > A = computer with jack, PA, audacity > B = second computer with sound card, jack and jack_delay. > > 1. Measure the round-trip latency on B, with an external > analog loop. > > 2. Connect B -> A, A -> B, run complete chain on A. > > 3. Measure again on B, subtract the value from (1). > >> > jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay. >> > >> >> Does this look reasonable? >> >> 1023.978 frames 21.333 ms total roundtrip latency >> extra loopback latency: 1023 frames >> use 511 for the backend arguments -I and -O >> 1023.976 frames 21.333 ms total roundtrip latency >> extra loopback latency: 1023 frames >> use 511 for the backend arguments -I and -O >> 1023.977 frames 21.333 ms total roundtrip latency >> extra loopback latency: 1023 frames >> use 511 for the backend arguments -I and -O > > Don't know - I'm by no means a PA expert... and I don't know > your Jack period size. Given PA's reputation I'd expect more: > 1024 samples would mean that PA imposes almost the same RT- > requirements on apps as Jack does, and it was designed *not* > to do that... But maybe the jack <-> PA interface doesn't > use the same amount of buffering that PA normally adds. > > Note that the value measured is modulo 2^16 samples, but I > wouldn't expect anything more than a second, so this probably > irrelevant. > Here's a bit more detail for discussion before I send this over to the PA guys for feedback. I am seeing the time period returned by jack_delay regularly increase during the measurement process. Do you have any thoughts on why that would be happening? I would like to rule out jack_delay because this is most likely a bug in PA that I have come across now. I'm using this method: jack is now set to 64/48000/2 This is the graph: jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay Using audacity with 0 internal latency and in pass through mode I see the following results. It starts out as 10.667ms and after a few seconds it climbs up to 70.667 ms. I see similar results with ecasound instead of audacity using the following graph and ecachain: jack_delay -> pa_source -> ecasound -> pa_sink -> jack_delay ecasound -f:32,2,48000 -b:64 -i alsa -o alsa In that case it starts at 60.000 ms and climbs upto 572.000 ms after a few seconds of running the test. Console logs here: http://boosthardware.com/pa-jack-latency.txt > >> > 3. If pa_source and pa_sink are a single Jack client (probably not), >> > subtract one period from the result of (2). >> >> Can you explain that with the data above? > > If they are a single Jack client you create a loop in Jack's > processing graph, this adds one period to the measurement. > > >> > 4. Add the two values. >> > >> >> I would like to provide an app for this task. Do you think it would be worthwhile to extend jack_iodelay for this purpose? > > Don't see how. You need to do two measurements anyway, no matter how it's done, then add or substract. > -- Patrick Shirkey Boost Hardware Ltd

11 years, 3 months

Testing JACK and PA latency

by Patrick Shirkey

Moving this thread to LAU as it seems to be a more generic issue now: I am testing the round trip latency when using PA and JACK together. I have the following connection graph: jack_system (in) -> pa_source (in) -> audacity (in) -> audacity (out) -> pa sink (out) -> jack_system (out) Audacity is run in pass through mode with internal latency set to 0. I would like to measure the round trip latency from jack_system (in) to jack_system (out) This is a slightly unusual request but it is actually a reasonably important measurement in the bigger scheme of things. Does anyone have any suggestions? Ideally I would like to get accurate measurements for both input and output latency. input: jack_system (in) -> pa_source (in) -> audacity (in) output: audacity (out) -> pa sink (out) -> jack_system (out) So a tool that allowed me to measure the latency between every node on the graph would be perfect. Obviously made alot harder by mixing PA and JACK together. I have tried jack_iodelay but it does not measure the input signal from the mic instead it provides it's own signal. I suppose I could modify jack_iodelay to accept an input signal as the starting point for the latency graph but I have not looked into the code yet to see how tricky that would be. -- Patrick Shirkey Boost Hardware Ltd

11 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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-user September 2013