[LAD] Re: Pipewire

[Robin Gareus]

Hi Fons,

As far as I know pipewire can not currently meet all 8 of your 
requirements, but I best leave this to Wim to answer.


On 2024-08-13 15:39, Fons Adriaensen wrote:

> 1. Jack2 and some clients are started manually after I login,

So you finally made the switch to jack2?

> and will be running all the time.

just a sidenote. doing that killed the battery on my old laptop.


3. PW will be started manually when required, and I don't expect
that will happen very often. It may remain running when no longer
needed but shouldn't interfere. It will be used to connect apps
to Jack as in (2), or those that even don't support ALSA, or
maybe to route audio from Jack to Bluetooth etc.



I do occasionally run pipewire, and do so from its source tree by just 
calling `make run`.


Then I use the following script to launch applications that i want to 
test with pipewire:


```
#!/bin/bash
PW_SRC=$HOME/src/pipewire/
export SPA_PLUGIN_DIR=$PW_SRC/builddir/spa/plugins
export SPA_DATA_DIR=$PW_SRC/spa/plugins
export PIPEWIRE_MODULE_DIR=$PW_SRC/builddir/src/modules
export PIPEWIRE_CONFIG_DIR=$PW_SRC/builddir/src/daemon
export ACP_PATHS_DIR=$PW_SRC/spa/plugins/alsa/mixer/paths
export ACP_PROFILES_DIR=$PW_SRC/spa/plugins/alsa/mixer/profile-sets
export LD_LIBRARY_PATH=$PW_SRC/builddir/pipewire-jack/src/
export 
PATH=$PW_SRC/builddir/pipewire-jack/src/:$PW_SRC/builddir/src/tools:$PATH

exec "$@"
```

e.g pw-src-env pw-jack Ardour8

The downside compared to using the JACK/ALSA bridge is that a already 
running applications will not connect to pipewire after the fact.


Maybe you already knew this, if not I'll take 1/8th of your eternal 
admiration and gratitude :)



> 4. All Jack ports created by PW should be permanent and exist
> as soon as PW is started, so they can be manually connected
> and remain connected even when not in active use.
>
[...]
> 7. I do not expect anything 'automatic' to happen when things
> are plugged in or out.


This is something where macOS' Coreaudio/MIDI shines. Unlike macOS 
Linux/ALSA has no persistent unique IDs for soundcards or MIDI devices. 
ALSA supports hotplug, and first come first server sequential numeric 
IDs. The best you^Wpipewire can do is keep track of cards by name.


So this is not something pipewire can reliably address, until ALSA get 
support to identify cards by vendor and serial-number, and provide a UUID.


Cheers!
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: PandaResampler 0.2.0

[Robin Gareus]

On 2024-06-10 03:16, Yuri wrote:

On 6/9/24 15:47, Marc Lavallée wrote:



Why do people still insist on GNU Tools?



mostly to aid cross compilation. It is still the option that sucks least 
for libraries, notably to specify which symbols to expose in a cross 
platform library. Though meson is catching up.


--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: Update of zita-at1

[Robin Gareus]

On 2024-04-25 00:10, Fons Adriaensen wrote:

The way 'fast mode' works in the x42 plugin could give you
a momentary latency of 2 ms, but the average value will be
quite a bit higher and depend on signal content. 


Correct, yet the effective signal delay (which can be measured) needs to 
be reported to the host to align the signal.


No claim is made that the pitch is corrected within that time. The time 
until pitch correction kicks in is obviously [much] longer. For the case 
at hand (live usage) the audible onset is relevant.


If zita-at2 can get that delay down to 10ms, it is likely sufficient.

> Using the same misleading definition of 'latency' I could
> claim whatever I like for zita-at1-0.8.1, even down to zero.

Well, not quite. Calling Retuner::process (), even without any pitch 
correction delays the signal. That delay has to be reported to the host.


This all pertains to how long it takes for the first non-zero sample at 
the input to reach the output of the plugin. The plugin's fast-mode 
decreases that latency for practical purposes.


--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: Update of zita-at1

[Robin Gareus]

On 2024-04-24 21:39, Fons Adriaensen wrote:

On Tue, Apr 23, 2024 at 09:24:20PM +0200, Robin Gareus wrote:

On 2024-04-20 16:41, Fons Adriaensen wrote:


With the new logic deciding on forward / backward jumps, the
low latency mode just came for free


Except the latency in zita-at1 0.8.1 is still around ~20ms,


It will be 10 ms when selecting low latency mode.


At 48kHz sample-rate, Retuner::set_lowlat(true) sets Retuner::_latency 
to 1024.



compared 2ms when using the current plugin's "fast mode".


That must be BS. A typical male voice frequency is 125 Hz,
8 ms. So when the algorithm has to skip a cycle, will the
latency change to -6 ms ??

Did anyone ever verify this ? I did a few minutes ago, by
observing in and out on a scope.


Yes, and the documentation and tool-tip of the "fast" control reads
"Reduces latency by allowing initially uncorrected signal."

Probably not what you expect, but it is a nice hack that works well in 
real world live situations.


--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: Update of zita-at1

[Robin Gareus]

On 2024-04-20 16:41, Fons Adriaensen wrote:


With the new logic deciding on forward / backward jumps, the
low latency mode just came for free


Except the latency in zita-at1 0.8.1 is still around ~20ms, compared 2ms 
when using the current plugin's "fast mode".



Re. microtuning individual notes: I don't think the retuning
is ever accurate enough for this to be of any use. Or maybe
I misunderstand what you refer to.


It allows one to detune individual notes, and it is sufficiency accurate 
(not unlike changing the reference pitch or notebias).


Those controls are not exposed in the custom plugin UI. They are control 
ports that show up as automation lines in Ardour, or when editing the 
plugin with a generic control UI.


I think it is best to leave the current plugin as-is. Doing so will not 
break existing sessions using the plugin.



I have started a new project without all the custom patches made to the 
AT1 DSP, and without the variants of the current plugin. The new plugin 
will closely follow the upcoming zita-AT2.




What would be great (in particular for zita-at2) would be
a mode were you can e.g. select a region in Ardour, have it
analysed, present the result graphically so it can be edited,
and finally apply the edited version to the region...


It's highly unlikely that we'll reinvent Melodyne. The hard and time 
consuming part is not the DSP, but the the GUI. It is a full time 
project by itself.


But you never know, someone might step up and file a pull request out of 
the blue. Things like this happened before.


--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: Update of zita-at1

[Robin Gareus]

Hi Fons,

it's great to see you have not lot your edge! :)

On 2024-04-20 11:50, Fons Adriaensen wrote:

> The new Retuner class can probably be used without changes
> in the x42-autotuner plugin.
I had a quick look and and sadly it's not that simple. The plugin 
already has a low latency mode, and supports for per note microtuning.


Either I have to backport your bug-fixes, or add the missing features to 
your new version. Then I will have to check that the behavior of 0.8.2 
does not alter the sound of existing sessions using the plugin.


Can you elaborate on the bug fixes that you made?

I'm already looking forward to zita-at2! That will have to be a new 
plugin. So perhaps there is also an option to wait for that to drop.


Thanks for your hard work on this.

--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

Re: [LAD] library soname, was Re: Rubber Band Library v3.0.0 released

[Robin Gareus]

On 7/28/22 15:52, Chris Cannam wrote:
> 
> The version in the .pc file is written in at install time,

Except, it isn't. $PREFIX/lib/pkgconfig/rubberband.pc here has Version:
1.8.2 for rubberband v3.0.0

the .pc.in file likely needs a placeholder %VERSION% so that it is
replaced at install time.

> The ABI has been at 2.something since version 1.2, 

Yeah that's fine. I was just surprised to see the age being zero.

http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Rubber Band Library v3.0.0 released

[Robin Gareus]

On 7/14/22 21:20, Chris Cannam wrote:
> Version 3.0.0 of Rubber Band Library is now available.
> 
> https://breakfastquay.com/rubberband/
>

Congrats on the release and thanks for the very informative blog post.

One small question:

https://hg.sr.ht/~breakfastquay/rubberband/browse/rubberband.pc.in?rev=v3.0.0

states Version: 1.8.2 (not 3.0.0).
The ABI version of the shared object is 2.2.0

Is that expected?

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Linuxaudio.org update and next steps--call for community input and participation

[Robin Gareus]

Dear Linux Audio enthusiasts,

As you may have seen on
https://lists.linuxaudio.org/archives/linux-audio-announce/2022-July/003054.html
our long time Director wishes to  step down from his duties.

Discussion continues on the
https://lists.linuxaudio.org/listinfo/consortium email list. The list
archive is open to the public, and everyone who is interested is very
welcome to join the discussion there.

--
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Fw: Re: Deriving a steady MIDI clock crossplatform?

[Robin Gareus]

On 5/19/22 22:27, Fons Adriaensen wrote:
> Don't know about Apple. Last time I looked it didn't have clock_gettime(),

While there is a corresponding mach/clock.h, for the case at hand it is
preferable to use Apple's Core Audio, CoreMIDI. MIDI Event scheduling is
abstracted, and there is dedicated API to convert timestamped events
with high precision:

AudioConvertNanosToHostTime() and AudioConvertHostTimeToNanos()

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Any csound experts here ?

[Robin Gareus]

On 2/1/22 12:53, Fons Adriaensen wrote:
> Hello all,

Hi Fons,

I'm not a csound expert, but I do know the answer to at least 2 of your
questions:

> * run Csound with Jack,

  -+rtaudio=jack

> * using Ninp input ports and Nout output ports,

I don't recall this being a parameter, but the `outch`  and `nchnls`
opcodes sets the number of output channels. I never tried this myself
with more than 2 channels though.

> * not autoconnecting any ports,

 -odac:null and -iadc:null

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Programming LV2 plugin from scratch tutorial video series

[Robin Gareus]

On 10/18/21 10:54 PM, Fons Adriaensen wrote:

> I never got to grips with turtle. 

https://www.w3.org/TR/turtle/ to the rescue :)

There is currently ongoing work to allow JSON-LD as alternative, but
that's just the encoding.

> In particular not with things like:

> @prefix doap:   .
> @prefix lv2:    .
> @prefix rdf:    .
> @prefix rdfs:   .
> @prefix units:  .
> 
> All docs and tutorials I found mention that the URLs do NOT
> mean that an application reading a file that contains them
> would actually need to read them from the web (which would
> be a unacceptable security risk anyway).

URIs are just used as unique identifiers. They do not even need to
resolve and one can use urn: as well. However in most cases they point
to online documentation which is helpful to developers.

> Which raises the question why those @prefix lines are 
> required at all. 

@prefix just syntactic sugar, so you do not have to spell out the full
URI every time. Instead of e.g.
  http://lv2plug.in/ns/lv2core#ControlPort
you can just write
  lv2:ControlPort

> So all that these lines seem to provide is some illusion
> of conformity which isn't enforced or checked at all. 

Those URIs are defined in header files of the LV2 ontology and must
match, otherwise a LV2 plugin does not conform to the spec. There are
tools like lv2lint to check the validity, but other than that, they are
just unique IDs.

> So the conclusion is that this isn't any better than any
> ad-hoc way of encoding the plugin metadata.

Except it is not ad-hoc, but a w3c standard. Why invent an new meta-data
schema for unique resource IDs, when there is already a very good one
out there, that is also formalized as RFC?

As side-effect you can also use existing tools from the semantic web to
index and search LV2 plugins. IIRC the MOD website uses that.

I hope that clarifies things,
robin




OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Phase rotation

[Robin Gareus]

To follow up, there is

https://github.com/x42/phaserotate.lv2#readme

Binaries of the plugins are available from
https://x42-plugins.com/x42/x42-phaserotate
The commandline tool is currently only available when building from source.

On 8/31/21 3:09 PM, Fons Adriaensen wrote:
> On Tue, Aug 31, 2021 at 04:24:43AM +0200, Robin Gareus wrote:
>  
>>> Now don't believe that phase shifting a signal will always result
>>> in a waveform with a lower peak/RMS ratio. It could very well
>>> have the opposite effect.
>>
>> Well, there is a minimum. So far I just brute force detect it, trying
>> all angles in 1 deg steps on a file.
> 
> Brute force indeed...

Works sufficiently well and fast, I have a few ideas how to integrate it
into the plugins, but it is tricky since it requires context.

> In other words, this really kills whatever snappy transient response
> you may have had.
I did some listening tests, both on individual samples as well as using
the plugin on the master-bus with various performances. In many cases it
is audibly transparent.

But yes, it can kill quality, just like [multiband] compressors,
limiters, or any tool, really.

On the upside I now have better understanding of segmented convolution,
hilbert filter and related FFT topics, which is what this exercise was
about.

Cheers!
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Phase rotation

[Robin Gareus]

Hi Fons,

Thanks for the reply, and from vacation no less.

On 8/30/21 7:06 PM, Fons Adriaensen wrote:

> To implement this you need more than just FFT and IFFT. Using only
> those on each block would amount to circular convolution, while
> what you need is linear convolution. Changing only the phase of
> a signal is just a special case of filtering, which means the output
> will be longer than the input.

Aha! That is what I was missing and didn't understand. Thank you.

> Define the phase shift in the
> frequency domain (i.e. as if it were the result of an FFT), do the
> inverse FFT and use the result as the IR for the convolver.

So just compute a FIR and apply it. I now have a working prototype.

I hoped to sidestep that because the phase-angle should be a sweepable
parameter. I can probably make this work by cross-fading the computed
FIR when the parameter changes.

> Now don't believe that phase shifting a signal will always result
> in a waveform with a lower peak/RMS ratio. It could very well
> have the opposite effect.

Well, there is a minimum. So far I just brute force detect it, trying
all angles in 1 deg steps on a file.

Finding out if it can be computed is up next. Perhaps using linear
regression on the spectrum of the file. I may pick your brain again when
I progress to that stage.
> Greetings to all from sunny Crete.

The next retsina is on me, unless you prefer a cold ΑΛΦΑ beer :)

Stay safe!
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Phase rotation

[Robin Gareus]

Hi all,

During the last days, I looked into phase-ration: components of a signal
are delayed differently depending on their frequency.

A good write up on the subject can be found at [1], and a commercial
tool is available from [2].

The interesting aspect is that phase rotation does not alter the sound
of the signal nor the loudness. However changing the phase vs. frequency
relationship between lower and upper harmonics changes the waveform and
can affect where the digital peak occurs.

For this reason phase rotation is commonly used by radio stations to
reduce the signal peak, and make the signal more symmetrical. Phase
rotation circuits are also used during mastering to increase headroom.

To implementing this, the following operations are performed:

* FFT
* rotate phase, retain magnitude
* inverse FFT

This works well, except for the first FFT bin: 0 Hz, DC offset. If the
phase-shift changes the average DC level of the signal there is a
discontinuity.

I could use some of the collective expertise of this list.

Has anyone looked into this before?

Is it even possible with piecewise block processing?

Is there a way to calculate the DC offset?

Since the overall magnitude does not change simply summing up the bins
results in the same 0th bin. I considered to low-pass filter the DC
offset, or simply remove the DC offset using a high-pass before the FFT
to mitigate the issue. But either introduces different artifacts. If I
understand correctly, a Hilbert transform as mentioned at [1] has the
same issue.

I've condensed the DSP into a simple test tool to toy around with the
issue: https://gist.github.com/17fd61b04d4c4939727dfdccd79f53a5

with low frequencies, the differences are obvious:

* https://i2.paste.pics/cc32f6c5d622e31ab0e830ab1ce205e9.png (2.5 *
FFT's base-freq)
* https://i2.paste.pics/3e6eb827148b90800569843c11da2e48.png (0.37 *
FFT's base-freq)


I'd appreciate any insights.

--
robin


[1]
https://forum.juce.com/t/how-to-rotate-the-phase-of-an-audio-signal/39072/10

[2] https://www.izotope.com/en/products/rx/features/phase.html



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?

[Robin Gareus]

On 7/7/21 1:00 PM, Wim Taymans wrote:
> This utterly fails with jackd on this system, it doesn't even want
> to start all the clients, I'm sure it's something with the config somewhere...

jack has a port-limit (IIRC 256 by default). It is not dynamic and
unbound for performance reasons.

try:  jackd --port-max 1024 -d alsa ...

--
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?

[Robin Gareus]

On 7/4/21 6:35 PM, John Murphy wrote:
> On Wed, 30 Jun 2021 15:48:31 -0700 Yuri wrote:
> [...]
>> Does anybody have experience using it?
>>
>> https://pipewire.org/
> 
> Yes. I've used it for a whole day now, on Linux Mint 20.1 Ulyssa base
> (Ubuntu 20.04 focal). Everything seems to just work.


Yes, the project is making huge progress. Also thanks to the many early
adopters filing helpful issue reports. Wim and his team address them at
incredible speed.

If you use it, be prepared to live on the bleeding edge, e.g. until last
week pipewire didn't set realtime permissions correctly, and the week
before had a crashing bug with Ardour querying ports when 3rd party apps
are involved. Fixed now.

So update early, update often

--
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?

[Robin Gareus]

On 7/1/21 12:48 AM, Yuri wrote:
> Somebody said on GitHub that "Pipewire is the soon to be successor to
> Jack/Pulseaudio".


Yes, and ALSA as well to some extent. To applications pipewire looks
like a running JACK server, or pulseaudio or like an ALSA device. So
existing apps do not have to be changed.

Search this list archives from 2018. There was a discussion of the
framework.

> Is Pipewire viewed like this by the wider community? Does anybody have
> experience using it?
> 

Yes, all Fedora 34 users, and some Arch'ers too. It comes up regularly
on the Ardour forum in recent months, top 3: [1,2,3].

There are still a few rough edges, but it matures quickly.

--
robin

[1]
https://discourse.ardour.org/t/has-anyone-experimented-with-pipewire-yet/104933
[2]
https://discourse.ardour.org/t/solved-is-there-a-simple-definitive-answer-to-getting-pipewire-fedora-34-to-play-nice/106059
[3] https://discourse.ardour.org/t/god-save-pipewire/105691



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Freenode #lad #lau

[Robin Gareus]

On 6/12/21 8:37 PM, Marc Groenewegen wrote:
> What happened? 

The channels moved to https://libera.chat/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is there an LV2 plugin that can add echo like echo added by large cathedrals?

[Robin Gareus]

On 4/6/21 10:00 PM, Yuri wrote:
> I remember listening to the talk of researchers who were traveling to
> different old cathedrals, particularly to Hagia Sophia in Turkey, and
> measuring echo in these cathedrals. Such buildings add a lot of deep and
> very prolonged echo which depends on the building's shape and materials.
> They were quantifying the noise response too.
>

You could ask CCRMA for the Hagia Sophia IRs.

Alternatively https://www.openair.hosted.york.ac.uk/?page_id=36 has a
few very nice ones.

St. Mary's Abbey has a very long reverb tail, as does the Hamilton
Mausoleum. Also check out the Spokane Woman's Club.

The Lady Chapel of the Ely cathedral is amazing, too:
https://www.jezwells.org/Computer_music_tools.html#Impulse_responses

> Are there LV2 plugins that can add same or similar echo as cathedrals add?

Any convolver will do. Apart from the ones that others have already
mentioned:

https://lsp-plug.in/ has a very efficient and reliable one with plenty
of controls. If you want a simple one with presets-only (incl. the
openairlib) check out: https://x42-plugins.com/x42/x42-zconvolver

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] XUiDesigner -> create LV2 plugs from scratch

[Robin Gareus]

Hi Fons,

On 3/23/21 9:59 PM, Fons Adriaensen wrote:
> If by that you mean it can't use dynamic libs, then how do
> you arrive at that conclusion ?

It is motivated by running plugins in process to avoid context switches.

Say you have 2 plugins, one using aubio.so.2 the other aubio.so.3, or
different plugins using different versions of libavresample.so

Distros often bundle multiple major versions of libraries and that is
fine as long as a given ABI of that library is only used by different
processes. But when you want to load plugins into a host, they will
conflict.

Another example where this happened in the past was fftw. Then this also
extends to various GUI toolkit conflicts (gtk 2/3/4 cannot co-exist in
the same memory space, nor can QT 4/5/6).

Plugins should be self-contained and not depend on external libs (except
for ones with a client/server interface where the lib needs to match the
server e.g. X11, openGL -- but those have versioned symbols and a stable
ABI).

As added benefit, this increases reliability when distributing plugin
binaries: The plugin does not use some random library version found on
the target system.


Cheers!
robin

References:
 https://ardour.org/plugins-in-process.html
 https://gist.github.com/abique/4c1b9b40f3413f0df1591d2a7c760db4
 https://linuxmusicians.com/viewtopic.php?p=84986#p84986
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] READ THIS IF YOU CARE ABOUT FREEDOM! Fwd: [LAA] Non DAW release including Non Session Manager (i.e. the real NSM)

[Robin Gareus]

On 1/29/21 6:18 PM, rosea.grammostola wrote:
> Linuxaudio community has a serious problem

Yes, the problem is that people here are not discussing Linux Audio
Development :)

"The Linux Audio Developers (LAD) list is dedicated to sound
architecture and application development for the Linux Operating
System." [1]

Please refrain from any personal references. Neither your nor J.Liles
messages are acceptable here. Please focus on technical aspects
pertaining to Linux/libre audio projects. Thank you.

PS. You may raise issues pertaining to policy [2] article 6 by
contacting the consortium [3].


[1] https://lists.linuxaudio.org/listinfo/linux-audio-dev
[2] http://linuxaudio.org/policy.html
[3] https://lists.linuxaudio.org/listinfo/consortium
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A question to plugin host devs

[Robin Gareus]

On 12/20/20 5:59 PM, Fons Adriaensen wrote:
> Hello all,
> 
> I wonder what are the pros and cons of using RTLD_NODELETE as
> a flag to dlopen() and call dlclose () as soon as the required
> symbols are loaded.
> 
> The alternative is to leave all shared object handles open until 
> the host terminates.

Why keep it around?

As soon as the last plugin instance is deleted from a session the
plugin's shared object can and should be unloaded. Otherwise you would
just accumulate [shared] memory simply by adding and removing different
plugins.

> What are you doing in your plugin host

VST3 and LV2 reference implementation for Linux just use RTLD_LAZY
(along with dlopen's default RTLD_LOCAL), and dlclose() when the last
instance is removed.

That is also what Ardour does for LV2 and VST3.

I do not know any plugin host that uses RTLD_NODELETE.
Besides, NODELETE is not portable. macOS' CFBundleLoadExecutable() and
Windows LoadLibraryExA do not have equivalent mechanism.

In the distant past, Ardour (really libsuil) used NODELETE for LV2 GUIs.
https://lv2plug.in/ns/extensions/ui#makeSONameResident
but that is no longer the case since the option was deprecated.

> (and why)

Accumulating memory generally degrades overall performance. The larger
the page table, the more expensive are context switches.

[Re]Loading the shared object adds overhead of static initialization,
which is usually done in the GUI thread and fast compared to any user
interaction. It's also a one time operation, not a periodic one.

As a side-effect it also aids plugin-developers. If a host unloads the
.so. A dev can recompile the plugin and reload it in the same session.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] wiki.linuxaudio.org mostly fixed again

[Robin Gareus]

On 3/15/20 1:26 AM, Jeremy Jongepier wrote:
> Dear all,
> 
> The linuxaudio.org wiki is almost fully functional again. 

Hi Jermey,

Thanks for your work so far!

It looks like most of the meta-data (JACK, LV2, ..) for apps is lost:

https://web.archive.org/web/20161119193236/http://wiki.linuxaudio.org/apps/daw_apps
vs https://wiki.linuxaudio.org/apps/daw_apps

and tag/categories don't work:

https://web.archive.org/web/20161129041747/http://wiki.linuxaudio.org/apps/categories/jack
 vs https://wiki.linuxaudio.org/apps/categories/jack

Also while rewriting works, dokuwiki isn't configured to 'userewrite'
and generates links using request parameters  doku.php?id=...

e.g. "Apps" in the left sidebar links to
 https://apps.linuxaudio.org/doku.php?id=apps:start
 instead of https://apps.linuxaudio.org/wiki/start

so long,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] BPM and key detection libraries

[Robin Gareus]

On 10/14/19 10:36 AM, Louigi Verona wrote:
> Hey everyone!
> 
> What are the bpm and key detection libraries people use for open source
> projects? And how good are they?

https://vamp-plugins.org/download.html are amazing.

You can test for yourself using sonic-visualizer.


Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Berlin Linux Audio meeting @ c-base 2019-10-08

[Robin Gareus]

On 10/7/19 9:18 PM, Daniel Swärd wrote:
> Hi all.
> 
> Tomorrow it's the scheduled meeting at c-base again. I don't know if
> I'll make it (I've stayed home from work today not feeling great), but
> maybe Louigi or Robin can gather people?

I'm sorry, but I won't be able to join this time, either.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack meterbridge 0.9.2 update / maintenance

[Robin Gareus]

On 7/29/19 8:21 PM, Stephan Bourgeois wrote:

> Should meterbridge be maintained or should another metering app de bundled
> with jack?

Given that jack is cross-platform and meterbridge is a X11 application
it's not very likely to be bundled with jack itself.

The main use-case for meterbridge is the dpm mode with many channels to
check input activity.

You may also want to have a look at
https://lists.linuxaudio.org/archives/linux-audio-dev/2012-June/032475.html
- the debian package applied this, but it never reached upstream, it's
likely not relevant after your re-work either.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack meterbridge 0.9.2 update / maintenance

[Robin Gareus]

On 7/29/19 8:21 PM, Stephan Bourgeois wrote:

> The only thing missing would be a 4x oversampling true peak meter.
https://github.com/x42/meters.lv2/ also comes with a jack app.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] LAC steaming to c-base, Berlin

[Robin Gareus]

Hi all,

A group of people who do not attend the Linux Audio Conference in
Stanford this year are meeting at c-base.org to participate remotely.

http://lac.linuxaudio.org/2019/#program

We'll watch the live-stream of the paper-presentations on Saturday,
Sunday, Monday 17h to 21h CET, and share dinner, which is sponsored by
the Paul Davis and the Ardour community!

You're very welcome to join our small local hallway track in the space
station below Berlin-Mitte, located in the 2nd backyard of Rungestraße
20, 10179 Berlin.

There'll also some un-conference BarCamp track, likley some LV2 hacking
on the week-end. Monday evening overlaps with the Bitwig user-group at
c-base. Going to be fun!

Looking forward to seeing you there,
robin

PS. Safe travels to all who head to Stanford.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Bit shift

[Robin Gareus]

On 3/17/19 5:56 PM, Jonathan Brickman wrote:
> That is likely to change depending on GCC optimization setting, no?

Not usually. It depends on the target architecture more than anything.

Even with -O0, gcc translates integer addition and multiplications into
a combination of bitwise and arithmetic operations if that is
appropriate for the target CPU.


On 3/12/19 11:43 PM, Will Godfrey wrote:
> Does anyone know if GCC will replace power of 2 
> multiplications/divisions of unsigned integers with bit shifts?
Not only power of two, and it depends. In some cases the compiler
doesn't replace it because the resulting code is not faster. Many modern
CPU already implement integer multiplication using bitwise operations in
microcode.

I don't know if this your question is academic, but if you plan to
manually optimize code, I highly recommend against that.

Write semantically! If you mean a multiplication, use (a * 2), if you
mean bit-shift use (a << 1). Do not use bitwise-operations when you
really do integer-arithmetics.

Your future self and code-contributers will thank you for it; as will
compilers targeting future CPU architectures.


2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] So in 2019, which plugin "format"?

[Robin Gareus]

On 11/25/2018 11:47 PM, Gordonjcp wrote:
> Hi folks,
> 
> At the risk of igniting a flame war, if one were to develop softsynth
> plugins for Linux, what would be the "framework" of choice these days?

https://distrho.github.io/DPF/ -- https://github.com/DISTRHO/DPF

> Back in the day I wrote some using DSSI, which was a model I was pretty
> comfortable with.  I had a look at LV2 but couldn't work out how to
> generate the huge incomprehensible non-human-readable "ttl" files.

I thought you didn't want a flame-war? :)
How are they not human-readable? They're nice semantic triplets.

Anyway, you could use DPF to auto-generate the file for you.

> Where does the world stand now?

I don't know about 2019, but in 2018 LV2 still sucks least of the
available options.

In 2019, perhaps VST3 may become an alternative, but right now Bitwig is
the only Linux host to support it, and the VST-GUI API for Linux is also
still in flux.

ciao,
robin

PS. you could /steal/ some GPL code from e.g. zyn-fusion or helm.
The former uses DPF, the latter a patched JUCE to export LV2, both also
offer VST2 as alternative.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Robin Gareus]

On 11/23/2018 01:00 PM, Will Godfrey wrote:
[...]
> Thanks for going into this in such detail Robin. I never realised fp stuff
> could be *quite* so, umm, approximate!

Depending on context and the maths, the difference may not matter at
all, or may be off completely..

  float a = (1 + 1e20) - 1e20;
  float b = 1 + 1e20; b -= 1e20;
  printf ("%f %f\n", a, b);

Any guesses what this code prints without compiling it? :)

> I was using O3. Following on from this I found that if I removed either O3 or
> ffast-math the problem disappeared.

OK, so SSE/AVX/compiler-intrinsics are the issue at hand.

> It's quite possible that I'm over-thinking this as there are actually only a
> few iterations before the initial figures are re-calculated, but I don't like
> mysteries :(
> 

You could also disable this for a specific function only

__attribute__((optimize("-fno-fast-math")))
void different_mysteries_here (float val)
{
...
}

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Robin Gareus]

On 11/22/2018 09:27 PM, Hermann Meyer wrote:
> 
> 
> However, problems with NAN's and INF's when use -ffinite-math-only
> occurs only when we save preset values to file, and only sometimes then.

A shot in the dark..

Serializing a float in most parts of the world uses comma as decimal
separator. e.g. "0,5"

Reading this in the C-locale (dot as decimal separator) with c/c++
standard library functions returns 0. This may lead to a division by
zero later.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Robin Gareus]

Hi Will,

I just ran your code and -ffast-math does not make any difference.

With or without --ffast-math I get "int: 5 rem: 0.049994"

However optimizing the code with `-O2 --ffast-math` does make a
difference because SSE is used.

Do you also use -O2, or -O3 along with --fast-math?

On 11/22/2018 06:30 PM, Will Godfrey wrote:
[...]
> My suspicion is that the difference is due to accumulated rounding
> errors.
> 
> Curiously without the decrements the behavior with and without
> -ffast-math seems to be identical well into the millions.
Yep. you do loose precision. In IEEE 32bit float, there is no 0.1.

0.1 would be approximated as (13421773) * 2^(-27), and 0.05 as
(13421773) * 2^(-28) and truncated.

Note that this is an odd number. The last bit of the mantissa
(0x004d) is lost when the exponent changes.

A simpler example to show this is

#include 
#include 
int main (int argc, char** argv) {
  float a = 0;
  for (int i = 0; i < 100; ++i) {
a += 0.1f;
a -= 0.05f;
a = fmodf (a, 1.f);
  }
  printf ("%f\n", a);
  return 0;
}

using gcc 6.3.0-18+deb9u1, x86_64, this
prints 1.00 (when compiled with -O0)
and0.01 (when compiled with -O2 --fast-math)


The difference here is that the former calls fmodf(), while in the
latter, optimized, case the compiler uses cvtss2sd SSE instead. The
internal limits of float precision differ for those cases.


--ffast-math issues in audio-dsp are usually due to re-ordering and
reciprocal approximations. e.g. instead of (x / 2) the compiler calls
(0.5 * x), which can lead to different results if the inverse value does
not a precise floating point representation.  e.g.  1.0 / 0.1 != 10.0

A good read on the subject is
http://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf (Goldberg,
David: "What Every Computer Scientist Should Know About Floating-Point
Arithmetic").

If you were change the two constants to
  a += 0.5f;
  a -= 0.25f;
the issue vanishes.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Robin Gareus]

On 11/22/2018 07:28 PM, David Runge wrote:

> Rabbit hole stuff! SuperCollider came to a similar conclusion:
> https://github.com/supercollider/supercollider/issues/4116

This is a different issue. In SuperCollider's case they do want NaN and
not finite-math, that is not usually the case for audio.

If you have perform a calculation that can produce NaN or infinite
values or needs to distinguish +/-0 in your DSP code, there is a much
bigger issue.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Berlin Linux Audio meeting @ c-base 2018-11-06

[Robin Gareus]

On 11/04/2018 07:54 PM, Daniel Swärd wrote:
> Hi all.
> 
> Next meeting at c-base is on Tuesday 2018-11-06 at 20:00.

Wasn't it supposed to be the 2nd Tuesday every month?

My calender had it down on the 13th :(

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?

[Robin Gareus]

On 10/30/2018 09:36 AM, Hermann Meyer wrote:
> 
> Am 30.10.18 um 08:37 schrieb Hermann Meyer:
>>
>>
>> Am 29.10.18 um 15:34 schrieb Robin Gareus:
>>>> The plugins already loaded into memory should still hopefully be OK.
>>> yep.
>>>
>>> On Unix systems already loaded .so will be kept in memory. On Windows
>>> you cannot write/replace to a file that is currently opened.
>>>
>>> You can skip and postpone scanning of plugins that are currently in use
>>> until the next session load.
>>>
>>
>> During plugin development I check plugins usually (first) in jalv.

That's good advise.

>> Sometimes I forgot that I've loaded a plug already and update it,
>> result is always a crash in jalv.
>>
>> The same happen in Mixbus4, I've just checked it, out of curiosity.
>>

Ardour/Mixbus does no do as I suggested (it does not skip loaded
plugins). I mentioned it so that others don't make the same mistake.

> True, there is no problem when the update didn't happen in-place, means
> remove the older bundle and then install the new one ( like most package
> mangers does).
>  

In Ardour and jalv's implementation the LV2 world is constructed
statically at application start. Changes won't be picked up correctly.
It's different for VST

Also there may be conflicts by loading the plugin and later open a
mismatching GUI (different .so).


I usually think of changing or adding/removing plugins to be like adding
another [analog] stomp-box effect pedal between a guitar and amp. That
involves to re-plug cables. You don't usually do that while playing nor
while the amp is turned up.

the point is: I don't think it is important that the plugin-scanner must
be able to cope with changing plugins.

What would be nice though is to support scanning in background with a
priority list: When loading a session, first check the plugins that are
already in the session. block and wait until they're re-scanned.
Then load the session and continue plugin discovery in the background.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?

[Robin Gareus]

On 10/29/2018 06:52 AM, Tim wrote:

> On 10/29/2018 12:40 AM, Hermann Meyer wrote:
>> Downside of cached information is, that it could clash on plugin load
>> when the plugin have changed it's ports (updated).
If that happens you have a much bigger issue than stale caches.

Released plugins should not change ports or behavior in a way that is
not backwards compatible. Doing so would break existing sessions using
the plugin.


>> So when you save plugin information on your own, you need to check
>> before you at least load the plugin, if the cached information is
>> still valid.
>
> 
> Yes that was of great concern from the start of this effort.
> 
> Scenario 1: While the the program is not running, the user
>  installs, moves, removes, or upgrades a plugin, then runs
>  the program.
> I have an idea at program startup to compare the date/time
>  of each given plugin path with the one of the cache file.
> If different, reload the cache.

I suggest to prefer a checksum or hash (at least additionally), or use
inotify or some existing watch mechanism.

Ardour uses stat()'s mtime. There are various issues with this:
e.g. zip files do not include timezone, some tar archives include
strange timestamps, installers on other platforms do strange things, and
some users toy with clocks on occasion.
Edge cases like these have lead to countless headaches in the past.


> Scenario 2: While the the application is running - perhaps already
>  for hours into a project - the user decides to install, move, remove,
>  or upgrade a plugin. Watch out !
> I have an idea to 'watch' all the given plugin paths for changes
>  and take appropriate action: Crash ;-)
> I don't think the scenario is too drastic though.
> The plugins already loaded into memory should still hopefully be OK.

yep.

On Unix systems already loaded .so will be kept in memory. On Windows
you cannot write/replace to a file that is currently opened.

You can skip and postpone scanning of plugins that are currently in use
until the next session load.

> It might not be wise to alter my data or info of an already loaded
>  plugin if it is deleted or removed or upgraded, but at the very
>  very least I would like to be able to support loading a
>  'brand new' plugin if it suddenly appears.

Why? I've never seen someone installing/removing software while
recording or mixing. It also sounds like a bad idea to me.

What happens if you run two instances of the same DAW or two different
programs that share the plugin cache?

Do all programs watch for changes and use lock-files to prevent
concurrent scanning?

One solution is to ask a user to directly or indirectly initiate a scan.
Directly by pressing a button or indirectly by opening a session. These
actions are rarely performed concurrently.


> 
> Also IIUC sometimes plugin ports can be created on-the-fly? Ouch.
> 

Do you need to know the ports a-priori?

The host needs to load the plugin anyway to insert it. So the only
interesting part to cache is

 * Plugin-Name
 * Plugin-Author
 * Factory & User Presets
 * Category/Tags (if any)
 * Description (if any)

I/O and Control Ports are not usually something that's worth caching,
except perhaps for "has MIDI I/O" (to detect Instruments for plugins
that don't specify a category).

What other information are you interested to cache? Is there a benefit
to caching port names, default values, for each plugin?


> About my cache format: Since the highest denominator (most advanced)
>  in all these plugin types would be LV2, I think it would be really
>  cool if the Turtle tools or libraries could report ALL types
>  of plugins and generate new ttl files on the fly from found plugins.

RDF is generic, it can describe pretty much anything. I thought there is
already a LADPSA ontology. Also LADSPA uses RDF for presets.

TTL is just a RDF serialization. There is also some discussion to allow
JSON-LD as alternative to turtle for LV2.


LV2's ontology provides for a nice description of the basics, it really
uses  foaf[1] and doap[2,3] for the basics.  This leaves some
classification (categories, tags) and  a presets-name to ID map.

I have no opinion about the de/serialization format. turtle is fine with
me, as would be JSON-LD. Both can be efficiently parsed (low CPU, low
memory, serial I/O) and satisfy requirements (semantic description,
ordered data structure).

> Then we could all simply use our same LV2 discovery codes to examine
>  all plugin types found.

I'm not sure if that's very likely, nor practical. While serd/sord are
generic to deal with turtle/RDF, liblilv is rather specific for LV2. The
mechanism to scan/discover plugins and presets is rather different for
each standard.

Realistically, these days the only interesting plugin formats are LV2,
VST and AudioUnit.

VST does not even specify a system-wide install location for discovery.
The AU format is abstracted by Apple, you can't directly interact with
it but have to use Apple's libs. This leaves LV2.


On a related 

Re: [LAD] New(ish) OSS synth plugin

[Robin Gareus]

On 09/27/2018 02:43 PM, Kjetil Matheussen wrote:
[...]

> For anyone who wants to give it a try,
> it might be that it's enough just using a
> newer version of VSTGUI and gtkmm than I did.
> I used gtkmm 3.16 and gtk-3.3, which probably
> are some years old old. The VSTGUI I used,
> I don't know how hold is, or where it came from.

Indeed, try to update.

VST3's VSTGUI recently removed all gtk from their toolkit.
That greatly helps to produce distributable plugins (since gtk cannot be
statically linked and also has ABI issues when combined other toolkits).

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] PipeWire

[Robin Gareus]

On 02/19/2018 09:39 AM, Wim Taymans wrote:
[...]
> I would very much like to hear your ideas, comments, flames, thoughts on this
> idea. I think I'm at a stage where I can present this to a bigger audience and
> have enough experience with the matter to have meaningful discussions.

Hi Wim,

I think the general lack of enthusiasm about pipewire here is because it
does not solve any issues for linux-audio and at best does not
introduces new ones.

In the past years the most prominent question that I have received is

 * How can I use all of my USB Mics with Ardour on Linux?
 * How do I uniquely identify my many MIDI devices?
 * Why does my audio device not have proper port-names?
 * Why can't I re-connect my device and resume work?

These questions are mostly from Mac or Windows users moving to Linux ...
and many of them moving back to MacOS.

While it is not impossible to combine multiple devices, it is not a
straightforward to set this up. Manging devices uniquely and handling
temporarily missing devices is not possible on GNU/Linux AFAIK.

If you try to come up with a new system (think pipewire), please copy as
many concepts as possible from Mac's CoreAudio.

Both pulseaudio and jack had the correct idea to present audio as a
service to applications. The server is concerned with device(s) and
device settings. However, both fail to abstract multiple devices, map
their port uniquely and provide multiple apps to concurrently use those
devices for different purposes.

The main issue with pulse is that it is a poll API. Also pulseaudio's
per device, per port-latency is incorrect (if set at all). JACK on the
other hand is too limited: single device, fixed buffersize. jackd also
periodically wakes ups the CPU and uses power (even if no client is
connected).

Browsing around in the pipewire source I see several potential design
issues.

In particular data format conversions: The nice part about JACK is that
uses float as only native format. Also port-memory is shared between
application with zero-copy.

In pipewire a port can be any data-type including vorbis and worse MIDI
is a bolted-on sub-type on an audio port.

JACK-MIDI has in the past been criticized most because MIDI was a
dedicated type instead of JACK providing generic event-ports.

Another conceptual issue that I see with pipewire is that it pushes sync
downstream (like gstreamer does), instead of sources being pulled
upstream. This in particular will make it hard to compensate for
latencies and align outputs.

Implementation wise there are plenty of other issues remaining to be
discussed, e.g. context-switches, resampling, process-graph,.. but those
are not important at this point in time.

Cheers!
robin



signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Github DCMA takedown notice - VeSTige header

[Robin Gareus]

On 06/05/2018 09:45 AM, Filipe Coelho wrote:
> On 05.06.2018 01:18, Robin Gareus wrote:
>> Hi LADs,
>>
>> I was contacted earlier today by GitHub with a DCMA request from
>> Steinberg.net to remove the aeffectx.h from VeSTige. [1]
> 
> Oh wow, incredible timing with Microsoft buy out.

Honi soit qui mal y pense.

> Do you think renaming aeffectx.h will be enough?

The filename does match a filename of the official Steinberg VST SDK.
I've added a disclaimer and clarified that is vestige.

It may well be that this is part of a larger outreach. grep all of
github for plugins that ship aeffectx.h.

If you the DCMA notice carefully, you'll fine that they did not even
follow github's guide to do so. It may well be some semi-automated process.

I guess we'll find out, the 24h will expire 21:55 CEST today.

> It is their API, which they might feel entitled to sue over.

Only in the US of A. APIs are not (C) in the EU.
The vestige header is a pure API without any implementation.

>> I have no idea why Steinberg would target this rather low profile
>> project, but there you go.
> 
> Likely because of the name. lv2vst sounds "dangerous" :P
> 
> Sadly, if they insist on this, it will only be trouble for opensource
> applications.
> Ardour, Qtractor, Carla, MusE, LMMS and others all use this vestige
> header... making it "illegal" would mean our beloved tools will simply
> drop VST support.

Those are hosts though. Except for Carla which can be both.

> This is now how they convince developers to change to VST3 at all...

If this is indeed only about plugin (not hosts), then this would explain
it. I am curious if other plugin authors also received a notice.

For hosts, I would be able to ignore the fact the VST3 SDK is a
kitchen-sink and with a bad conscience also tolerate UTF-16, but VSTGUI4
depending on GTK on Linux is a no-go.

> rather, just makes me want to remove all VST related things from my
> system, damn bastards.

LV2 FTW!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Github DCMA takedown notice - VeSTige header

[Robin Gareus]

Hi LADs,

I was contacted earlier today by GitHub with a DCMA request from
Steinberg.net to remove the aeffectx.h from VeSTige. [1]

I am planning to contest the DCMA request. This will ideally happen with
some legal counsel and support from Javier Serrano Polo who is the
original (C) holder of the VeSTige header and reverse engineered the API.

Since Github requires action within 24 hours, I have meanwhile complied
and force-pushed
https://github.com/x42/lv2vst/blob/master/include/aeffectx.h out of
existence.

I have no idea why Steinberg would target this rather low profile
project, but there you go.

Cheers!
robin


[1] Search the web for
"aeffectx.h - simple header to allow VeSTige compilation and eventually
work"
and you will find the exact file in various places.


In case you're wondering how a github DCMA notice looks like:

- - -

**Are you the copyright owner or authorized to act on the copyright
owner’s behalf?**
Yes

**Please provide a detailed description of the original copyrighted work
that has allegedly been infringed. If possible, include a URL to where
it is posted online.**
https://www.steinberg.net/en/company/developers.html

**What files should be taken down? Please provide URLs for each file, or
if the entire repository, the repository’s URL:**
https://github.com/x42/lv2vst/blob/master/include/aeffectx.h

**Have you searched for any forks of the allegedly infringing files or
repositories? Each fork is a distinct repository and must be identified
separately if you believe it is infringing and wish to have it taken
down.**
no

**Is the work licensed under an open source license? If so, which open
source license? Are the allegedly infringing files being used under the
open source license, or are they in violation of the license?**
no

**What would be the best solution for the alleged infringement? Are
there specific changes the other person can make other than removal?**
no

**Do you have the alleged infringer’s contact information? If so, please
provide it:**


**Type (or copy and paste) the following statement: "I have a good faith
belief that use of the copyrighted materials described above on   the
infringing web pages is not authorized by the copyright owner, or its
agent, or the law. I have taken fair use into consideration."**
"I have a good faith belief that use of the copyrighted materials
described above on the infringing web pages is not authorized by the
copyright owner, or its agent, or the law. I have taken fair use into
consideration."

**Type (or copy and paste) the following statement: "I swear, under
penalty of perjury, that the information in this notification is
accurate and that I am the copyright owner, or am authorized to act on
behalf of the owner, of an exclusive right that is allegedly infringed."**
"I swear, under penalty of perjury, that the information in this
notification is accurate and that I am the copyright owner, or am
authorized to act on behalf of the owner, of an exclusive right that is
allegedly infringed."

**Please confirm that you have you have read our Guide to Submitting a
DMCA Takedown Notice:
https://help.github.com/articles/guide-to-submitting-a-dmca-takedown-notice/**

yes i confirm

**So that we can get back to you, please provide either your telephone
number or physical address:**
[private]
[private] Phone: [private]
Steinberg Media Technologies GmbH Fax : [private]
[private]
http://www.steinberg.net

**Please type your full legal name below to sign this request:**
[private]
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Robin Gareus]

On 12/12/2017 04:02 PM, Gordonjcp wrote:

> That doesn't answer the question, really.  For one thing, statically
> linking *anything* is utterly ridiculous and anyone doing that now or
> indeed at any point in the past 30 years of Unix development should have
> their hands cut off.

Keep in mind that audio plugins are not unix.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Robin Gareus]

On 12/04/2017 06:52 PM, Jörn Nettingsmeier wrote:
> On 12/04/2017 01:30 PM, Robin Gareus wrote:
> 
>> Seeing as this was in a train, and last I looked the DB-network was wide
>> open, I'm curious if this was actually a hack by guy in another
>> train-compartment or perhaps a subverted access-point exploiting some OS
>> X vulnerability.
> 
> I was connected to my own phone hotspot. So unless it's a very low-level
> WLAN interface vulnerability, a local wireless exploit seems unlikely.
> 
> I'm pretty sure the kill message did come from the iCloud (a service
> which I'm not using and which I don't indent to ever use) using the
> Find-my-Mac feature. I was _never_ given an option to opt out of this
> feature, and it was never made clear to me that I was carrying a
> time-bomb (with remote wipe option) that would enable unknown third
> parties to potentially cause five-digit damages on a whim.

It's probably all in some EULA smallprint, and your visit to the
Apple-store will be rather unspectacular.

You said earlier "[the macbook] had been factory-reset and completely
installed from scratch." According to the doc, clearing the NVRAM or
PRAM should disable "Find-My-Mac". Then again, since any Apple-store can
un-brick it if you show them a proof-of-purchase, there's yet another
backdoor...

Anyway, I'm glad you were able to get all the data from it.
May I ask how? http://www.system-rescue-cd.org/ ?

Cheers!
robin

PS. As atonement for your sin, I suggest hosting the next Linux Audio
Conference ;-))
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Robin Gareus]

On 12/04/2017 11:52 AM, Louigi Verona wrote:
> You should also understand that millions of people are
> using Macs everyday and their data doesn't get lost, right?

I actually don't know a Mac user who hasn't been burnt and they all use
TimeCapsules or iCloud or dropbox or a similar backup solution.

I've seen a many master-students who are writing their thesis on OS X to
send it to themselves or friends by email every other hour as backup.
Only few of them embraced git, because sending an email is just too trivial.


Anyway Joern's story is not about loosing files, but being locked out of
the machine (!).

Seeing as this was in a train, and last I looked the DB-network was wide
open, I'm curious if this was actually a hack by guy in another
train-compartment or perhaps a subverted access-point exploiting some OS
X vulnerability.


> Because, if not, I can supply many-many stories where I would loose data
> because of stupid Linux machines, lose gigs because suddenly the music
> software wouldn't start, although it did just yesterday. There are enough
> problems that stem from software not having an owner that from it "being
> controlled" by someone else. And then after bashing Linux, I can finish my
> email with a dramatic "don't".
> 
> Any system can fail, and it is never at the right time. And in my
> experience, proprietary systems are generally much more stable than floss,
> and are less likely to fail suddenly and without warning.
> 
> For instance, when preparing for the Sonoj convention, I had Carla start
> crashing on me and I could not complete music examples. I eventually had to
> revert to FLStudio to make them.
> 
> At the Sonoj Convention, 10 minutes before my dj set, Mixxx has deleted all
> of my tracks library and I had to frantically search for a fix. I found a
> workaround, but could not include a couple of new tunes into the set.
> 
> Did I write a post blaming floss for that? No.

I very much hope you did file bug reports for all those issues.


While the end-result may be the same: "fail to deliver result". Joern's
experience is quite different from what you describe.

Also note that all the software that you have mentioned comes with a
disclaimer (GPL):

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

..writing a blaming blog post is a non-starter if you accept the license.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] OSC-generating plugin?

[Robin Gareus]

On 06/19/2017 11:57 PM, Jörn Nettingsmeier wrote:
> the customer is always right

Doesn't sound like the right customer though :-)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] OSC-generating plugin?

[Robin Gareus]

On 06/19/2017 08:07 PM, Jörn Nettingsmeier wrote:
> Hi *!
> 
> Does anybody know of a decent free plugin that generates arbitrary OSC
> command streams from plugin automation data in the DAW? Preferrably
> (gasp!) VST? Idea is to use SomeEvilDAW to send and control smart things
> on a box running a friendly OS and a FriendlyDAW.

Sending OSC is not rt-safe and VST parameters are rather limited.
"arbitrary messages" are no fun and need all kinds of hacks (eg sending
them from the UI thread). There are a couple of single-parameter VSTs
though.

Along those lines there's an ancient LADSPA plugin, too:
https://code.google.com/archive/p/noisesmith-linux-audio/downloads
needs some CFLAGS=-fPIC but otherwise still compiles, but it probably
won't run in SomeEvilDAW.

A more generic solution: https://github.com/x42/jackmidi2osc
Receive MIDI from someplace, generate fancy OSC based on rules.

Spencer wrote a similar tool https://github.com/ssj71/OSC2MIDI/ which
despite its name can also turn MIDI into OSC.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAC 2017 Program - Linux Audio Conference in Saint-Etienne

[Robin Gareus]

On 05/02/2017 08:58 PM, Albert Graef wrote:
> On Tue, May 2, 2017 at 8:53 PM, Fons Adriaensen  wrote:
> 
>> Doesn't need to be pizza, but please no *foie gras* for me :-)
>> Looking at the list of restaurants I noticed this:
>>
>>   
>>
> 
> Looks good to me, and not far from the university.
> 

Lebanese is great. Count me in. ~19h?!

looking forward,
robin




signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/22/2016 07:30 PM, Tito Latini wrote:
> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote:
> [...]
>> > Ableton have now done that, albeit by circumventing the hardest parts of
>> > the problem (a tempo map with varying meter and tempo).
> What?
> 
> I repeat: that's not an innovation.

Did anyone say it was? Why does it matter if it's innovation?

Compared to all the prior-art, I suppose the interesting part of Link is
momentum behind it, along with the apple-style dictated protocol: take
it as-is or leave it. Not the usual years of consortium design
discussions which may or may not eventually result in consensus and more
like a floss-like benevolent dictator style (think jack, or LV2).

The closest thing to innovation is "Pro Audio company that usually does
closed-source proprietary software publishes an API and reference
implementation under GPLv2" and it work on GNU/Linux, too.

That's pretty cool IMHO and I wish more companies would do that!

Also coming up with a protocol is the easier part. Documenting it,
pushing it out to users, gaining traction in the industry etc is the
hard part.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/21/2016 12:24 PM, Perry Nguyen wrote:
> I am still vaguely under the impression that if a Timebase master client is
> Link-capable then any transport-aware client (e.g. most LAU apps today)
> would be able to follow any tempo changes described by the master and
> therefore automatically have "Link support"

Theoretically, yes. A jack timebase master is supposed to translate
current absolute position to musical time. It's mainly useful for
tempo-maps.

Ableton Link does not provide an absolute reference, so the client would
have to maintain an internal count depending on transport state, infer
that information and keep track.

Still jack-position is versatile enough to represent information
provided by Link:

http://jackaudio.org/files/docs/html/structjack__position__t.html

The real question is if it's useful and how many jack-apps
can cope with potentially non-linearity WRT to absolute jack transport
sample time.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/20/2016 01:40 PM, Patrick Shirkey wrote:
> 
>> On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
>>>
>>> Because netjack isn't good enough
>>
>> correct.
>>
>> jack can have a single timebase master and likewise netjack has a single
>> net-master.
>>
>> Ableton-Link is decentralized: Multiple performers can interact with
>> each other on an equal level (no master/slave semantics).
>>
>> It's not groundbreaking tech. Laptop orchestras and the likes have used
>> similar techniques since a while, but all prior-art that I know is ad-hoc.
>>
>> As far as I know this is the only protocol concerning *musical-time*
>> that's spec'ed out, has a cross-platform reference implementation and
>> potential to find its way into hardware.
>>
>> Feel free to criticize the protocol on a technical level or hunt for
>> bugs in the implementation ... or simply ignore it silently.
>>
> 
> So then the next question would be is there any reason NOT to integrate it
> directly into JACK?
> 

There's an existing feature request already: [1]


JACK cannot be slaved to anything. jackd is always master, so there's a
conceptual conflict.

Closest concept is jack-timebase master [2]. A client can provide
musical-time to jack and thereby to all jack clients that support jack
transport.

So yes, there are some reasons to not *directly* integrate it, but like
existing jack tools [3] (jack_lsp, jack_connect, jack_transport,...) it
could be included with jack one way or another. Seamless integration is
possible. It just needs someone to do the work.

Rui already has a working standalone prototype (no timebase support yet,
but it's a good start).

There are also some technical details to be sorted out: e.g. the current
Link reference implementation requires C++11, jack-tools are C89... but
those are details.


Cheers!
robin


[1] https://github.com/jackaudio/jack2/issues/231
[2] http://jackaudio.org/files/docs/html/group__TransportControl.html
[3] https://github.com/jackaudio/tools

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
> 
> Because netjack isn't good enough 

correct.

jack can have a single timebase master and likewise netjack has a single
net-master.

Ableton-Link is decentralized: Multiple performers can interact with
each other on an equal level (no master/slave semantics).

It's not groundbreaking tech. Laptop orchestras and the likes have used
similar techniques since a while, but all prior-art that I know is ad-hoc.

As far as I know this is the only protocol concerning *musical-time*
that's spec'ed out, has a cross-platform reference implementation and
potential to find its way into hardware.

Feel free to criticize the protocol on a technical level or hunt for
bugs in the implementation ... or simply ignore it silently.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/19/2016 11:56 PM, Patrick Shirkey wrote:
> 
>> why?
>>
>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini 
>> wrote:
>>
>>> What is the content of the network packets ?
>>>
>>> Regardless, I'll ignore software with that technologogy.
>>
> 
> The OP seems to be suggesting that whoever has access to the data captured
> by Ableton Link or the potential backdoor that link *might* enable would
> use it for nefarious purposes.

Ableton link is used to synchronize software and devices on a *LAN*.
It basically broadcasts BPM and song-position to the *local* network.

Link does not allow to synchronize devices on a WAN.

The complete source code is free (GPLv2) you can read it, no strings
attached.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] midi bindings -- was Re: ZASFX is mean with my Qtractor XML session files

[Robin Gareus]

On 07/08/2016 05:26 PM, Mark D. McCurry wrote:

> Last time I counted the total possible parameters given the default
> number of parts/kits/voices/etc there's a bit over 6,000,000 parameters.
> 
> Think about how big of a .ttl that would be :p
> 
> The way that MIDI learn works is:
> 1. you select one of these many parameters
>(Middle click or CTRL+right click in the fltk/ntk UI)
>(if you're in a version where this doesn't lauch correctly use
>zynaddsubfx-ext-gui osc.udp://localhost:PORT)
> 2. you send zyn an unbound MIDI CC
> 3. zyn creates an internal mapping from MIDI CC -> internal parameter
> 
> This isn't visible as a standard lv2/vst/etc parameter, so it's quite
> non-standard in that sense, but IMO it's a reasonable solution given the
> scope of zyn.
> 
> So, remove your doubt and enjoy the non-standard solution to this problem.

+1

setBfree uses exactly the same approach, with a slight difference is
step 2: it does not have to be unbound: one can re-assign in one step.
setbfree is nowhere near 6M parameters, but similarly large.

There was some idea floating around to expose plugin parameter bindings
to a host via LV2 Patch::Set/Get

IMHO that makes sense for effects which otherwise don't parse midi
itself, nor have any synth related concepts of programs or banks.

Note: Any parameter that can be automated on a timeline (exposed as
normal control-port) should never ever be set by a plugin itself via
midi-bindings of otherwise.  That'll lead to inconsistent parameters.

ciao,
robin




signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LV2 plugin host MIDI channel number detection

[Robin Gareus]

On 03/16/2016 03:03 AM, Yassin Philip wrote:
> 
> 
> On 03/16/2016 01:49 AM, Robin Gareus wrote:
>> On 03/16/2016 02:45 AM, Yassin Philip wrote:
>>
>>> But... How do other plugins do?
>> most listen to all channels.
> I meant, how do they do that? I suppose it's in the LV2 ttl file
> <https://bitbucket.org/xaccrocheur/kis/src/2d12ab34ff10c67a0f99fa562fa50560f19454a3/kis.ttl?fileviewer=file-view-default>,
> I'd like to know where to look in the LV2 docs, but I somehow confuse
> terms, port index, channel number..?

a lv2:InputPort, ev:EventPort;

uhm. Event Ports have been deprecated since years and were pronounced
End of Live over 2 years ago:
http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2014-January/000642.html

Please have a look at http://lv2plug.in/book/

HTH,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LV2 plugin host MIDI channel number detection

[Robin Gareus]

On 03/16/2016 02:45 AM, Yassin Philip wrote:

> But... How do other plugins do? 

most listen to all channels.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Multiple JACK servers connected in one host?

[Robin Gareus]

On 03/11/2016 05:53 PM, Jonathan Brickman wrote:
>>
> OK, I think I see what you are referring to: the switching nature of the
> client list, where the JACK server has to switch between.  And this is
> entirely why it helps to run multiple JACK servers on multiple
> motherboards, and why it will help to run multiple JACK servers on my
> box, because the client list reduces tremendously per JACK server.

I'm curious how did you reach that conclusion?

You either need to synchronize the multiple jacks or run them all
independently each jack instance with its own soundcard. In either case
the CPU will need to do at least as many context switches as running the
whole thing in a single graph.

In any case, the I don't believe the context switch overhead with only
19 clients is much of an issue here.


First thing I'd check here is the scheduler:
cyclictest -m -S -d0 -p80
is a good start. Leave it running for a while, the "Max:" at the end is
relevant, those are usec.  Ideally it'll not exceed 50 or so long term.

If you want to dig deeper, compile jack2 with --profile it can print
nice diagrams like
http://www.grame.fr/ressources/publications/Timing.pdf  including
wake-up times for each of the clients; then again this is fairly
advanced and the issue in your case is likely simpler.

I didn't follow recent yoshimi development, but last I looked it was
neither rt-safe nor very efficient. Some mutex/locks in the process
callback could well explain why your CPUs idles a lot and jack does not
work properly. Did you try recent zynaddsubfx?


2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Multiple JACK servers connected in one host?

[Robin Gareus]

On 03/11/2016 02:24 PM, Patrick Shirkey wrote:
> According to Jonathan his multiple cores are barely reaching 5% usage. How
> can JACK_DSP be so high when there is so much room left to play with if
> JACK2 is handling the parallelism correctly?
> 
> It seems similar to my car telling me that I am red lighting when I am
> only going 20km/hr in second.

The proper analogy here would be a Formula-1 car in Downtown Manhattan
during rush hour :)

Cheers!
robin

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Multiple JACK servers connected in one host?

[Robin Gareus]

On 03/11/2016 01:17 PM, Patrick Shirkey wrote:
> According to Jonathan's results he is finding a bottle neck with JACK DSP
> with a single server.

He reports that the bottleneck is his complete setup, I saw no evidence
that JACK is the bottleneck nor that the reason is the "single-server".
Maybe I missed some analysis related to that?

In the vast majority of cases raw CPU power is the least to worry about
in low-latency audio realtime graphs.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Multiple JACK servers connected in one host?

[Robin Gareus]

On 03/11/2016 08:03 AM, Patrick Shirkey wrote:
> If this cannot be fixed in JACK directly we should be able to spin up
> multiple instances on the same machine and have them play nice with each
> other.

and how would that be different from splitting the current graph in JACK
and not preform worse?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Realtime inter-thread communication

[Robin Gareus]

On 02/29/2016 03:38 PM, Sebastian Gesemann wrote:
> Hello fellow audio developers,
> 
> I've started writing a software synthesizer in C++ (using SDL2 for
> now) for kicks and giggles and ran into the problem of having the
> event loop thread that listens for keyboard events communicate with
> the audio callback.
> 
> Are there any recommendations for how to pass real-time events (note
> on, note off, etc) to such an audio callback? I figured, this is
> already a solved problem and that I could benefit from your
> experiences. Maybe you know of some nice open-source C++ queue
> implementation that is suitable in such a situation.
> 
> I could use some kind of "channel" (thread-safe bounded buffer
> implemented using mutexes and condition variables) but I'm not sure
> whether this is a good idea in this situation since the audio callback
> function should avoid unnecessary delays.

Mutexes are not a good idea.
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

The generic solution for cases like this is a lock-free ringbuffer.

Then again, ideally you'll get both Audio and MIDI in the same callback
to begin with. JACK provides this for example.


> I've also looked into LV2. If I implemented the synthesizer as LV2
> plugin, I would get around having to solve the inter-thread
> communication problem because it's the plugin host's responsibility.
> But to be honest I've found this API to be a bit intimidating and I'm
> not familiar with any LV2 host that would allow me to test such a
> plugin. Any recommendations? Ardour?

jalv, Carla, QTractor, Ardour..

A LV2 simple synth example can be found at http://lv2plug.in/book/#_sampler

HTH,
robin

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Midi Beat Clock to BPM

[Robin Gareus]

On 11/01/2014 08:10 PM, Clemens Ladisch wrote:
> hermann meyer wrote:
>> I try to fetch the bpm from the Midi Clock, and stumble over "jitter".
>>
>> How do you usually fetch the bpm from Midi Clock, any pointer will be 
>> welcome.
> 
> 
> 
> 
> MIDI clock is interesting, because deviations from the predicted clock
> frequency are either errors and must be suppressed, or are because of
> a change in tempo and must replace the old clock rate.
> 

A very good paper with example code:
 http://kokkinizita.linuxaudio.org/papers/usingdll.pdf
(ardour uses that approach to filter MTC, LTC and MClk)

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] xrun callback

[Robin Gareus]

On 09/03/2014 04:04 PM, Raphaël  BOLLEN wrote:
> Hello,
> 
> I'm trying to use jack_set_xrun_callback to be notified in my
> application of eventual xrun.
> 
> in the documentation of the function I see a note: that 'this function
> cannot be called while the client is activated'.
> 
> Does it mean that my client must call jack_set_xrun_callback before
> being activated 

Yes. First set the callback, and only later call jack_activate().


Two tiny jack clients which may come in handy:

 * jackxrun: report x-runs on the command line
 * busyjack: create artificial load

http://gareus.org/gitweb/?p=jackfreqd.git;a=tree;f=tools;
gcc -o jackxrun jackxrun.c -ljack
gcc -o busyjack busyjack.c -ljack

./jackxrun # reports xruns in the terminal
./busyjack 90 # will ramp things up to 90% DSP load (default is 50)

It can be used to create x-runs, yet it's not the same as a x-run from hw.

[..]
> It says return 0 on success. Does it mean the callback must succeed.

Your callback function must return 0.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Beta testers required...

[Robin Gareus]

On 07/24/2014 12:56 AM, Fons Adriaensen wrote:
> Anyone interested in beta-testing this please let me know.
> 
> 
> Zita-njbridge
> -
> 
> Command line Jack clients to transmit full quality
> multichannel audio over a local IP network, with
> adaptive resampling at the receiver.
> 
> Main features:
> 
> * One-to-one (UDP) or one-to-many (multicast).
> * Sender and receiver(s) can each have their own
>   sample rate and period size.
> * Up to 64 channels, 16 or 24 bit or float samples.
> * Receiver(s) can select any combination of channels.
> * Low latency, optional additional buffering.
> * High quality jitter-free resampling.
> * Graceful handling of xruns, skipped cycles, lost
>   packets and freewheeling.
> * IP6 fully supported.
> * Requires zita-resampler, no other dependencies.
surely it requires libjack - and probably libc, too :)


Hi Fons,

Wow, that sounds great.

I'm curious why you've made a standalone client out of this, rather than
fixing netjack. Is there any chance that this could become an internal
client (required for forwarding jack-transport)?

What is the use-case of directly resampling for network-transmission?
Are you running two jackd's at different sample-rates? And if not,
how does that differ from using netjack and resampling locally with
zita-ajbridge?

Could it be used to bridge two jackd's on localhost with different SR?

Why is it limited to 64 channels only?

Are there any plan to add support for jack-midi ports?

Does it set jack port-latencies properly (after resampling)?

I suppose I am interested in testing :)

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] LAC'14 video archive

[Robin Gareus]

Hi all,

The video recordings of the LAC'14 presentations have just been uploaded
to the conference website and are now directly linked from the archive:
http://lac.linuxaudio.org/2014/program


There are still a three videos missing and the workshop videos are also
yet to come. Currently they are also only available as vp8/vorbis/webm
(sorry IE and Safari users). But since it has been quite a while
already, we decided to not hold back the release of these already
finished videos any further.

Once the collection is complete, we will provide a .torrent. Meanwhile,
for those who prefer to download the videos incrementally, they are
accessible via rsync://linuxaudio.org/ [1].

Many thanks for Frank and Moritz to get those done in really outstanding
quality this year. Kudos to the complete stream-team.

enjoy,
robin - for the LAC'14 team


[1] example to get the 720p versions:
rsync -Pa --exclude "*360p.webm"   \
  rsync://linuxaudio.org/lac2014/  \
  lac2014/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] LAC'14 program announcement

[Robin Gareus]

Hi all,

We're excited about the upcoming Linux Audio Conference, featuring a
tightly packed diverse schedule with 77 events by over 100 persons!

The conference schedule has just been published at
  http://lac.linuxaudio.org/2014/program

Apart from presentations, there are workshops, a poster-session and five
concerts in 3 days. The 4th day of the conference is dedicated to an
excursion: http://lac.linuxaudio.org/2014/excursion a simple overview of
the complete schedule can be found in the printable version of the program.

If you want to attend and have not yet done so, please register at
  http://lac.linuxaudio.org/2014/registration

Looking forward to seeing you all in May at the ZKM.

yours truly,
robin - LAC'14 team
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] JACK latency API clarifications

[Robin Gareus]

On 02/20/2014 11:32 PM, Stefano D'Angelo wrote:
Hi Stefano,

You got this right.

> Hi all,
> 
> Let's say I have a client that introduces an amount of latency that's
> variable at runtime and potentially unbounded. From JACK's docs it
> seems that you need to recompute the min/max latencies in the latency
> callback that's called "by the server" whenever it feels like, but you
> can force that by calling jack_recompute_total_latencies (right?).

correct.

> The problem is, you are advised to call this last function only after
> calling jack_port_set_latency_range(), which you should only call in
> the latency callback, which may be called next month... am I dumb
> (probably) or is there a deadly loop?

It's called whenever the graph changes (e.g. port connections change) or
when some client invokes jack_recompute_total_latencies().

So whenever a setting in your app changes that affects the latency, call
jack_recompute_total_latencies(), which in turn will trigger the
callback set via jack_set_latency_callback(),  and there you set the
[new] port-latency(ies).

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Zita Resampler unexpected output

[Robin Gareus]

On 02/12/2014 09:34 PM, Robin Gareus wrote:
> On 02/12/2014 09:29 PM, André Garnier Coutinho wrote:
> [..]
>> over.inp_data = 0;
> [..]
> 
> You cannot use a NULL pointer. It needs to point to an array filled with
> zeroes.

mmh. I'm sorry.

I was too quck and wrong, again :(
zita-resampler-1.3.0/libs/resampler.cc:193 does catch that.

/me crawls back under his stone.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Zita Resampler unexpected output

[Robin Gareus]

On 02/12/2014 09:29 PM, André Garnier Coutinho wrote:
[..]
> over.inp_data = 0;
[..]

You cannot use a NULL pointer. It needs to point to an array filled with
zeroes.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Zita Resampler unexpected output

[Robin Gareus]

On 02/07/2014 11:49 PM, Robin Gareus wrote:

>> I'm attaching my code.
> 
> I'm attaching a quick diff :)

I'm sorry. It turns out, I only got this half right (wrong number of
samples to line things up). Just read the API documenation, explains it
all:
http://kokkinizita.linuxaudio.org/linuxaudio/zita-resampler/resampler.html

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Zita Resampler unexpected output

[Robin Gareus]

On 02/07/2014 11:26 PM, André Garnier Coutinho wrote:
> Hi Guys!
> 
> I was doing some tests to learn how to use zita resampler and I got an
> unexpected output. All the last positions of my output vector were 0 and I
> don't know why.
>
[..]
> Does anyone know what I am doing wrong?

Fons may have a detailed explanation. In code where I use zita-resampler
I do initially feed it with a cycle of zeroes.
Doing the same fixes the behaviour in your code.

see also /apps/zresample.cc
it also has a // Insert zero samples at start.

> I'm attaching my code.

I'm attaching a quick diff :)

Cheers!
robin

PS. over.setup(..., 16)  is rather poor quality.
--- a/main.cpp	2014-02-07 23:38:34.479692524 +0100
+++ b/main.cpp	2014-02-07 23:47:45.346424129 +0100
@@ -34,8 +34,22 @@
 		cout << "buffer[" << i << "] = " << buffer[i] << endl;
 	}
 
+
 Resampler over;
 over.setup(samplerate, n_over*samplerate, 1, 16);
+
+		/* initialize resampler */
+#define RSZ_INIT_SIZE (n_samples)
+		float *zeroes = (float*) calloc(RSZ_INIT_SIZE, sizeof(float));
+		float *scratch = (float*) calloc(n_over * RSZ_INIT_SIZE, sizeof(float));
+		over.inp_count = RSZ_INIT_SIZE;
+		over.inp_data = zeroes;
+		over.out_count = RSZ_INIT_SIZE * n_over;
+		over.out_data = scratch;
+		over.process ();
+		free(zeroes);
+		free(scratch);
+
 over.inp_count = n_samples;
 over.out_count = n_samples*n_over;
 over.inp_data = buffer;
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Linux Audio Conference 2014 - Call for Participation

[Robin Gareus]

[Sorry for cross-posting, please distribute]

We are happy to announce the next issue of the Linux Audio Conference
(LAC), May 1-4, 2014 @ ZKM | Institute for Music and Acoustics, in
Karlsruhe, Germnany.

  http://lac.linuxaudio.org/2014/

The Linux Audio Conference is an international conference that brings
together musicians, sound artists, software developers and researchers,
working with Linux as an open, stable, professional platform for audio
and media research and music production. LAC includes paper sessions,
workshops, and a diverse program of electronic music.

*Call for Papers, Workshops, Music and Installations*

We invite submissions of papers addressing all areas of audio processing
and media creation based on Linux. Papers can focus on technical,
artistic and scientific issues and should target developers or users. In
our call for music, we are looking for works that have been produced or
composed entirely/mostly using Linux.

The online submission of papers, workshops, music and installations is
now open at http://lac.linuxaudio.org/2014/participation

The Deadline for all submissions is January 27th, 2014 (23:59 HAST).

You are invited to register for participation on our conference website.
There you will find up-to-date instructions, as well as important
information about dates, travel, lodging, and so on.

This year's conference is hosted by the ZKM | Institute for Music und
Acoustics (IMA). The IMA is a forum for international discourse and
exchange and combines artistic work with research and development in the
context of electroacoustic music. By holding concerts, symposia and
festivals on a regular basis it brings together composers, musicians,
musicologists, music software developers and listeners interested in
contemporary music. Artists in Residence and software developers work on
their productions in studios at the institute. With digital sound
synthesis, algorithmic composition, live-electronics up to radio plays,
interactive sound installations and audiovisual productions their
creations cover a broad range of what digital technology can inspire the
musical fantasy to.

The ZKM is proud to be the place of the LAC for the fifth time after
having initiated the conference in 2003.

  http://www.zkm.de/musik

We look forward to seeing you in Karlsruhe in May!

Sincerely,
The LAC 2014 Organizing Team
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LV2] LV2: Communicate from the DSP to the UI

[Robin Gareus]

On 11/09/2013 08:10 PM, David Robillard wrote:
>> > I've just brushed it up a bit, removed all raw-atom write calls, added
>> > RDF attributes for channel-id, etc and also sanitized the drawing
>> > routine somewhat. pushed to
>> > 
>> >   https://github.com/x42/sisco.lv2
>> > 
>> > Now it is a proper example and should be about halfway towards your needs.
>
> Perhaps a good candidate for "official" (i.e. included) example?

eg-scope, sure, fine with me; but please give me a few days to add some
more comments to the source: elaborate on Atom-msgs and clearly note
that the scope display itself is horribly wrong design. It's actually a
perfect textbook example of what *not* to do:

* no thread sync. it redraws somewhat randomly
* it's neither accurate nor stable
* it displays raw samples (a proper scope should^Wmust not do that)
* the display itself just connects min/max line segments
* no labels, no scale, no calibration
* ...

maybe Aurélien is going to address some of these issues, and his project
will eventually be suited better for inclusion as official example.

Alternatively removing the drawing routine would IMHO be appropriate for
an example atom-vector communication plugin.

@Aurélien: are you planning to implement a trigger mechanism and/or
history? any plans to add up-sampling and interpolation? what about
markers and numerical readout?

best,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LV2: Communicate from the DSP to the UI

[Robin Gareus]

On 11/06/2013 04:21 PM, Aurélien Leblond wrote:

> @Robin: I'll defo have a look at the example you sent though, that
> looks like exactly the type of example I was looking for.

I've just brushed it up a bit, removed all raw-atom write calls, added
RDF attributes for channel-id, etc and also sanitized the drawing
routine somewhat. pushed to

  https://github.com/x42/sisco.lv2

Now it is a proper example and should be about halfway towards your needs.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LV2: Communicate from the DSP to the UI

[Robin Gareus]

Hi guys,

On 11/05/2013 06:48 AM, Michael Fisher wrote:
[..]
> 
> ForgeFrame frame;
> 
> AtomObject obj (forge.write_blank (frame, 0, object_type));
> forge.property_head (prop_type, 0);
> forge.write_raw (buffer, sizeof (float) * bufsize);
[..]

That works all right, but it's not proper LV2 Atom/RDF.
 - the receiver has no idea about the length
 - if the host-buffer overflows there's no way to re-sync
 - it cannot be interleaved with other DSP -> UI messages
 - `jalv.gtk -d ...` cannot parse it as RDF
 - ...

LV2_Atom_Vector is made for exactly that purpose.

from sratom/tests/sratom_test.c:

  lv2_atom_forge_property_head(&forge, eg_vector, 0);
  int32_t elems[] = { 1, 2, 3, 4 };
  lv2_atom_forge_vector(&forge, 4, forge.Int, sizeof(int32_t), elems);


 @Drobilla:
I think the last line is slightly wrong, it should be
  lv2_atom_forge_vector(&forge, sizeof(int32_t), forge.Int, 4, elems);
as per ns/ext/atom/forge.h

lv2_atom_forge_vector(LV2_Atom_Forge* forge,
  uint32_tchild_size,
  uint32_tchild_type,
  uint32_tn_elems,
  const void* elems)

not that it really matters because only (child_size * n_elems) is used.



Either way, you'll likely need
http://lv2plug.in/ns/ext/resize-port/#minimumSize as well if you're
going to pass large chunks of data around.


-=-=-


Anyway even if you make it work, I doubt that you'll have much fun:

Atom messages are written into a ringbuffer in the LV2host in the
DSP-thread. This ringbuffer is sent to the UI by another thread
(jalv.gtk and ardour use a g_timeout() usually at 40ms ~ 25fps), and
finally things are drawn in the X11 thread ie. gtk-main or qt's main.

Other LV2 hosts may do do things differently and you have no control
over it.

As much as like LV2 from a user's perspective and host integration. It
kinds sucks for visualizations. The only realistic way do to RT
*visualizations* (e.g. a scope) right is to bypass the host (use
instance access & a semaphore) and use openGL with vblank-sync using a
custom thread in the UI (drobilla is going to blacklist me now).

Synchronizing even one [audio] thread with the gfx-hardware is not
trivial. Default LV2 communication involves two or more, including some
threads that the LV2-host controls. -- It may be fun for someone to sort
this all out, but not me.

That being said I do like LV2 Atoms, event-queues, mapped URIs, and more
generally the CY-y way of LV2, though. It's very nice, robust and
elegant for control. Sometimes a tad overkill, but heck, therefore it's
portable, too.

However, if you want to write a proper scope, make it a jack application
- or wait for Fons to release zita-scope.


-=-=-

I did some tests a while ago, passing raw audio data inside an
LV2_Atom_Vector to the UI. I've just added an over-simplified scope UI
so that you see for yourself. unzip,
 make
 sudo make install PREFIX=/usr
 jalv.gtk http://gareus.org/oss/lv2/audiopipe
 # curse loudly
 sudo make uninstall PREFIX=/usr

Cheers!
robin


audiopipe.lv2.tar.gz
Description: GNU Zip compressed data
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Fwd: Measuring phase and frequency response of a filter.

[Robin Gareus]

On 11/05/2013 08:52 PM, Rafael Vega wrote:
> 
> Hi.
> I'm building a little ear training application for eqing for which I'm
> building some filter banks in puredata. Can someone point me to a practical
> way of measuring and plotting my filter's frequency and phase responses?
> Jack apps, pd patches or code should be fine.
> Thanks!

https://github.com/Ardour/ardour/blob/master/gtk2_ardour/fft.cc
Is what generates the effect analysis (frequency and phase response) in
Ardour.

The code is quite easy to [re]use. Just feed a delta impulse into your
filter, call FFT::analyze() with the result and you get two arrays:
power_at_bin[], phase_at_bin[] YMMV.

HTH,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] limiting email traffic

[Robin Gareus]

On 10/31/2013 05:32 PM, Fred Gleason wrote:
[..]
> Might we want to consider modifying this rule so as to apply to a
> dozen messages *in a given thread* per day?  I agree that, if one is
> doing that much shouting about a single topic, it'd probably be
> better to give it a rest.  :)

That was the initial intention. However it's much harder to do. The
current implementation is a few lines of bash. it does not look at the
content at all, just address and mail-headers as logged by the MTA.
Basically inotifywait mail.log; cut, sort, uniq, wc, test

You're welcome to provide a tool to do a better job. It's probably not
too hard in perl or python, but I did not consider it worth my time.

Before you get down to implement it however, consider volunteering as
list-moderator. I hazard a guess that it is effectively more efficient
to do things manually when it comes to more complex rules.

If interested please contact linux-audio-user-ow...@lists.linuxaudio.org
(which is not me).

robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] limiting email traffic

[Robin Gareus]

On 10/31/2013 04:19 PM, drew Roberts wrote:
[..]
> Have the lists history been mined to see how many "valuable" users violate 
> this proposed policy one some days? Perhaps they go a week and then have 20 
> posts in one day and  then go another week?

Mined, no. The problem here is the definition of 'valuable'.

I did elaborated a bit more on this when addressing the consortium about
this:

"I've checked some random samples and found that no reasonable[...]
discussion on the LA lists in the last 2 years required more than 5
posts per user per day."
Now that's still somewhat subjective.

The current settings are rather conservative. With these, only four
persons would have received warnings (two of them repeatedly) in the
last two years, and only one would have been temporarily banned (also
more than once).

Anyway we intentionally chose a short ban time (6h). The idea is not to
snub or censor. Just to let things calm down a bit.

None of the persons who'd have  triggered the warning are high-profile
developers or major contributors to linux audio software architecture or
ecosystem.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] limiting email traffic

[Robin Gareus]

On 10/29/2013 05:26 PM, Charles Z Henry wrote:
> On Tue, Oct 29, 2013 at 10:01 AM, Robin Gareus  wrote:
> 
>>
>> The system will be activated on 31/Oct/2013 if not vetoed. The actual
>> rate-limit may also be adjusted over time to reflect list-behaviour.
>>
>> yours truly,
>> robin
>>
> 
> So, I've got just today and tomorrow to thrash the server, huh?
> 

lol.

Trashing the server will not be easy, but even after today it will not
be too hard to pollute the email lists if you really set your mind to it.

Luckily malicious intent is much easier to handle for us.

It's the gray area that causes the email-list-admins headaches. Hence
this automated fair system. It basically just reminds and enforces what
should be common sense anyway: If you fail to get your message across in
~10 - possibly long messages - on a public forum, better sleep over it.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] limiting email traffic

[Robin Gareus]

Hi all,

Due to excessive posts - in particular on the linux-audio-user email
list, we are going to rate-limit the number of emails to

  13 emails per user per 24 hours

with direct follows-up replies to self counting twice.

It is not unreasonable to assume that a single user posting more than
12 emails per day is either involved in a heated flame-war or otherwise
disrupting reasonable discussion. Neither of which is acceptable on the
LA email lists.

We understand that some communication requires rapid exchange of many
small snippets and recommend users who need to regularly post short
messages many times per day to rather use services such as twitter, IRC
or simply private email. The LA email lists are mainly intended for
discussion, questions & answers, sharing and preservation of knowledge.
  Note that there are currently over 3000 persons subscribing to the LA
lists, every single email sent to the list will result in 3000+ forwards
and be archived in various places on the web.


Offenders will be notified with a warning message with the 10th email
within a day and after the 13th email temporarily banned for 6 hours
from further posting to the given email list.

Feel free to comment on this email here on this list, but official
inquires should be addressed to members of the consortium. See
http://linuxaudio.org/contact

The system will be activated on 31/Oct/2013 if not vetoed. The actual
rate-limit may also be adjusted over time to reflect list-behaviour.

yours truly,
robin

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] lv2 external UI -- was Re: LV2 Oscilloscope

[Robin Gareus]

On 10/11/2013 04:08 PM, Robin Gareus wrote:
> On 10/11/2013 02:28 AM, Harry van Haaren wrote:
>> On Thu, Oct 10, 2013 at 8:07 PM, Paul Davis 
>> wrote:
>>
>>>
>>> If a plugin uses one of them (the original) then Ardour will NOT delete
>>> the UI instance when it is closed.
>>> If a plugin uses the other (the version "forked"/"copied" by falktx) then
>>> Ardour WILL delete the UI instance when it is closed.
>>>
>>> Both specifications state that the UI is defunct and no longer usable
>>> after being closed:
>>>
>>>* After this callback is called, UI is defunct. Host must call
>>>* LV2UI_Descriptor::cleanup(). If host wants to make the UI visible
>>>* again UI must be reinstantiated.
>>>
>>>
>> Thanks for clearing that up: learning in progress on my behalf.
>> Cheers, -Harry
>>
> 
> To clarify this a bit and fill in the details:
> 
> *All this is only relevant for external UI.*
> 
> 1) URI: http://kxstudio.sourceforge.net/ns/lv2ext/external-ui

correction. the official URI is

  http://kxstudio.sf.net/ns/lv2ext/external-ui#

> 
> Ardour3.4 behaves according to spec, see the function documentation
> of void (*ui_closed)(LV2UI_Controller controller); in the header file
> http://kxstudio.sourceforge.net/ns/lv2ext/lv2_external_ui.h
> 
> 
> 2) URI: http://lv2plug.in/ns/extensions/ui#external
> 
> Ardour 2.X - 3.4 does not follow the spec regarding void (*ui_closed).
> It just hides the window and shows it again.
> 
> The reason for Ardour doing (2) differently is that it was agreed on by
> some developers that for many plugins re-initialization does not make
> sense (re-init can be CPU intense). Those devs updated the
> implementation but forgot or neglected to update the spec.
> 
> AFAIK it's also only Ardour that does not follow the spec. Other LV2
> hosts that support lv2plug.in#externalui may implement it as synonym to
> kxstudio#external-ui.
> 
> Otherwise the kxstudio#external-ui and lv2plugin#externalui are
> identical (with just a minor cosmetic difference that kxstudio defines a
> separate URI for the Host and plugin-widget).
> 
> In any case, external UI's should be avoided if possible, there are very
> few valid use-cases. Just use a 'normal' LV2 UI or let the host generate
> one.
> 
> ciao,
> robin
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] lv2 external UI -- was Re: LV2 Oscilloscope

[Robin Gareus]

On 10/11/2013 02:28 AM, Harry van Haaren wrote:
> On Thu, Oct 10, 2013 at 8:07 PM, Paul Davis wrote:
> 
>>
>> If a plugin uses one of them (the original) then Ardour will NOT delete
>> the UI instance when it is closed.
>> If a plugin uses the other (the version "forked"/"copied" by falktx) then
>> Ardour WILL delete the UI instance when it is closed.
>>
>> Both specifications state that the UI is defunct and no longer usable
>> after being closed:
>>
>>* After this callback is called, UI is defunct. Host must call
>>* LV2UI_Descriptor::cleanup(). If host wants to make the UI visible
>>* again UI must be reinstantiated.
>>
>>
> Thanks for clearing that up: learning in progress on my behalf.
> Cheers, -Harry
> 

To clarify this a bit and fill in the details:

*All this is only relevant for external UI.*

1) URI: http://kxstudio.sourceforge.net/ns/lv2ext/external-ui

Ardour3.4 behaves according to spec, see the function documentation
of void (*ui_closed)(LV2UI_Controller controller); in the header file
http://kxstudio.sourceforge.net/ns/lv2ext/lv2_external_ui.h


2) URI: http://lv2plug.in/ns/extensions/ui#external

Ardour 2.X - 3.4 does not follow the spec regarding void (*ui_closed).
It just hides the window and shows it again.

The reason for Ardour doing (2) differently is that it was agreed on by
some developers that for many plugins re-initialization does not make
sense (re-init can be CPU intense). Those devs updated the
implementation but forgot or neglected to update the spec.

AFAIK it's also only Ardour that does not follow the spec. Other LV2
hosts that support lv2plug.in#externalui may implement it as synonym to
kxstudio#external-ui.

Otherwise the kxstudio#external-ui and lv2plugin#externalui are
identical (with just a minor cosmetic difference that kxstudio defines a
separate URI for the Host and plugin-widget).

In any case, external UI's should be avoided if possible, there are very
few valid use-cases. Just use a 'normal' LV2 UI or let the host generate
one.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LV2 Oscilloscope

[Robin Gareus]

On 10/10/2013 08:37 PM, Lars Luthman wrote:
> I would just bypass the LV2 host altogether and use shared memory to get
> the audio data to the GUI. This is what the DSSI plugin does. This means
> that it will not work if the plugin and the GUI are running on separate
> machines, but that seems to be pretty rare.

These days it not as rare as it used to be.

A scope is just 1D - say 1024 pixels width -> 1K values that need to be
transmitted from the back-end to the UI. No need to use shared memory,
really.

The only reason for using shmem would be transmitting _all_ the raw
audio-data for upsampling in the UI-thread[1]. But even so, 1.5 Mbit/sec
is nothing these days. Besides, up/down-sampling requires a ringbuffer
anyway, and shmem won't buy you anything.

Message-passing (LV2 Atom messages) can go directly into the UI's
ringbuffer (no extra copy) and will allow the UI to run remotely.

2c,
robin

[1] Upsampling can be CPU heavy, but since it's for display only, it
should not cause DSP load -> delegate to UI-thread.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A more efficient way to detect INF and/or NAN in a block of samples

[Robin Gareus]

On 10/06/2013 09:07 PM, Kjetil Matheussen wrote:
> But brainstorming further, it probably works to combine the peak finding 
> routine
> (which is run on all signals) with the nan/inf-detection:

+1

BTW compile with -ftree-vectorizer-verbose=7 to check what gcc does.

If you're looking for something ready-made, there are SSE, and altivec
asm routines for mixing buffers and calculating the peak value in
ardour. Have a look at libs/ardour/*.s, libs/ardour/mix.cc and
libs/ardour/ardour/mix.h

GPL and everything, thanks to Sampo IIRC.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A more efficient way to detect INF and/or NAN in a block of samples

[Robin Gareus]

On 10/06/2013 01:34 PM, Kjetil Matheussen wrote:
> I want to detect INFs and NANs in my DSP graph to avoid having
> them spread and cause various trouble.
> 
> Here is the straight forward way:
> 
> int i;
> for (i=0;i   if (!isfinite(samples[i])) break
>
> if(i!=num_samples)
>   error();
> 
> But is this as efficient as we get it?

Probably. Unless you start to dive into CPU specifics and wander off to
assembly.

> I'm wondering if comparing samples using for instance SIMD
> instructions, for instance, could make it around 4 times faster,
> Something like this:
> 
> for(i=0;i   if(samples[i]!=samples[i]))
>  break;
>
> where the samples[i]!=samples[i] test would succeed

You probably already know that, but be careful with this when using
optimizations with this comparison. -ffast-math may void IEEE compat.

> if it was a nan or inf, since INFs and NANs don't behave normally.
>
>
> I don't think this particular example works though (?),
> but perhaps something similar could?
> 
> Anyone doing something like this?

In my case it's not only about detecting, but also flushing them to
zero. Depending on what is appropriate for DSP at hand (meters.lv2) I
settled on using math.h's isnan(), !isfinite() or simply adding
something (to minus infinite).

While that's probably not optimal it is portable and architecture
independent, and I don't notice any significant DSP load caused by it.


BTW gcc does not vectorize the isnan/isfinite loop that you've posted:
"control flow in loop" (i386, gcc 4.7.2).  No dice when replacing the
break statement in the loop with  v |= isfinite(); either.  But it
unrolls the loop at least.

Another idea: add the signal (using SSE). If one of the summands is NaN,
the result will be Nan. -- that should effectively take less CPU
(assuming that NaN is non the common case).

brainstormingly yours,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] vu-meter DSP

[Robin Gareus]

On 07/27/2013 04:19 PM, Fons Adriaensen wrote:

> The actual value used is found by measuring the
> result, which is the only correct way.

OK. there's that :)

How did you measure it? Did you plot the output of the filter for
various input signals?  or fit the coefficient to some data?

> [..]

Many thanks for the detailed explanation!



FWIW, I took a somewhat empirical approach: feed 4 VU meters with the
same input, video-tape it and step the video frame-by-frame:

  1) hardware from a PreSonus TubePre
  2) http://www.lsraudio.com/lvlmeter.html
  3) http://www.pspaudioware.com/plugins/tools_and_meters/psp_2meters/
  4) Ardour 3.3-63 (jmeters-0.4.1 code)


(I first sure jmeters and ardour3's use of the code show identical data
on a linux-box. ..but I did not bother to compile jmeters on OSX where
the tests run using AU effects for (2), (3) )

All meters are set to -18dBFS = 0dBu,  0dBu == 0VU

(1) Has an incorrect deflection to start with. -18dbFS 1KHz sine wave
calibrated to 0VU; then changing the volume by +-3dB deflects the meter
by about -7dB, +4dB, besides it overshoots like hell.

one down.

(2) rises way to fast and falls off too slow. It also overshoots maybe
10%. On the upside it has a neat reflection of my non-existent
living-room windows in the meter-glass which easily makes up for that :)
see http://robin.linuxaudio.org/tmp/vu-011.webm

..another one out.

(3) looks generally promising - but a simple sine-sweep  30second
20Hz-20kHz at -18dBFS shows some issue: Around 5kHz, The PSP2 meter is
off by -2VU. see http://robin.linuxaudio.org/tmp/vu-010.webm

The VU-meter specs say "[for a sine wave] the [meter] reading should not
depart from the reading at 1kHz by more than 0.2 dB from 35 Hz to 10 kHz
[..]"


which leaves us with...Congrats Fons.


Here's a series of various sine-waves and a kick-drum sample going into
(3) and (4). Interestingly jmeters' algorithm is always a tad below the
PSP meter. But that is somewhat consistent with the
band-pass-filter-like artefact that the PSP meter shows at ~5kHz. ie.
the PSP meter emphasizes lower frequencies:

  http://robin.linuxaudio.org/tmp/vu-008.webm

..and some Beethoven, just for the fun of it :)
  http://robin.linuxaudio.org/tmp/vu-001.webm



> Why such a dinosaur meter in Ardour ? You'd be better off with
> a DIN PPM or a K-meter

Those already in there and working just fine.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] vu-meter DSP

[Robin Gareus]

Hi Fons,

Would you mind explaining how the vumeterdsp.cc from jmeters works?

In particular how you arrive at the filter-constant:

 _w = 11.1f / fsamp;

With the DSP using a 2nd order low-pass filter, and since VU should have
an integration-time of 300ms, I'd have though it should rather be:

 _w = (1.0 - exp(-2.0 * M_PI / 0.3 / fsamp)) / 2.0;

for large values this can be approximated by _w = 10.468 / fsamp;

What am I missing?

-=-=-=-

I suppose the gain is arbitrary, seeing as it is mapped to a GUI element
without any numeric display, anyway. But is there something special about:

  _g = 1.5f * 1.571f;

1.5 * M_PI/2 ?? ie 90 degree deflection? But why the 1.5?

-=-=-=-

The context of all this is re-using your code to implement a VU meter in
Ardour3. For reference, the source-code is at
https://github.com/Ardour/ardour/blob/master/libs/ardour/vumeterdsp.cc

Some experienced beta-testers contested the ballistics of the meter and
I'm trying to get to the bottom of it...

Since this might be of general interest, I'm CCing LAD.

thanks in advance,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] New Jack / LV2 Host with socket support

[Robin Gareus]

On 05/28/2013 05:04 PM, Bruno Gola wrote:
> On Tue, May 28, 2013 at 10:53 AM, Thijs van severen
>  wrote:
>> hi all
>>
>> a question about this host app:
>> would this allow me to control the calf LV2 plugins using an external midi
>> controller ?
>> (map a midi 'knob' to a LV2 parameter)
> 
> we have plans to support a midi-mapping feature, but not now :(
> 
> []'s,
>

Can you connect one plugin's control-out to another plugin's control-in?

..then you could use a LV2 plugin to do the midi-mapping.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] wiki consolidation linuxmusicians.com & linuxaudio.org

[Robin Gareus]

Hi all,

Just a quick head's up: linuxaudio.org and linuxmusicians.com have
joined forces. Today Arnout and me have started to consolidate the wiki:

http://wiki.linuxmusicians.com has been merged into
http://wiki.linuxaudio.org/

Many thanks to all who have contributed to and helped maintaining the
content over the past years! Your efforts are very much appreciated.

There are still a few open ToDo items to be sorted out. In case you
would like to help, please see
  http://wiki.linuxaudio.org/wiki/migrationprogress

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM support: progress, wishlist

[Robin Gareus]

On 05/21/2013 12:13 AM, geoff wrote:
> conversations with the one known in this thread as rosea.grammostola 
> 
> What is that supposed to 
> mean Paul?
> 
> g

It means "rosea.grammostola" is not his real name :)

and please don't top-post.
thanks,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] simple silence detection tool

[Robin Gareus]

On 02/10/2013 06:57 PM, Jeremy Hansen wrote:
> 
> On Feb 10, 2013, at 8:16 AM, Robin Gareus  wrote:
> 
>> On 02/10/2013 08:38 AM, Jeremy Hansen wrote:
>>>
>>> I'm looking for a simple tool where I can point it at an http audio
>>> stream, define a number of seconds to detect silence and exit with a
>>> non-zero status if silence is detected.  It seems like this should be
>>> easy but I've been search high and low for such a utility and nothing
>>> simple exists.  Unfortunately I'm not much of a developer, but this
>>> doesn't seem like it would be that difficult.  Maybe it's harder than
>>> I think, hence no tool that I can find.
>>
>> https://github.com/x42/silan may do the job. It prints ranges or silence
>> in a file or stream (incl. mp3,aac,wma,ogg,m4a,.. decoding and http,
>> rtmp stream support thanks to libav/ffmpeg). It is used by airtime
>> (sourcefabric's radio) to highlight silent ranges.
>>
>> silan -t 0.1 -s -60d "http://mp2.somafm.com:9016"; \
>> |  grep -quiet "Sound Off" \
>> && echo " do something"
> 
> This is strange.  This works, but I'm unable to grep the output and I'm not 
> sure why.  If I pipe to grep, I get nothing.  I tried redirecting stderr to 
> stdout and doesn't seem to work.
> 
> [jeremy@serv src]$ ./silan -t 2.0 -s -40d 
> "http://live.skidrowstudios.com:8000/live";
> Info: signal threshold: 0.01 ^= -40.000dBFS
> 0.069569 Sound On
> 15.814150 Sound Off
> 
> Doing the same test:
> 
> [jeremy@serv src]$ ./silan -t 2.0 -s -40d 
> "http://live.skidrowstudios.com:8000/live"; | grep "Sound Off"
> Info: signal threshold: 0.01 ^= -40.000dBFS
> 
> 
> I get nothing.
> 
> Thanks
> -jeremy

long lost reply.

I cannot reproduce this.

It may have be related to (A) using an endless live-stream + (B) stdout
pipe caching.  I've just added a flush() command.

HTH,
robin

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Fwd: Scheduled maintenance outage

[Robin Gareus]

Hi all,

This weekend, starting a midnight (EST), Saturday morning (Mar 9), the
Systems Support Group at Virginia Tech has scheduled storage maintenance.

The storage that supports linuxaudio.org will be unavailable from
midnight until noon Saturday (EST) and hence the server will be offline.

thanks for your understanding.
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] JACK and CPU stress testing

[Robin Gareus]

On 03/01/2013 12:41 PM, Harry van Haaren wrote:
> Hey all,
> 
> I'm currently attempting to stress test my setup of  -rt kernel, rtirq
> scripts, and a Jack client program I've been working on.
> So my idea is to create a script that runs the programs, and also a
> cpu-load generating program (cpuburn or alternative).

There's a tool to cause jack DSP load:
 http://subversion.ardour.org/svn/ardour2/branches/3.0/tools/jacktest.c
which may or may not come in handy.

I've hacked it somewhat for testing CPU freq scaling a while ago:
 http://gareus.org/gitweb/?p=jackfreqd.git;a=blob;f=tools/busyjack.c

> Then collecting stats based on Xruns, % DSP load, etc.

drobilla and me did a similar analysis for LV2 plugins. Basically
measure the time it takes to process N samples for various block-sizes
and input data. The total execution time is only significant for a
single machine, however we were interested in variations (error bars).

If processing always takes the same amount of time per sample and is
independent of the input data, the algorithm is very likely RT safe.
Furthermore if there is no significant relationship to block-size that's
even better.

The scripts and data is available at
  http://drobilla.net/2012/08/22/benchmarking-lv2-plugins/


> I intend to show (trough brute force) that an application is RT capable on
> machine X with a latency of Y ms.
> Of course this won't be 100% representative, but the stats will show some
> RT-safe-ness.
>
>
> Has anybody done this kind of profiling / stress testing with JACK before?
> Hints / tips / advice / etc welcomed! -Harry
> 
> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] So what do you think sucks about Linux audio ? OP reply.

[Robin Gareus]

On 02/10/2013 03:43 PM, Dave Phillips wrote:
> Greetings,

Hi Dave,

> I've spent this morning reading through the ~200 replies to the topic.
> IMO the thread has devolved gracefully and I have the information I was
> looking for.

I've been waiting for that to say: I can find nothing that sucks about
Linux Audio ('xept maybe ~200 w[h]ining users :))

Looking forward to your article,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] simple silence detection tool

[Robin Gareus]

On 02/10/2013 08:38 AM, Jeremy Hansen wrote:
> 
> I'm looking for a simple tool where I can point it at an http audio
> stream, define a number of seconds to detect silence and exit with a
> non-zero status if silence is detected.  It seems like this should be
> easy but I've been search high and low for such a utility and nothing
> simple exists.  Unfortunately I'm not much of a developer, but this
> doesn't seem like it would be that difficult.  Maybe it's harder than
> I think, hence no tool that I can find.

https://github.com/x42/silan may do the job. It prints ranges or silence
in a file or stream (incl. mp3,aac,wma,ogg,m4a,.. decoding and http,
rtmp stream support thanks to libav/ffmpeg). It is used by airtime
(sourcefabric's radio) to highlight silent ranges.

silan -t 0.1 -s -60d "http://mp2.somafm.com:9016"; \
|  grep -quiet "Sound Off" \
&& echo " do something"
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] linuxaudio.org scheduled maintanance

[Robin Gareus]

Hi all,

I'm not quite sure how to interpret this, but it sounds like
linuxaudio.org will be offline for a short time (failover period) coming
Saturday January 12th 8am EST.

 Original Message 

Just wanted to make sure you were aware of the upcoming maintenance this
Saturday.

Maintenance for the central storage system known as minnow.cc.vt.edu is
schedule for Saturday, January 12 starting at 8am. Several hardware
components in the filer head needs to be replaced. Since this is a
cluster storage system, the maintenance will be performed in failover
mode, so minnow services will continue to be available. During the
failover, services will pause until the failover is complete.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] List moderation

[Robin Gareus]

On 01/07/2013 07:48 PM, Marc-Olivier Barre wrote:
> 
> PS: as you might have seen, Robin was faster than I and turned on the
> guys moderation bit. I would have gone for a pure ban, but hey ! Robin
> is a nicer guy than I am I guess :D

I'm not the chosen moderator to make such a decision. Turning on
moderation was a stopgap solution to calm things down.

Even though some parts of the KvR thread are kind of entertaining, I do
support an outright ban. Ove's choice of language and personal insults
is completely inappropriate for LAD.

2c,
robin

PS. note that Ove still receives email to this list.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] What KvR didn´t understand.

[Robin Gareus]

On 01/07/2013 06:05 PM, Ove Karlsen wrote:
> Wow I think I can actually feel your anus opening up, and getting ready
> for toiletsex.

Not only is this off-topic, but language like this is totally
unacceptable on LAD.

Until further notice, emails from you to LAD will need to pass moderation.

Peace Be With You.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Announcing PHASEX-0.14.96

[Robin Gareus]

On 12/30/2012 05:42 AM, William Weston wrote:
> Happy New Year!
> 
> Yes, your eyes are working correctly.  This is v0.14.96.  Some things
> are worth the wait. 

Certainly! Congratulations on this release. It rocks!

I'm far from getting to the bottom of the rabbit hole, but playing
around with phasex 0.14.96 is fun!

[..]

> Until then, a request goes out for build
> reports from other distros, especially Debian/Ubuntu, Arch, and Mint.

It compiles cleanly and works just fine on debian.

There's single compiler warning, nothing major, really:

midi_event.c: In function ‘queue_midi_event’:
midi_event.c:140:47: warning: pointer targets in passing argument 1 of
‘g_atomic_int_compare_and_exchange’ differ in signedness [-Wpointer-sign]
/usr/include/glib-2.0/glib/gatomic.h:45:10: note: expected ‘volatile
gint *’ but argument is of type ‘volatile unsigned int *’

[..]

> So what do we do, now that the world didn't end?
> Let's make some music!

I suggest to announce this on linux-audio-announce, too.

keep up the good work,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Jack dropping connections ?

[Robin Gareus]

On 12/27/2012 10:40 PM, Fons Adriaensen wrote:
> On Thu, Dec 27, 2012 at 10:03:52PM +0100, Robin Gareus wrote:
>  
>> Is it a static setup or are there apps that run occasionally and
>> create/release jack ports from time to time?
> 
> All apps run continuously, but some connections are made/unmade
> as required. However the connections that mysteriously disappear
> are between two apps which only have fixed connections, in casu
> the outputs of a multichannel player and the inputs of the wfs
> mixer app. There are 20 channels from the player to the mixer
> numbered 1..20, in both cases all but 6,7,8 were disconnected. 

I assume both apps are custom made, right?
Can you run them in valgrind? Could be some memory issue..
Other than that I have no idea.

>> Which version of jack1?
> 
> 0.121.3

There have been many changes since;  0.121.4 is in git and there's more
commits since then, too. but skimming the git log none are related to
the issue at hand.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev