Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Fons Adriaensen

Hello all, Updates are available at <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html> for all of the following: aeolus-0.9.7 ambdec-0.7.1 clthreads-2.4.2 clxclient-3.9.2 ebumeter-0.4.2 jaaa-0.9.2 jack_delay-0.4.2 jack_utils-0.0.1 japa-0.9.2 jconvolver-1.0.2 jkmeter-0.6.5 jmatconvol-0.3.3 jmeters-0.4.4 jnoisemeter-0.2.2 octofile-0.3.2 tetraproc-0.8.6 yass-0.1.0 zita-ajbridge-0.8.2 zita-alsa-pcmi-0.3.2 zita-at1-0.6.2 zita-bls1-0.3.3 zita-convolver-4.0.2 zita-dpl1-0.3.3 zita-jclient-0.4.2 zita-lrx-0.1.2 zita-mu1-0.3.3 zita-njbridge-0.4.4 zita-resampler-1.6.2 zita-rev1-0.2.2 For most of them this is just small bug fixes, general maintenance, and above all a systematic cleanup of the Makefiles. Also the jacktools python package (presented at LAC 2018) is available now. I actually did upload the files just before the conference, but forgot to update index.html... Ciao, -- FA

7 years, 3 months

PipeWire

by Wim Taymans

Hi everyone, I'm Wim Taymans and I'm working on a new project called PipeWire you might have heard about [1]. I have given some general presentations about it during its various stages of development, some of which are online [2]. PipeWire started as a way to share arbirary multimedia, wich requires vastly different requirements regarding format support, device and memory management than JACK. It wasn't until I started experimenting with audio processing that the design started to gravitate to JACK. And then some of JACKs features became a requirement for PipeWire. The end goal of PipeWire is to interconnect applications and devices through a shared graph in a secure and efficient way. Some of the first applications will be wayland screen sharing and camera sharing with access control for sandboxed applications. It would be great if we could also use this to connect audio apps and devices, possibly unifying the pulseaudio/JACK audio stack. Because the general design is, what I think, now very similar to JACK, many people have been asking me if I'm collaborating with the linux pro-audio community on this in any way at all. I have not but I really want to change that. In this mail I hope to start a conversation about what I'm doing and I hope to get some help and experience from the broader professional audio developers community on how we can make this into something useful for everybody. I've been looking hard at all the things that are out there, including Wayland, JACK, LV2, CRAS, GStreamer, MFT, OMX,.. and have been trying to combine the best ideas of these projects into PipeWire. A new plugin API was designed for hard realtime processing of any media type. PipeWire is LGPL licensed and depends only on a standard c library. It's currently targeting Linux. At the core of the PipeWire design is a graph of processing nodes with arbirary input/output ports. Before processing begins, ports need to be configured with a format and a set of buffers for the data. Buffer data and metadata generally lives in memfd shared memory but can also be dmabuf or anything that can be passed as an fd between processes. There is a lot of flexibility in doing this setup, reusing much of the GStreamer experience there is. This all happens on the main thread, infrequently, not very important for the actual execution of the graph. In the realtime thread (PipeWire currently has 1 main thread and 1 realtime data thread), events from various sources can start push/pull operations in the graph. For the purpose of this mail, the audio sink uses a timerfd to wake up when the alsa buffer fill level is below a threshold. This causes the sink to fetch a buffer from its input port queue and copy it to the alsa ringbuffer. It then issues a pull to fetch more data from all linked peer nodes for which there is nothing queued. These peers will then eventually push another buffer in the sink queue to be picked up in the next pull cycle of the sink. This is somewhat similar to the JACK async scheduling model. In the generic case, PipeWire has to walk upstream in the graph until it finds a node that can produce something (see below how this can be optimized). Scheduling of nodes is, contrary to JACKs (and LADSPA and LV2) single 'process' method, done with 2 methods: process_input and process_ouput. This is done to support more complex plugins that need to decouple input from output and to also support a pull model for plugins. For internal clients, we directly call the methods, for external clients we use an eventfd and a shared ringbuffer to send the right process command to the client. When the external client has finished processing or need to pull, it signals PipeWire, which then wakes up the next clients if needed. This is different from JACK, where a client directly wakes up the peers to avoid a server context switch. JACK can do this because the graph and all client semaphores are shared. PipeWire can't in general for a couple of reaons: 1) you need to bring mixing of arbitrary formats to the clients 2) sandboxed clients should not be trusted with this information and responsability. In some cases it would probably be possible to improve that in the future (see below). This kind of scheduling works well for generic desktop style audio and video. Apps can send buffers of the size of their liking. Bigger buffers means higher latency but less frequent wakeups. The sink wakeup frequency is determined by the smallest buffer size that needs to be mixed. There is an upper limit for the largest amount of data that is mixed in one go to avoid having to do rewinds in alsa and still have reasonable latency when doing volume changes or adding new streams etc. The idea is to make a separate part of the graph dedicated to pro-audio. This part of the graph runs with mono 32bit float sample buffers of a fixed size and samplerate. The nodes running in this part of the graph also need to have a fixed input-output pattern. In this part of the graph, negotiating the format becomes trivial. We can preallocate a fixed size buffer for each port that is used to send/mix data between nodes. Exactly like how JACK works. In this scenario it would be possible to bring some of the graph state to trusted clients so that they can wake up their peers directly. As it turns out, the generic scheduling mechanism simplifies to the JACK way of scheduling and the option to do some optimisations (can directly start push from the sources, bundle process_input/output calls, mixing on ports is simplified by equal buffer sizes, ...) There is a lot more stuff that I can talk about and a lot of things that need to be fleshed out like latency calculations, an equivalent of JACK transport, session management, ... But this mail is already getting long :) 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. PipeWire is currently still in heavy development, many things can and do still change. I'm currently writing a replacement libjack.so[3] that runs jack clients directly on PipeWire (mixing and complicated scheduling doesn't work yet). Hope to hear your comments, Wim Taymans [1] pipewire.org [2] https://www.youtube.com/watch?v=6Xgx7cRoS0M [3] https://github.com/PipeWire/pipewire-jack

7 years, 4 months

revisiting system timer sound application wake up

by Ricardo Biehl Pasquali

08/08/2018 (ignore this date) PulseAudio tsched ================= Around December 2007 to February 2009 Lennart Poettering has asked some questions in alsa-devel mailing list in order to implement the timer based audio scheduling for PulseAudio. In 2008 he wrote an article named "What's Cooking in PulseAudio's glitch-free Branch". I have not found detailed documentation about PulseAudio timer wake up and I'm not sure about some implementation details. By using the emails from Lennart and his article a Documentation can start to grow. Do PulseAudio synchronize to sound device by adjusting the timer or the amount committed (application pointer)? The nice thing about the second case is that the period time (in application's view) is bonded to system clock instead of sound device's. What timer interface does PulseAudio use? timerfd? POSIX timers? Hardware issues =============== How the deviation of system and sound device clock is today? Perhaps someone that works with sound cards or SoCs can answer this. Do the most of today's hardware has the same clock for sound device and system? How sound devices deal with random accesses to their ring buffer. Do most of them allow writing/reading anywhere and anytime? How is the acurracy and precision of the hardware pointer returned by sound devices? Does SNDRV_PCM_INFO_BATCH flag reveals something about the above one? As PulseAudio runs in many Linux distributions today, it seems an interesting idea to implement an utility to collect some information regarding the above issues. Then make it available to the public. E.g. it would be possible to know the pointer acurracy for specific devices. SCHED_DEADLINE and timerfd ========================== There are a few works over there about SCHED_DEADLINE and audio: - This paper presented in Linux Audio Conference 2011: BAGNOLI, Giacomo; CUCINOTTA, Tommaso; FAGGIOLI, Dario. 2011. Low-Latency Audio on Linux by Means of Real-Time Scheduling. Dario Faggioli is one of the authors of SCHED_DEADLINE. - This presentation of Alessio Balsini: "Experimenting with the Android Audio Pipeline and SCHED_DEADLINE". OSPM 2018. Here is an overview: <https://lwn.net/Articles/754923/>. In SCHED_DEADLINE I assume there is no way to accurately adjust the timer. As well as there is no way to adjust when the first expiration will be. I think this is because of Constant Bandwidth Server algorithm. Must ask to some developer of this. Having this in mind, the only way to synchronize to sound device is by adjusting the amount read/written (application pointer). Timerfd on the other hand is fully adjustable. However, it can be preempted by a high priority task. Anyway I don't see that as a problem as it should ralely happen. Perhaps SCHED_DEADLINE is suitable for professional environment (aiming almost-zero glitches). Thoughts on this? Is there someone planning to implement SCHED_DEADLINE in PulseAudio? I'm currently working on both implementations (not for PulseAudio). See <https://github.com/ricardobiehl/simplesound>. Take a look at 'Documentation/timer_wakeup.rst', 'tools/timer_wakeup.c' and 'tools/deadline_wakeup.c'. 'tools/waveplay.c' play .wav files using the application wakeup method specified in 'tools/Makefile'. Documentation ============= Many of the points I've mentioned should get well covered by some documentation (e.g. ALSA, PulseAudio). Also, I think ALSA's internal (kernel-level) documentation needs to grow. I'm actually working on that, documenting some stuff as I'm developing a small sound library that interacts directly to ALSA in kernel, and the application wakeup using timerfd and SCHED_DEADLINE. Cheers!

7 years, 4 months

All videos online, website going to read-only mode

by Linux Audio Conference

Dear Linux Audio community, we're sending this mail to let you know about the availability of the remaining videos from LAC2018. You can find them on media.ccc.de [1] and on the dedicated event pages linked to in the schedule [2]. We hope you had a great time at the conference and if you couldn't be there physically, this is now the time to have a look at much of what has happened in Berlin this year. In other news, the website [3] is going to read-only mode shortly. See you at future LACs! [1] https://media.ccc.de/b/conferences/lac/lac18 [2] https://lac.linuxaudio.org/2018/pages/schedule/ [3] https://lac.linuxaudio.org/2018/ -- Linux Audio Conference team

7 years, 4 months

Berlin Linux Audio meeting @ c-base 2018-08-14

by Daniel Swärd

Hi all. After previous discussions we decided to switch the meeting time to the second Tuesday of the month. That is tomorrow on the 14th. If the weather is nice (report said it might be rain) I suggest we'll stay outside, otherwise we'll meet in the mainhall as usual. I'll be there from 20:30. Location: c-base, Rungestraße 20 Cheers /Daniel

7 years, 4 months

DrumGizmo 0.9.16 Release

by Bent Bisballe Nyeng

DrumGizmo 0.9.16 Released! DrumGizmo is an open source, multichannel, multilayered, cross-platform drum plugin and stand-alone application. It enables you to compose drums in midi and mix them with a multichannel approach. It is comparable to that of mixing a real drumkit that has been recorded with a multimic setup. This is mainly a bugfix release. If you encountered timing issues when using the humanizer features of 0.9.15, this is the release to get. It also optimizes the resampling and a bunch of other stuff. For the full list of changes, check the roadmap for 0.9.16 [1]. And now, without further ado, go grab 0.9.16 [2]!!! [1]: https://www.drumgizmo.org/wiki/doku.php?id=roadmap:features_roadmap#version… [2]: http://www.drumgizmo.org/wiki/doku.php?id=getting_drumgizmo

7 years, 4 months

Re: [LAD] jackd not using jackdrc...

by Fokke de Jong

i have no JACK_RC_FILE set nor is jack already running……... > On Aug 2, 2018, at 17:28 , Paul Davis <paul(a)linuxaudiosystems.com> wrote: > > > > On Thu, Aug 2, 2018 at 11:25 AM, Fokke de Jong <fokkedejong(a)gmail.com <mailto:fokkedejong@gmail.com>> wrote: > So, how can I make my client into a ‘normal’ client :-) > What is mean is, i already have the .jackdrc file. I just don’t know how to make jackd use it. > > i don't see any way that it cannot be used ... if JACK is not running when you client starts (it is already a "normal" client) then jackd is started *using the contents of jackdrc* if it exists. > > so, either JACK is actually already running or you have JACK_RC_FILE set in your environment to point to some other location >

7 years, 4 months

jackd not using jackdrc...

by Fokke de Jong

Hi all, After migrating to a freshly installed system, it seems jackd has decided not to honor my settings in $HOME/.jackdrc anymore. I have a (minimal, no deskop) install of ubuntu 17.10 and jackd1 when I startt my jack client it prints: creating alsa driver ... hw:MADIFXtest|hw:MADIFXtest|1024|2|48000|0|0|nomon|swmeter|-|32bit but the contents of of ,jackdrc is: /usr/bin/jackd -p512 -dalsa -r48000 -p64 -n2 -D -Chw:MADIFXtest -Phw:MADIFXtest So I’m getting a period size of 1024 rather that 64. copying .jackdrc to /etc/jackdrc also didn’t help. Any idea why jack is refusing my settings? This was working fine on my other system which should be more or less identical, but obviously i'm missing something rather crucial here… thanks! fokke

7 years, 4 months

octofile release

by Fons Adriaensen

Hello all, Source code for octofile version 0.3.0 (linux) is now available at <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html> Octofile is the A to B format converter for Core Sound's Octomic. A-format input can be 1,2,4 or 8 audio file(s) with resp. 8,4,2 or 1 channel(s) each, 44.1, 48 or 96 kHz. Default output is a 2nd order Ambix file (CAF, SN3D, ACN) but the legacy .amb or non-standard formats (e.g. Ambix in a .wav file) are possible as well. You will require a calibration file from Core Sound of course. Ciao, -- FA

7 years, 4 months

USB audio on RPi3B+

by Fons Adriaensen

Hello all, Has anyone tried using multichannel USB audio on a Raspberry 3B+ ? It seems to work perfectly (using zita-alsa-pcmi) with stereo cards. When I try my RME Babyface (12 in, 12 out) in CC mode, the device opens without problems, but then Alsa_pcmi::pcm_wait() times out waiting for the poll fd to become ready. Timeout in pcm_wait() is 1000 milliseconds. The same seems to happen with Jackd, which uses similar code. Is there anything in the Pi's system or configuration that excludes multichannel cards ? Ciao, -- FA

7 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev