Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

5 participants
7515 discussions

Changes in ALSA firewire stack at Linux kernel v5.14 release

by Takashi Sakamoto

Dear all, I'm a maintainer of ALSA firewire stack. Linux kernel v5.14 was out a few days ago[1], including some changes in ALSA firewire stack. The changes bring improvement for usage of including drivers by solving some issues. I appreciate the users cooperating for it[2]. This message includes two topics about solved issues in the release: 1. get rid of playback noise by recovering media clock 2. allow some applications to run without periodical hardware interrupts and another topic: 3. device aggregation Let me describe the two topics first. 1. get rid of playback noise by recovering media clock Many users had been reporting playback noise since the initial version of each driver in ALSA firewire stack. The cause of the issue is complicated to explain, but let me roughly summarize it to a point below: * mismatch between audio sample count in playback stream and the one expected by hardware Since the initial stage of ALSA firewire stack, included drivers transfer audio data frames per second the exact count as sampling frequency, which is configured via ALSA PCM interface; e.g. 44.1 kHz. But it is figured out that it is not suitable for many models. For recent years, I've measured actual packets from/to various models with Windows and OS X drivers[3], and realized the below phenomena. Here, the configured frequency is called 'nominal', and the measured frequency is called 'effective'. * the effective frequency is not the same as the nominal frequency, less or greater by several audio data frames (<= 10 frames) * the effective frequency is not even in successive seconds for some models The phenomena mean that it is not achieved to transfer samples for playback sound by nominal frequency, and computation for even number of samples per second for some models. Additionally, in isochronous communication of IEEE 1394, part of models support time stamp per isochronous packet[4]. When parsing the sequence of time stamp and compare it to frequency of samples included in the packets, I realize the phenomena below: * the phase of sample based on computed time stamp shifts during long packet streaming * before and after configuring source of sampling clock to external signal input such as S/PDIF, neither the effective frequency of samples in packets nor the sequence of time stamp in packets have difference. The phenomena give us some insights. At least, the phase of samples is not deterministic somehow in driver side. It is required to recover the timing to put audio data frame into packet according to packets transferred by the hardware. This is called 'media clock recovery'[5]. In engineering field, many method of media clock recovery has been invented for each type of media. The way which ALSA firewire stack in v5.14 uses is the simplest one. It is to replay the sequence in transferred packets[6][7][8]. The result looks better. As long as I tested, it can cover all of models supported by ALSA firewire stack. 2. allow applications to run independently of periodical hardware interrupts ALSA PCM interface has hardware parameter for runtime of PCM substream to process audio data frame without scheduling periodical hardware interrupts[9]. PulseAudio and PipeWire use the function. All of drivers[10] in ALSA firewire stack now support it. Linux FireWire subsystem has function to flush queued packet till the most recent isochronous cycle. The function is available in process context without waiting for scheduled hardware interrupts, and allows drivers to achieve the topic. In most cases, it's done by calling ioctl(2) with SNDRV_PCM_IOCTL_HWSYNC. The call is the part of routine in usual ALSA PCM application, thus users do not need to take extra care of it. I think these improvements and configurable size of PCM buffer added in Linux kernel v5.5 brings better experience to users. The rest of topic comes from comparison to what existent userspace driver, libffado2[11], does. 3. device aggregation Some user pointed that it is not available with drivers in ALSA firewire stack to aggregate several audio data stream into one stream. It is what libffado2 does. Let me describe my opinion about it. At first, let me start with fundamental attribute of audio data frame. In my understanding about ALSA PCM interface, audio data frame is a unit for audio data transmission. The audio data frame includes the specific number of audio data depending on hardware; e.g. 2 samples for usual sound device. The fundamental attribute of audio data frame is to include the set of audio data sampled at the same time. The goal of aggregating audio data stream is to construct an audio data frame from some audio data frames for several devices. It means that one audio data frame consists of audio data sampled at different time. As I describe the phenomena about nominal and effective frequency, each hardware seems to run own unique effective frequency time to time[12], at least over IEEE 1394 bus. Additionally, we have the experience that the hardware is not aware of sequence of packet with nominal frequency for sample synchronization. It might be legitimate that we can not pick up audio data frame which consists of audio data sampled at the same time even if they are transferred at the same isochronous cycle[13]. When achieving the aggregation, we would need to loosen up the fundamental attribute of audio data frame, by accepting the range of sampling time for audio data in the frame, or need to implement one of resampling methods to adjust phase of audio data to the frame. Although the aggregation is itself superficially useful, it seems not to be a requirement to device driver in hardware abstraction layer of general purpose operating system. It may be over engineering. [1] Linux 5.14 https://lore.kernel.org/lkml/CAHk-=wh75ELUu99yPkPNt+R166CK=-M4eoV+F62tW3TVg… [2] The cooperation is done in my public repository in github.com: https://github.com/takaswie/snd-firewire-improve [3] The method is described in the message: [alsa-devel] IEEE 1394 isoc library, libhinoko v0.1.0 release https://lore.kernel.org/alsa-devel/20190415153053.GA32090@workstation/ [4] The resolution of time stamp is 24.576 MHz, which is the same as specification of cycle time in IEEE 1394. The method to compute time stamp of packet for samples in the packet is defined by IEC 61883-6. We can see integrated document for it published by industry group: https://web.archive.org/web/20210216003054/http://1394ta.org/wp-content/upl… [5] I borrow the expression from IEEE 1722. We can see specific term, sampling transmission frequency (STF) in IEC 61883-6 to express similar idea of the media clock. [6] [PATCH 0/3] ALSA: firewire: media clock recovery for syt-aware devices https://lore.kernel.org/alsa-devel/20210601081753.9191-1-o-takashi@sakamocc… [7] [PATCH 0/6] ALSA: firewire: media clock recovery for syt-unaware devices https://lore.kernel.org/alsa-devel/20210531025103.17880-1-o-takashi@sakamoc… [8] [PATCH 0/3] ALSA: firewire-motu: media clock recovery for sph-aware devices https://lore.kernel.org/alsa-devel/20210602013406.26442-1-o-takashi@sakamoc… [9] SNDRV_PCM_HW_PARAMS_NO_PERIOD_WAKEUP. When the PCM substream has a flag of SNDRV_PCM_INFO_NO_PERIOD_WAKEUP, it's available. [10] Precisely except for snd-isight. [11] http://www.ffado.org/ [12] Precisely the hardware looks to run own unique media clock over IEEE 1394 bus. [13] For precise discussion, the knowledge about IEC 61883-6 and vendor specific method for packetization is required. Regards Takashi Sakamoto

4 years, 1 month

B.Oops 1.8.0 - Glitch Sound Effect Sequencer

by Sven Jaehnichen

Hi, a the new version of B.Oops is out now. With really a LOT of new features: * New: Slot shape mode: Controlled by a user-defined shape instead of a pattern * New: Slot keys mode: Controlled by user-defined MIDI events instead of a pattern * New: Pattern randomization * Fx * New Banger * New EQ * Tremolo: Waveform option * Oops: New sample * Default optimization flags `-O3 -ffast-math` for compiling DSP * Improved binary compatibility / portability using static libs * User friendly hiding patterns for inactive slots * New presets * New: Provide binary packages * Bugfixes * Fix pattern Y flip glitches * Correctly X flip merged pads * Fix paste merged pads causing overlaps * Bugfix remove slots may cause segfault * Fix clicks on decay * Bugfix clicked handles if shape changed Thanks to the community for the ideas and suggestions. B.Oops has AFAIK now got more features than any commercial and closed-source effect sequencer! And you can further contribute to this project. Github: https://github.com/sjaehn/BOops Download: https://github.com/sjaehn/BOops/releases/tag/1.8.0 Preview: https://www.youtube.com/watch?v=nHJlSlvxit8 Regards, Sven

4 years, 1 month

PCM channel names API

by Philippe Bekaert

Same context as my previous mail … The RME HDSPe cards have a large number of inputs and outputs for which the standard ALSA channels names and mappings make little sense. Names reflect the hardware interfaces, e.g. Analog.L, Analog.R, AES.1/1 … AES.1/8, ADAT.1 … ADAT.8 etc… and not their function. Right now, the hdspm driver provides a ad-hoc virtual file in /proc/asound/card<n> containing these names. I am looking for a more generic driver <-> user space API for communicating PCM cannel names. Has anyone been facing the same / similar issues? How have you solved it? Are there any ideas, suggestions, preferences concerning this topic? Again looking forward to your feedback. Best regards and thanks in advance, Philippe.

4 years, 2 months

huge mixers

by Philippe Bekaert

Dear all, I am working on a new driver for the RME HDSPe cards, which eventually could replace the hdspm driver. These cards have a hardware mixer / matrix router, freely mixing tens of hardware inputs and software playbacks into tens of outputs (8192 mixer controls on the HDSPe MADI). Right now, mixer state (cached by the driver) can be read efficiently in one ad-hoc ioctl call, and individual channels modified through a HWDEP ALSA control element with 3 parameters (input/playback index, output index, gain value). I understand there is a desire to get rid of ad hoc ioctls and am therefore looking for a more generic driver <-> user space API to read and write huge mixer state. Does such more generic huge mixer interface already exist? Has someone been facing this or similar issues in this community? If not, are there any ideas, suggestions or preferences how it should look like? Looking forward to your feedback. Best regards and thanks in advance, Philippe.

4 years, 2 months

web expert advice wanted

by Fons Adriaensen

Hello all, I need some advice from a web protocols expert... I want to record the _audio_ part of <https://www.skylinewebcams.com/en/webcam/ellada/crete/rethymno/karavostasi-…> during a long time without wasting bandwidth on the video part, and avoiding being 'timed out' or blocked by 'please whitelist our ads' popups. Anyone has an idea of how to do this ? TIA, -- FA

4 years, 2 months

update of zita-jacktools

by Fons Adriaensen

Hello all, zita-jacktools-1.5.3 is now available at the usual place: <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html> Changes: Added missing method set_rotation() to JackAmbrot. Ciao, -- FA

4 years, 2 months

[ANN] Qtractor 0.9.23 - An Early-Summer'21 Release batch #3

by Rui Nuno Capela

Hello again, one third and last time... But happy to announce yet another point release of, drum roll please... Qtractor 0.9.23 (early-summer'21) is out! Changes for this hot season are just but a few, nothing heartbreaking: - Dropped the 'Activate' option on the plug-in Selection dialog, now being as always on by default. - Have some tolerance for JACK buffer-size changes, only prompting to a complete session reload, if increasing in double the initial period size. - Introducing plug-in blacklisting, on user discretion (in View/Options.../Plugins/Blacklist) and on inventory scan (crashed plug-ins are now automatically blacklisted). - Added special support for LV2 UI GTK2 plugins based on Gtkmm 2.4 framework. - All builds default to Qt6 (Qt >= 6.1) where available. - CMake [8] is now the official build system. Description: Qtractor [1] is an audio/MIDI multi-track sequencer application written in C++ with the Qt framework [2]. Target platform is Linux, where the Jack Audio Connection Kit (JACK [3]) for audio and the Advanced Linux Sound Architecture (ALSA [4]) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio. Website: https://qtractor.org https://qtractor.sourceforge.io http://qtractor.sourceforge.net Project page: https://sourceforge.net/projects/qtractor Downloads: https://sourceforge.net/projects/qtractor/files - source tarball: https://download.sf.net/qtractor/qtractor-0.9.23.tar.gz - source package (openSUSE Tubleweed): https://download.sf.net/qtractor/qtractor-0.9.23-66.1.rncbc.suse.src.rpm - binary package (openSUSE Tubleweed): https://download.sf.net/qtractor/qtractor-0.9.23-66.1.rncbc.suse.x86_64.rpm - AppImage [7] package: https://download.sf.net/qtractor/qtractor-0.9.23-66.1.x86_64.AppImage Git repos: https://git.code.sf.net/p/qtractor/code https://github.com/rncbc/qtractor.git https://gitlab.com/rncbc/qtractor.git https://bitbucket.org/rncbc/qtractor.git Wiki (outdated; help wanted, please): https://sourceforge.net/p/qtractor/wiki/ - static rendering: https://qtractor.org/doc http://qtractor.sourceforge.net/doc https://qtractor.sourceforge.io/doc - user manual & how-to's: https://download.sf.net/qtractor/qtractor-manual-and-howtos.epub https://download.sf.net/qtractor/qtractor-manual-and-howtos.pdf License: Qtractor [1] is free, open-source Linux Audio [5] software, distributed under the terms of the GNU General Public License (GPL [6]) version 2 or later. References: [1] Qtractor - An audio/MIDI multi-track sequencer https://qtractor.org https://qtractor.sourceforge.io http://qtractor.sourceforge.net [2] Qt framework, C++ class library and tools for cross-platform application and UI development https://qt.io/ [3] JACK Audio Connection Kit https://jackaudio.org [4] ALSA, Advanced Linux Sound Architecture https://www.alsa-project.org/ [5] Linux Audio consortium of libre software for audio-related work https://linuxaudio.org [6] GPL - GNU General Public License https://www.gnu.org/copyleft/gpl.html [7] AppImage, Linux apps that run anywhere https://appimage.org/ [8] CMake, a cross-platform, open-source build system generator https://cmake.org See also: https://www.rncbc.org/drupal/node/2262 Keep the fun && Stay safe, always! -- rncbc aka Rui Nuno Capela

4 years, 3 months

[ANN] Qtractor 0.9.23 - An Early-Summer'21 Release batch #3

by Rui Nuno Capela

4 years, 3 months

Is Piperware a successor to Jack/Pulseaudio?

by Yuri

Somebody said on GitHub that "Pipewire is the soon to be successor to Jack/Pulseaudio". I ran a quick search in this ML and couldn't find any mentions of it in the last few years. Is Pipewire viewed like this by the wider community? Does anybody have experience using it? https://pipewire.org/ Thanks, Yuri

4 years, 3 months

updates

by Fons Adriaensen

Hello all, updates on <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html> zita-jacktools-1.5.2 Fixed some bugs that made the class destructors segfault. jconvolver-1.1.0 jmatconvol-0.4.2 Added -T option to fconvolver and fmatconvol, truncates output file to input file size. Ciao, -- FA

4 years, 3 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