Linux-audio-user

linux-audio-user@lists.linuxaudio.org

20 participants
20684 discussions

Re: Pipewire hard disk usage (presumably)

by Holger Dehnhardt

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

1 year

Tape emulation - is it worth the effort ?

by Fons Adriaensen

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

1 year

Pipewire without a GUI?

by Mario Lang

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, ⡍⠁⠗⠊⠕

1 year

Yoshimi V 2.3.3.2

by Will Godfrey

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

1 year

Pipewire hard disk usage (presumably)

by Holger Dehnhardt

After the second move this year, I've finally started to set up my home studio properly again. (Ubuntu 24.04.1 LTS, Mixbus, RME ADI-2 Pro for monitoring, Focusrite Scarlett 18i20 2nd generation for integrating analog hardware) Since I've also updated Ubuntu, I've switched my workstation to Pipewire, as I've had quite good experiences with it on my laptop and running several audio interfaces in parallel is quite problematic. My first attempt with a smaller project (17 audio tracks) ran without any problems. My second attempt with a medium-sized project (~30 audio tracks), however, is driving me to despair. I have a DSP load of 50-60%, no buffer underruns but constant stuttering and occasional beeping. The log says the following Nov 12 22:37:13 muse pipewire[2048]: spa.alsa: hw:4c: snd_pcm_mmap_commit error 1022 514 1022: Data transfer interrupted (broken pipe) Nov 12 22:37:24 muse pipewire[2048]: spa.alsa: hw:4c: follower delay:873 target:1536 thr:1024 resample:1, resync (2 suppressed) It is interesting that when I start the safe mode in Mixbus, i.e. all effects are switched off, I have a DSP load of 10 percent and the stuttering and beeping is just as present. I don't have any analog hardware connected at this stage, so I read all tracks directly from disk and send them stereo to the RME interface. 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. I therefore suspect that it is a problem with the hard disk usage, as I can't think of any other reason. Unfortunately I have 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. Have you seen this phenomenon before or do you have any ideas what else I can try? Thanks for any suggestions! Holger -- Holger Dehnhardt holger(a)dehnhardt.org https://www.dehnhardt.org

1 year

ALSA output error (snd_pcm_open): Device or resource busy?

by Peter P.

Hi list, wanting to output audio from two applications at the same time using ALSA and not ~/.asoundrc in place, I am getting the following error for the second application (mpv) wanting to access the soundcard: ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave [ao/alsa] Playback open error: Device or resource busy [ao] Failed to initialize audio driver 'alsa' Could not open/initialize audio device -> no sound. Querying my system for devices using $ arecord -L I get (amongst other interfaces and cards): default hw:CARD=PCH,DEV=0 HDA Intel PCH, ALC269VC Analog Direct hardware device without any conversions plughw:CARD=PCH,DEV=0 HDA Intel PCH, ALC269VC Analog Hardware device with all software conversions I remember that the hw: devices may not allow simultaneous access, but the plughw: might. So will it help to declare the plughw:CARD=PCH,DEV=0 as the "default", and how would I go about to do so? https://www.alsa-project.org/wiki/Asoundrc indicates I should setup dmix but I somehow wonder if/why the above doesn't work out of the box without an .asoundrc? Thanks for all ideas! Peter

1 year

Rosegarden 24.12 Released

by Lorenzo Sutton

Forwarding to LAU in case there are interested users who are not on the Rosegarden mailing list ;-) -------- Forwarded Message -------- Subject: [Rosegarden-user] Rosegarden 24.12 Released Date: Wed, 4 Dec 2024 14:17:27 -0500 From: Ted Felix <ted(a)tedfelix.com> To: rosegarden-user <rosegarden-user(a)lists.sourceforge.net> ====== ROSEGARDEN 24.12 RELEASED ====== The Rosegarden team is proud to announce the release of version 24.12 of Rosegarden, a MIDI sequencer that features a rich understanding of music notation along with basic support for digital audio. http://www.rosegardenmusic.com/ Included in this release... ===== Bug Fixes ===== * LV2: Fix link problem with no gtk2. [2e168f0d] * LV2: Add lv2 check for GUI library ok. [9cb306b3] * Manage MIDI Banks and Programs dialog now allows the same bank MSB/LSB to be used for percussion and non-percussion banks on the same device. Bug #1692. * Fix wrong ports being assigned on file load. Bug #1687. [663099cc] * Fix autoscroll and highlighting behavior with multiple segments on a track. Bug #1672. * Fix missing scroll bar on Instrument Parameters Bank dropdown. Bug #1695. [295a2f7a] * Fix "turn repeats into copies" misses last segment. Bug #1696. [afcf2f0e] * Fix shortcut order ignored. Bug #1702. [b1272a6d] * Fix unexpected cursor position when moving from note to note on a bar with a clef or time signature. Bug #1704. [215b9d27] * Fix unexpected translation of bank and program names. Bug #1705. [6dbd6bcd] * Fix unexpected Save As... directory. Feature #522. [15db9d10] * Fix broken tempo line in tempo ruler after adding a time signature change. Bug #1706. [6a7ef89e] * Fix "Modify MIDI Filters" dialog does not mark document as changed. Bug #1707. [4e505977] * Fix LV2 sfizz plugin support. [8fce0614] * Fix group box formatting issue in native/light theme. Bug #1678. [d2df6376] * LV2: Fix crashes and locking related to atom buffers. [95b09722] [be37b31e] ===== New Features ===== * Make MIDI File Division value configurable for Export. GH #9. [991e4839] * WAV export of audio and soft synth tracks. File > Export > Export WAV File... [5b4d109e] * Apply interpretations to more than one segment. Segment > Interpret... Feature #517. [b8a243a5] * LV2 support has been promoted to beta. [a602850c] * Advanced Looping has been promoted out of beta. [25bdbf69] ===== General Improvements ===== * Manage MIDI Banks and Programs dialog is now full-featured and can be used to edit every aspect of an .rgd device file. Studio > Manage MIDI Devices > Banks... * Tempo and Time Signature Editor has been rewritten and improved. ===== Additional Contributions ===== * Korg-M3-Factory-ALL.rgd (Chuck Elliot) * Korg-M1.rgd (Chuck Elliot) * Updated Polish translation (Grzegorz Pruchniakowski) * Updated Chinese translation (Icenowy Zheng) * Yamaha-MM6-MM8.rgd (Icenowy Zheng) * Yamaha-PSR-SX600.rgd (Huanyu Liu) _______________________________________________ Rosegarden-user mailing list Rosegarden-user(a)lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user

1 year

Still doubt about frames/period and other related settings with Pipewire-jack

by Lorenzo Sutton

Hi LAU, I have now switched to pipewire on my main laptop, with an overall positive experience especially JACK-aware applications typically working 'out of the box' and (more or less) co-existing with other 'desktop' applications (I might talk about some caveats in a different thread). Something which I still can't totally work out though is jack frames/period (aka buffer size aka 'quantum') and its management. For 'everyday' use I keep this at 1024 (which I think is the default) but in some cases I want to push it down even to 128, and I must say that with recent versions of pipewire and with a reasonable 'cpu settings' (I have a tuxedo machine and it has its own cpu thingy) this actually works quite well. What I'm still not understanding completely is how to best manage the frames/period setting. Pre-pipewire in this use case I'd have dedicated qjackctl presets and just select the desired frames/period one for the sound device of interest, restart jack and be good to go. Now with Pipewire it seemed that this would be handled via pw-metadata and setting the clock.force-quantum value (I even made myself a script and then a little python-tk 'gui' for this and setting the sample rate). Up to recently indeed all of the previous preset-related settings in qjackctl (most notably sound device, sample rate, frames/period and periods/buffer) where disabled, but then now _only_ the frames/period setting dropdown seems to be available again and selectable. And indeed jack software (e.g. Ardour) seems to report that buffer size set in qjackcrl. But then if I do: pw-metadata -n settings 0 I see 1024 for clock.quantum and 0 for clock.force-quantum Explicitly setting clock.force-quantum also works. So I'm a bit confused. It seems the idea is to be able to change buffer size 'on the fly' or at least without restarting applications (e.g. in Ardour I _did_ have to disconnect and reconnect to JACK-pipewire, but without closing/reopening). Then I remember lots of discussions and advice about setting, for instance, the periods/buffer to 3 for USB sound devices etc. etc. With Pipewire we don't care about this any more? I also had a couple of instances where Ardour complained about the session being at 48000 but jack running at 44100 when actually it was running (reportedly) at 48000 - but then this is another matter, maybe. Hopefully getting insight on this could be helpful to other LAU 'transitioning' to Pipewire[-jack] :-) Lorenzo

1 year

Pipe organs effect the sound of their halls simply by existing

by David W. Jones

<https://phys.org/news/2024-11-pipe-auto-tune-effect-largest.html> I still don't have a house large enough for a pipe organ. ☹️ --- David W. Jones gnome(a)hawaii.rr.com exploring the landscape of god http://dancingtreefrog.com Sent from my Android device with F/LOSS K-9 Mail.

1 year, 1 month

Realtime-Kernel patch merged to mainline kernel after 20 years...

by Tobias Küchel

Cheers to Ingo Molnar! I am not sure how many users are interested in such news, since there might be still a linux-audio-dev community that I am not part of anymore. Nevertheless, it amuses me that basically half my life ago, I struggled and tested and read tons of stuff, invested a lot of time to get some nice audio stuff going on linux and some rather crappy hardware... and now, 20 years later, the foundation to all of it - a real-time kernel - did not disappear but was developed and maintained until the eagle has landed. Again, cheers to Ingo and all that contributed! Yours, Tobias.

1 year, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-user