On ebay I see a bunch of Biamp products with AVB support. While their
products seem to be more conference room oriented, I keep wondering
about using them with Linux, possibly for monitor management.
I know I've seen people talk about using AVB with Motu products, but I
don't think I've ever seen anyone mention using AVB with other products,
such as Presonus, Biamp, or macOS.
I just want audio networking to be accessible, and AVB looks like it is
the closet to being so.
I've just see that January's one is a free-for-all, so pretty much anything
goes.
Let's see a few Linux musicians on there!
--
Will J Godfrey {apparently now an 'elderly'}
Your message to the Linux-audio-user mailing-list was rejected for the following
reasons:
The message is not from a list member
The original message as received by Mailman is attached.
Ratatouille is a Neural Model loader and mixer for Linux/Windows.
This release introduce a normalization option for NAM models and
fix a issue with the normalization (a.k.a loudness compensation) of IR
Files (thanks to @avanzzzi )
Ratatouille allow to load up to two neural model files and mix there
output. Those models could be [*.nam files](https://tonehunt.org/all) or
[*.json or .aidax files](https://cloud.aida-x.cc/all). So you could
blend from clean to crunch for example, or, go wild and mix different
amp models, or mix a amp with a pedal simulation.
Ratatouille using parallel processing to process the second neural model
and the second IR-File to reduce the dsp load.
The "Delay" control could add a small delay to the second model to
overcome phasing issues, or to add some color/reverb to the sound.
To round up the sound it allow to load up to two Impulse Response files
and mix there output as well. You could try the wildest combinations,
or, be conservative and load just your single preferred IR-File.
Each neural model may have a different expected Sample Rate, Ratatouille
will resample the buffer to match that.
Impulse Response Files will be resampled on the fly to match the session
Sample Rate.
Project Page:
https://github.com/brummer10/Ratatouille.lv2
Release Page:
https://github.com/brummer10/Ratatouille.lv2
Hi Chris,
thank you for your answer!
> > I didn't have these problems under jack2, but then the RME was also
> > connected to the Scarlett via TOSLink, so there was only one interface
> > visible to the system.
>
> That is the difference. When you have two interfaces either they must have the
> sample clocks synchronized using hardware (e.g. word clock connection between
> the devices, or possibly Toslink if the device can be configured that way), or
> you must use software resampling.
> Errors during the software resampling is likely the cause of the noises you
> hear.
That's a good point. I now use the RME as the clock master, the Scarlett is connected via TOSLink only for syncronisation and an Octo PRE 8 is connected via Wordclock BNC from Scarlett.
But does Pipewire somehow knows that the two interfaces (RME and Scarlett) are synchronized and there is no need for resampling?
>
> > I therefore suspect that it is a problem with the
> > hard disk usage, as I can't think of any other reason.
>
> That is the least likely problem. Pipewire does not use the hard disk, and if
> there were a problem with hard disk access by the audio application it would
> result in underrun warnings.
>
> > not found a way to optimize hard disk access and I don't even know if this
> > is done directly by Pipewire or if one of the usual libraries is used for
> > this.
>
> Pipewire does not access the hardisk so not related at all to pipewire
> libraries.
I admit, this was a stupid idea. I was thinking about too many disk interrupts which may disturb interrupts for the soundcards.
But the first is of course completely out of control if pipewire.
Changing the number of processors which does the disk io in Mixbus nearly solved the problems and the latest update of Mixbus let it completely disappear.
>
> > Have you seen this phenomenon before or do you have any ideas what
> > else I can try?
>
> How have you configured the two devices in Pipewire?
Both are configured as pro_audio cards. Sample rate is 48k and buffersize is 1024 samples.
>
> Are you using the pipewire-jack interface to access the pipewire server as a
> JACK server? If so you could try configuring pipewire so that only the RME is
> accessed by pipewire, the Scarlett is ignored by pipewire, and then use
> zita_a2j and zita_j2a to access the Scarlett as a resampled device.
Yes, I use the pipewire jack libraries. Resampling hopefully is not needed anymore.
> Was there some reason you did not leave the Scarlett connected using Toslink?
Yes, if I do mixing / recording stuff I do have 2 more channels and I do not need to switch on the Focusrite if I don't do mixing stuff. RME and my monitors are enogh if I only want to listen to music..
Thanks for your suggestions
Holger
--
Holger Dehnhardt
holger(a)dehnhardt.org
https://www.dehnhardt.org
--
Holger Dehnhardt
holger(a)dehnhardt.org
https://www.dehnhardt.org
Hello all,
The purpose of this post is to gather some opinions on the
use of 'tape distortion' plugins.
The way an analog magnetic tape recorder distorts the signal
is quite complicated. The non-linear response is mainly due
to the hysteresis of the magnetisation process, and how this
interacts with the HF bias added to the recorded signal.
Simplifying things a bit, as the tape moves past the recording
head and away from it, it goes through several cycles of an
hysteresis loop with decreasing amplitude, and it finally
converges to some value more or less proportional to the signal.
The bias signal itself does not remain on the tape, or at most
at a very low level.
The same process but with just a very high level HF bias is
used to erase the tape.
Simulating this accurately is quite complicated, and very CPU
intensive. The sample rate must be at least twice the bias
frequency (around 100 kHz for 'pro' equipment) and for each
sample you need to evaluate the hysteresis loop up to a hundred
times (depending on tape speed) to simulate the convergence.
Over the past few months I've written the code to do this,
with the aim to present a useful 'tape emulation' plugin
at the next LAC. It uses a somewhat simplified form of the
Preisach algorithm for the hysteresis.
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/preisach-model.pdf>
But the first results are somewhat sobering.
Have a look at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/tapesaturation.png>
This shows the tranfer function (recorded magnetic signal as
a function of the input) for three values of the HF bias.
The blue line is what you get without bias. It result in a
very smooth saturation for high level signals, but a low
amplitude signal will be severly distorted due to the flat
region around zero.
As bias level is increased, this effect is reduced and the
low level gain increases up to some maximum. This is shown
by the orange curve.
The recommended way to set the correct bias level is to
further increase it until the small signal gain is reduced
by a few dB (typically 1 or 2 dB, depending on tape type).
This is shown by the green curve.
The central part of this is very linear (less than 1% THD).
But now the smooth saturation is almost transformed into
hard clipping. The sharp bend in the curve occurs when the
signal amplitude is higher than the bias amplitude.
The only effect that remains in a complete simulation is
the result of the EQ applied to the signal to be recorded.
Higher frequencies have a 'self erasure' effect (which is
nicely reproduced by the simulation) and so need to be
amplified. The net result is that they will saturate at
a lower input level.
How much EQ is required depends mainly on tape speed, higher
speeds need less. At the most popular 'pro' speed (381 mm/s)
this would be something around 10 dB at 10 kHz. At the higher
(762 mm/s) speed typically used for 'master tapes' it's just
a few dB.
So what does effectively remain of the 'smooth saturation
and compression' that is claimed to give tape recording its
magical 'warm' character ? Is it just a myth ?
I also simulated the green curve directly without going
through the complicated full simulation, and honestly,
to me that sounds just the same. And unless you really
use very high levels (much more than would actually be
used) the net effect is marginal. Maybe the hard clipping
can be useful when applied to individual tracks (e.g.
drums or bass), but then there are much simpler ways
to do this than 'tape emulation'.
Comments invited !!
Hi.
What do I need to know going forward trying to switch to Pipewire on a newer
machine? I skipped PulseAudio for several reasons.
I am basically using plain jackd with the tools like jack-lsp and
jack-connect.
from the command-line. That was relatively simple, since
I would specify the desired device on the jackd command-line,
and that was basically it. How do I use Pipewire without a graphical
control panel, practically speaking?
In particular:
* How do I select the desired device to use?
(Typical laptop + docking station setup easily has 2 sound cards these
days...)
* What is the equivalent of jack-connect and jack-lsp, i.e. how do I
connect clients to eachother and to a hardware output?
* Do I have to care about volume controls, which I didn't have to
previously with jackd since I would adjust volume on the clients?
--
CYa,
⡍⠁⠗⠊⠕
This is a relatively minor bugfix release. However there are some other general
improvements included. We've been steadily updating the code, to make it meet
current standard, but (hopefully) doing so in a way that improves performance
but makes no detectable difference to the actual sound.
--
Will J Godfrey {apparently now an 'elderly'}
