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!
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
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
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
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
>
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
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
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
DrumGizmo 0.9.15 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.
We didn't quite make the yearly LAC (Linux Audio Conference) schedule.
But fret not, now it is here! The new 0.9.15 release is primed and ready
for use.
Loads of new stuff in this release. Most prominent is the new timing
humanizer and the bleed control! The timing humanizer works in addition
to the velocity humanizer. Where the velocity humanizer adjusts the
velocity of incoming midi hits, the timing humanizer does the same thing
but instead moves them back and forth in time. This all helps to achieve
a less machine-sounding output. To help with the understanding of the
humanizing features, we've also added a “visualizer” which will mirror
the settings you choose for a better understanding. This is the first
iteration of the visualizer, so feedback is very welcome.
So what else? Oh yes, “bleed control”! And yep, it does exactly what you
expect. If you want a dry sounding kit, turn that slider aaaall the way
down. But if you want all of the ambience in there, turn it aaaall the
way up. Bleed is when a hit on any drum is also picked up by mics that
aren't the “primary” mic of that specific drum. For some genres bleed is
unwanted. For others, not so much. And now YOU are in control.
For the full list of changes, check the roadmap for 0.9.15 [2]
A note on the bleed control: Currently only the newly updated CrocellKit
v1.1 supports this [1]. We still need to update the rest of the kits
before it will work for those. So keep an eye out for that.
And that is all. Please enjoy this release! Get it here [3]
[1]: https://drumgizmo.org/wiki/doku.php?id=kits:crocellkit
[2]:
https://www.drumgizmo.org/wiki/doku.php?id=roadmap:features_roadmap#version…
[3]: http://www.drumgizmo.org/wiki/doku.php?id=getting_drumgizmo
Hey All,
Its been a long time, but there's a new Luppp release out now, version 1.2
https://github.com/openAVproductions/openAV-Luppp/releases/tag/release-1.2.0
Huge thanks to all the contributors, this release was largely driven by
contributions,
and community interaction and interest in the Luppp project - thanks to
all!!
Keep an eye out, there is more stuff coming up soon! -Harry
---
Changelog:
Features:
-> clear clip with MIDI
-> build with meson
-> space triggers special clip
-> manual BPM input (right click on Tap-Button)
Improvements:
-> avoid noise on all controls
-> reduce default metronome volume
-> make label code consistent
-> fix compiler warnings
-> remove all hard coded scene numbers
-> add some debug outputs
-> metronome fancy fades
-> better icon file
Fixes:
-> fix several leaks and errors
-> fix broken waveforms
-> fix fltk/ntk conflict
-> fix generic MIDI launch bug
-> fix wrong output mapping
-> fix input signal flow
-> fix input volume for clip recording
-> fix timing issues after changing playspeed
-> fix scenes losing names once a scene is played
